docs: point the releasing-struts skill at the published Release Guidelines - #1848
Merged
Merged
Conversation
lukaszlenart
added a commit
that referenced
this pull request
Aug 14, 2026
#1846 gated the maven.yml build job with a job-level `if:` on the `changes` output, on the reasoning that a job skipped that way still reports its check as "skipped", which required status checks accept. That holds for a plain job, but not for a matrix one. A matrix job whose condition is false is skipped before the matrix expands, so it emits a single check run named after the raw name template rather than one per matrix entry. On #1848 the reported name was literally Build and Test (JDK ${{ matrix.java }})${{ ... }} while .asf.yaml requires the context "Build and Test (JDK 17)". That context never appeared, so it stayed Pending and the pull request could not be merged - exactly the failure mode #1846 set out to avoid. Drop the job-level condition and gate the four steps instead. The matrix expands, all five checks report success under their expanded names, and no Maven build runs: a .claude-only pull request costs five idle runners for a few seconds instead of five full builds. Jenkins is unaffected - stage-level `when` has no matrix to expand. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
…lines The release process is now documented at struts.apache.org/release-guidelines.html (apache/struts-site#324, #325), and the cwiki pages the skill warned about are stubs pointing there. The skill was still treating "Building Struts 2 - Normal release" as a live trap and carrying a near-complete second copy of the process in release-runbook.md - two sources of truth that would drift on the next release. Cut the runbook down to what the site page cannot carry: where a step is the release manager's to take rather than the agent's (closing and releasing the Nexus staging repository), why the STRUTS_X_Y_Z tag prompt cannot move into the pom, the text/plain contract on the [ANN] mail, and the scripts this skill ships. Everything else is a link. SKILL.md keeps the gates and the judgement, and now says corrections belong in a struts-site PR rather than here. Two fixes that predate the port: the phase 1 gate said "BOM in sync" while the runbook said the BOM needs no sync, and the runbook told you never to run the staging script from a checkout and then gave a checkout-relative invocation. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
lukaszlenart
force-pushed
the
docs/releasing-struts-skill-guidelines
branch
from
August 14, 2026 16:58
b633817 to
58a9a01
Compare
lukaszlenart
added a commit
that referenced
this pull request
Aug 14, 2026
…ch (#1850) #1846 guarded the two JDK stages on a diff against GIT_PREVIOUS_SUCCESSFUL_COMMIT. On a branch build that is the right baseline. On a pull request build it is not: the pointer is the previous head of the same PR, so once the PR is rebased - or the target branch is merged into it - everything the target absorbed in between shows up as a change of the PR's own. PR-1848 build #2 is the case. The pull request touches only .claude/skills/releasing-struts/, but it had been rebased across the maven.yml fix, and Jenkins computed: + base=b633817af047afaa80948404e2e6f1eb78e02b7a + git diff --name-only b633817... HEAD + outside=.github/workflows/maven.yml Changes outside .claude/: true so both JDK stages ran a full Maven round trip for a documentation-only change. Since main almost always carries code, this made the filter useless for any pull request that is ever brought up to date. Use the merge base with the target branch as the baseline when CHANGE_TARGET is set. The multibranch checkout already fetches it - git fetch ... +refs/heads/main:refs/remotes/origin/main - so origin/$CHANGE_TARGET resolves in the workspace. Branch builds have no target and keep the previous-successful-commit baseline. Fail-open is unchanged and still covers the new path: an unresolvable merge base (target branch absent) yields an empty base and reports true. Exercised against the real commits of #1848 either side of its rebase, and against synthetic heads for: code only, .claude only, mixed, a .claudefoo/ near miss, a missing target branch, and the three branch build baselines. All ten behave as intended. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
The release process is now documented at Release Guidelines (apache/struts-site#324 and apache/struts-site#325), and the cwiki pages the skill warned about — Building Struts 2 — Normal release, Fast track release, Creating and Signing a Distribution, One time steps, Sample announcements — are now stubs pointing there.
The skill had not caught up. It still treated
pageId=27832970as a live trap, andrelease-runbook.mdcarried a near-complete second copy of the process: two sources of truth that would drift apart on the next release.What changed
release-runbook.md(292 → 96 lines) is now the delta only, per phase — the commands live on the site page:STRUTS_X_Y_Ztag prompt cannot move into the pom —tagNameFormatinterpolates@{project.version}and has no string functions.text/plaincontract on the[ANN]mail, with theezmlm-rejectevidence, since a draft made with the Gmail tool is an HTML draft whatever you pass it..java-versionis gitignored here, so it is not a signal.Phases 4 and 7 hand off to
creating-release-vote-mailandcreating-security-bulletinsas before.SKILL.mdkeeps the gates and the judgement, and now says corrections belong in a struts-site PR rather than here. The cwiki table is replaced by a short note that those pages are retired and that their history — the 2013–2017 process,develop/master,people.apache.org, an svn checkout of the production site — is never to be restored from.Two fixes that predate the port
$(mktemp -d), matching the script's own usage line.Documentation only, under
.claude/; no build impact.🤖 Generated with Claude Code