CI: Check CHANGELOG presence for published tooling and config packages

[simison]

Alternative to #83486

What?

Extend the package CHANGELOG verifier to the npm-published tooling and config packages.

What changed:

• 19 more packages are checked.
  • babel-plugin-import-jsx-pragma, babel-plugin-makepot, babel-preset-default
  • browserslist-config, npm-package-json-lint-config, prettier-config, stylelint-config
  • create-block, create-block-interactive-template, create-block-tutorial-template
  • dependency-extraction-webpack-plugin, readable-js-assets-webpack-plugin
  • postcss-plugins-preset, postcss-themes
  • docgen, e2e-test-utils-playwright, env, eslint-plugin, scripts

wp-build was already covered.

• Test-only changes are now skipped anywhere in a package. Before, only test and stories folders under src/ were skipped. These packages keep tests elsewhere. This also stops test-only changes to theme and wp-build from being flagged. We still keep real source files, including one like utils/testing.js.

Why?

These are tools consumers rely on, so it's fair to give a proper heads-up when they change or add new features.

How?

Expands existing CI checklists.

Over the last six months of trunk, this change makes the changelog check run on about 10% more PRs, and it would have flagged about 41% more PRs for a missing changelog entry. In absolute terms that's roughly 3–4 extra flagged PRs a week.

How often the CHANGELOG check would trigger (AI Analysis)

The sample is 3,349 PRs merged since 2026-03-28, after dropping automated release, publish and "backport release metadata" commits. Those touch every package at once, so they inflate the counts for both rules.

	Before	After	Change
Workflow runs at all	1,410 PRs (42.1%)	1,461 (43.6%)	1.04×
PRs where a package presence check runs	923 (27.6%)	1,016 (30.3%)	1.10× (+93, about 3.6 a week)
Package presence checks run	1,375	1,714	1.25×
Package checks that fail (no changelog entry)	433	685	1.58×
PRs with at least one failed check	222 (6.6%)	312 (9.3%)	1.41× (+90, about 3.5 a week)

Testing Instructions

CI passing.

Use of AI Tools

claude

[mirka]

Adding these entries makes every matching PR start 35 presence jobs instead of 16. On this PR, the 19 new jobs checked out the repository and fetched trunk before skipping. Apparently that's not too significant in wall clock time (13 seconds total?), but I can't help but think it can be done more efficiently 😅 Separate problem though.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: simison <simison@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[simison]

Apparently that's not too significant in wall clock time (13 seconds total?), but I can't help but think it can be done more efficiently

Yeah, I don't think the package per-job is sustainable, and I explored moving them to a single job at #83486 — worth doing in a follow-up and measuring which approach is more efficient.

[aduth]

Yeah, I don't think the package per-job is sustainable, and I explored moving them to a single job at #83486 — worth doing in a follow-up and measuring which approach is more efficient.

Maybe we can do the single-job consolidation as its own pull request separate from the changes to require changelog entries? If that would be easier / incremental / less controversial.