shreemaan-abhishek commented on code in PR #13503:
URL: https://github.com/apache/apisix/pull/13503#discussion_r3411391426
##########
.github/workflows/check-changelog.yml:
##########
@@ -21,6 +17,10 @@ jobs:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd #
v6.0.2
with:
fetch-depth: 0
+ # Check out the PR branch head itself, not the default
merge-with-base
+ # commit, so the changelog is validated against the release branch's
+ # own scope (since-last-release) rather than a moving target base.
+ ref: ${{ github.event.pull_request.head.sha }}
Review Comment:
**Why scope this to `pull_request` and check out the PR head**
The job runs the validator as `git log <last-release-tag>..HEAD`. On a
`pull_request` event, `actions/checkout` defaults to the **merge commit** (this
branch merged into the base), so `HEAD` becomes "this branch + base combined."
For a release PR that means the validator effectively compares against the
**base branch tip**, which keeps advancing as unrelated PRs merge. Those newer
commits belong to the *next* release and are intentionally absent from this
release's changelog, so the check fails on a moving target rather than on
anything wrong with the changelog.
Two changes fix this:
- `ref: ${{ github.event.pull_request.head.sha }}` checks out the PR branch
head itself instead of the merge commit, so the validator compares against this
branch's own range (everything since the last release tag). That scope is
stable and is exactly what the changelog should cover.
- Limiting the trigger to `pull_request` keeps a single, correctly scoped
run and avoids a post-merge `push` run on the base branch, which would again be
scoped to the base tip (the moving target) and fail for the same reason.
Net effect: the changelog is validated against exactly the commits this
release introduces, independent of how far the base branch has moved.
##########
ci/check_changelog_prs.ts:
##########
@@ -55,7 +55,15 @@ const IGNORE_PRS = [
// 3.15.0
12761, 12805, 12844, 12863, 12829, 12725, 12948,
// 3.16.0
- 12958, 13053, 13148, 13100, 13094, 13081,
+ 12958, 13053, 13148,
+ // 3.17.0
+ // 13386 (add configurable request JSON library) + 13407 (qjson error fix)
were
+ // fully reverted by 13449 within this release, so they net to a no-op and
are
+ // not user-facing. The rest are test-only / CI-only / docs-only changes
whose
+ // subject prefix (e.g. "fix ", "fix(ci)", "feat(seo)", "feat(test)")
dodges the
+ // docs/chore/test/ci type filter but which do not belong in a user
changelog.
+ 13386, 13407, 13449, 13485,
Review Comment:
**Why these `IGNORE_PRS` updates**
`IGNORE_PRS` lists PRs the checker should not require in the changelog. Two
adjustments:
**1. Removed #13081, #13094, #13100 from the `3.16.0` group.** These were
ignored during the 3.16.0 cycle, but they are not part of 3.16.0 — they fall
within this release's range and are now documented in the 3.17.0 changelog.
They should be required, not ignored.
**2. Added a `3.17.0` group** for PRs that are genuinely in range but should
not appear in a user-facing changelog:
- **#13386 + #13407 + #13449** — a feature (configurable request JSON
library) and its follow-up fix that were **fully reverted within this same
release** (#13449). They net to a no-op and never ship, so listing them would
be misleading.
- **#13485, #13139, #13156, #13157, #13158, #13222, #13234** — test-only,
CI-only, or docs-only changes. Their commit subjects use a prefix (e.g. `fix `,
`fix(ci)`, `feat(seo)`, `feat(test)`) that slips past the `docs/chore/test/ci`
type filter, but they have no user-facing effect.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
