Repository navigation
Include GitHub issues in the release notes built by build-changelog.sh - #1701
Merged
Merged
Conversation
build-changelog.sh built the release notes only from Apache Jira: it looked up the Jira version id on the ReleaseNote.jspa page and copied that page's text release notes into the changelog. Issues are filed on GitHub now, so their fixes never reached the changelog, and a release without a Jira version stopped the script. The page also answers anonymous requests with 401 by now, so the script failed for every version. The script now collects both: - the Jira issues resolved as Fixed with the version as fix version, through the anonymous REST API; a version Jira does not know is skipped instead of failing; - the GitHub issues referenced from the commits since the previous release, as #N, GH-N or an issue URL, either directly or through a pull request that closes them. Issues closed as not planned or as a duplicate are left out. The previous release is the rel/wicket-* tag with the highest version below the one being built; --since overrides it. Release tags are not on the maintenance branches, so the range is taken from the tag rather than from git describe. The repository has no milestones or type labels, so the commits are the only record of which release fixed an issue that needs no bookkeeping. A fix whose commits do not reference its issue is missed, so the script lists the issues closed as completed in the same period that no commit on any branch references, for the release manager to check before it commits. Issues referenced only from another branch are left out of that list: on a maintenance branch they are almost all fixes that were not backported. GitHub issues get the [GH-N] key, which GitHub links by itself, and are grouped by their issue type: Bug, Feature (as New Feature, next to Jira's) or Task. Issues without a type go into an 'Other' group, and the script reports how many there are so their type can be set first. The layout of the notes is unchanged, so release.sh still reads them from /tmp/release-notes-<version>.txt or cuts them from the changelog. Regenerating 10.10.0 gives the same Jira section as the original changelog commit. The script now runs under bash, which it already needed, and needs jq and a GitHub CLI that is logged in. A version given as argument is used as is; the major version is taken from it instead of a pattern that required a qualifier. A changelog that does not exist yet, CHANGELOG-11.x on master, is created, and the diff shown before the commit is taken after staging, so it includes such a new file. GitHub issue #1699 Generated-by: Claude Code (Claude Opus 5.5)
This was referenced Oct 23, 2026
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1701 +/- ##
============================================
- Coverage 62.34% 62.32% -0.02%
- Complexity 11361 11363 +2
============================================
Files 1253 1253
Lines 48438 48438
Branches 6794 6794
============================================
- Hits 30198 30191 -7
- Misses 15538 15550 +12
+ Partials 2702 2697 -5 🚀 New features to boost your workflow:
|
JIRA is read-only now. An issue fixed after that can no longer be resolved or given a fix version, so the query for the issues resolved as Fixed in the release left it out. On wicket-10.x the notes for 10.12.0 missed WICKET-7199, WICKET-7203 and WICKET-7204, all still open in JIRA, and WICKET-7205, which JIRA lists under 10.11.0 although its fix came after that release. The script now also takes the JIRA keys from the subjects of the commits since the previous release and looks them up in JIRA, for the type and summary. Two rules keep out the keys a commit only mentions: a key from the body is not used, and neither is a key that a commit before the previous release already has in its subject, which drops for example "carry the WICKET-6877 fix over" on master. An issue resolved otherwise than as Fixed is left out. JIRA's search skips a key it does not know instead of failing. The fix-version query stays, so the notes of a release that JIRA did track are unchanged. GitHub issue #1699 Generated-by: Claude Code (Claude Opus 5.5)
The script listed the GitHub issues closed as completed since the previous release that no commit referenced, as possible fixes missing from the notes. In practice it listed fixes made on other branches, and after narrowing it to issues no branch referenced, only GH-1588, a copy of WICKET-7199. It nagged about issues that were fine, so it is gone. What the release manager is told now is about the issues in the notes: - A GitHub issue the commits of the release reference but that is still open is reported, to be closed once every branch that needs the fix has it. On wicket-10.x that is #1584, #1659 and #1699. - A GitHub issue with a JIRA key in its title is taken as a copy of that JIRA issue. When the JIRA issue is in the notes, the copy is listed under the JIRA key only, so a fix is not listed twice when commits reference both, and a copy that is still open is reported. JIRA is read-only, so the copy is where such an issue can be closed. Both reports only pause the script; neither changes what is merged into the changelog. GitHub issue #1699 Generated-by: Claude Code (Claude Opus 5.5)
…ed issue The script took every #N in a commit message as an issue the commit fixes. A body that only mentions an issue put it in the release notes: the message of the previous commit names #1584 and #1659 in passing, so the notes for 9.25.0 and 8.20.0 listed both, although neither fix is on those branches. The subject still counts as a whole, as does a pull request number in it. In the body a reference now counts in the forms that say the commit fixes the issue: 'GitHub issue #N', the form the commits of this project use, and #N after fixes, closes or resolves, with or without 'issue' in between. On the ranges of the coming releases this finds the same issues as before, except on master, where a commit that adds a regression test for #1618 only mentions it. GitHub issue #1699 Generated-by: Claude Code (Claude Opus 5.5)
The script reported the open GitHub issues in the notes and the ones without an issue type, then merged the notes after a key press. A release could go out with issues still open and entries under 'Other'. It now stops before it touches the changelog and exits with an error when it flags an issue: - a GitHub issue in the notes that is still open; - an open GitHub copy of a JIRA issue in the notes; - a GitHub issue without an issue type. Closing an issue stays with a person, once every branch that needs the fix has it, and setting a type likewise. --force merges the notes anyway, for example for a release that goes out while a backport of one of its fixes to another branch is still under way. JIRA issues are not checked, since JIRA is read-only. A GitHub issue now counts as a copy of a JIRA issue only when its title starts with the key, as '[WICKET-1234] Summary' or 'WICKET-1234 Summary'. A key further on in the title, as in a new issue about the regression of an old fix, no longer makes it one. GitHub issue #1699 Generated-by: Claude Code (Claude Opus 5.5)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #1699, backported in #1702 (10.x), #1703 (9.x) and #1704 (8.x).
build-changelog.shnow builds the release notes of a release from the commits on its branch, looking up the issues they fix in Jira and on GitHub. A release without a Jira version, such as 10.12.0, still gets a changelog section.The old script was broken for every version: Jira's
ReleaseNote.jspapage answers anonymous requests with 401 now, so the version-id lookup always failed. Jira is also read-only now, so a Jira issue fixed after that can no longer be resolved or given a fix version. Of the options in the issue, this takes the commit-based one: nothing on GitHub records the release, and milestones or labels would mean tagging every issue for this release by hand first.GitHub issue #Nor#Nafter fixes, closes or resolves. A pull request number contributes the issues the pull request closes. Issues closed as not planned or as a duplicate are left out.[WICKET-7199] Summary, is a copy of that Jira issue. When the Jira issue is in the notes, the copy is listed under the Jira key only.New Feature, next to Jira's) and Task. Keys are[GH-N], as Apache Arrow writes them. The layout is otherwise unchanged, sorelease.shneeds no change.--forcemerges the notes anyway, for example when a backport of one of the fixes to another branch is still under way. Jira issues are not checked, since Jira is read-only.Review
The only file is
build-changelog.sh. The five commits are the steps of the design and read best in order:[GH-N].--forceis given; a copy is recognised by its title prefix only.The commit messages have the reasoning.
Risk
Only release tooling changes; nothing in the build or the artifacts does. The release manager needs
jqand a logged-ingh; the script checks for both. A release run now fails while an issue in its notes is open on GitHub. On every branch that is #1699 itself until these PRs are merged. On master and 10.x it is also #1584 and #1659, and on master #1593 and #1616; all four are fixed but were never closed.A fix tracked both in Jira and on GitHub without the title prefix is listed twice. Regenerating 10.10.0 lists WICKET-7189 and GH-1492, which are the same fix; renaming GH-1492 to
[WICKET-7189] …lists it once.Tests
ghchecked the copy and untyped paths on 10.x. Both[WICKET-7204] …andWICKET-7203: …are taken as copies, and "Regression of the WICKET-7205 fix" is not. A copy that commits reference is folded into its Jira entry. An untyped issue is flagged.--force, every branch stops with the open issues listed and leaves the changelog unchanged.release.sh's extraction reads the new sections, and shellcheck is clean at-S warning.Output on master (11.0.0)
Run at this branch's tip with
--forceand Enter at the prompt. Without--forcethe run ends after the list of open issues, with:CHANGELOG-11.xdoes not exist yet, so the script creates it.🤖 Generated with Claude Code