chore(release): prepare 0.6.2 and clear the docs-versioning backlog - #715
Merged
Conversation
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Contributor
🤖 ThrillhouseBot PR SummaryWhat this PR doesCuts the 0.6.2 release and clears the docs-versioning backlog: the changelog's [Unreleased] entries move into a dated [0.6.2] section with a new Dependencies subsection, the pom version moves to 0.6.2, and the website freezes v0.6.0 and v0.6.1 by archiving their nine byte-identical docs pages with versioned sidebars, assets and versions.json entries (current label → v0.6.2). Also adds .claude/ to .gitignore as local tooling. Description vs. ImplementationNo mismatch found between the PR description and the change. Changes Overview
Changed Files
…and 10 more file(s). Risk Assessment
Previous Findings Status
Key Findings
|
| Check | Type | Status | Detail |
|---|---|---|---|
| test | check-run | ⏳ Pending | - |
Automated review by ThrillhouseBot. Reply with /review to re-run.
![thrillhousebot[bot]](https://avatars.githubusercontent.com/in/3996985?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
thrillhousebot
Bot
added
the
documentation
Bumps the project version from 0.6.2-SNAPSHOT to 0.6.2 and turns the [Unreleased] changelog section into [0.6.2], dated today. The section covers what a 0.6.1 user gains: the refused-review handling from #704, the delimiter-aware span stripping in the decline re-check, mention triggers built from the configured bot login, four further injection-sink floor defeaters, and the release workflow now failing loudly when the post-release bump PR cannot be opened. The SonarCloud pass on main is behaviour-neutral and carries no entry. Also gitignores .claude/, a local tooling directory that does not belong in the project tree.
versions.json listed current as v0.6.0 with archives stopping at 0.5.0, while v0.6.1 was already released. Both releases shipped without a freeze, so both are taken here: the third and fourth time this has slipped, after 0.4.0 at the 0.5.0 cut and 0.5.0 at the 0.6.0 cut. The archive script expands the include markers at archive time, so each snapshot is taken from its own tag's content rather than the working tree. README, docs/, CONTRIBUTING.md and the docs pages were restored to v0.6.0, archived, restored to v0.6.1, archived, then returned to the live tree. Worth recording: the doc sources are byte-identical between v0.6.0 and v0.6.1, so the two archives hold the same pages. That is correct rather than redundant, since both are released versions and both belong in the picker, and it is why the 0.6.1 snapshot carries no docs/RELEASING.md, which arrived with #208 after the tag. Nine pages per archive with matching assets and version metadata. Neither tag restore resurrected a deleted file. current.label moves to v0.6.2.
devops-thiago
force-pushed
the
release/prepare-v0.6.2
branch
from
August 14, 2026 21:43
347d0df to
7eb95f7
Compare
devops-thiago
force-pushed
the
release/prepare-v0.6.2
branch
from
August 14, 2026 21:44
7eb95f7 to
01af832
Compare
The release doc described the tag-driven workflow and the bump-PR setting, but said nothing about the two things that made the docs site wrong in production. The docs freeze is manual. versions.json and the archived snapshots are not produced by CI, so skipping the step leaves the site serving the new version's pages under the old version's label. It has been missed at four cuts. The doc now names it in the release checklist and gives the commands, including taking the snapshot from the outgoing tag because the archive script expands the include markers at archive time, and the git status check that catches a restore resurrecting a file deleted since that tag. The github-pages environment must allow the tag ref. The Docs workflow deploys on release: published, which runs against the tag, so without a v* rule the deploy fails at its last step and the only way to publish is to dispatch from main, which serves main's docs and defeats the release-only trigger. The policy is now recorded with the error it produces and the command to inspect it.
Contributor
🤖 ThrillhouseBot — changes since the last review
|
…idebar The per-version sidebar is a hardcoded list in archive-docs-version.mjs kept in sync with astro.config.mjs by comment alone, and it had drifted: the Finding feedback page was added to the live sidebar but never here, so every archive taken since carried eight entries against nine or more pages. The archived feedback page was reachable only by direct URL in 0.4.0, 0.5.0, 0.6.0 and 0.6.1, and 0.4.0 also hid its review-quality evaluation page. The list now carries Finding feedback, and the drift cannot recur silently: a page with no entry aborts the archive before anything is written, naming the page, so the failure is a stopped release step rather than a quietly unnavigable page. Entries whose page is absent from the snapshot are dropped instead, which is what lets older versions archive without carrying entries for pages that did not exist yet. The four affected sidebars are repaired in place, with labels taken from each page's own frontmatter title so an archive keeps the wording it shipped with. 0.4.0 and 0.5.0 predate the website, so there is no per-tag config to restore them from. Verified both directions: a page with no entry exits 1 and leaves no partial archive, and a clean tree archives nine entries in sidebar order. Site builds with all internal links valid.
The Access paragraph said every command but /help takes write access or a login on THRILLHOUSEBOT_REVIEW_MANUAL_TRIGGER_ALLOWED_LOGINS, while the paragraph below it said the allowlist does not extend to @thrillhousebot resolved. Both sentences were on the same page and only the second matched the code, so a maintainer reading the general one would expect an allowlisted login to be able to clear a finding. The code splits the two paths cleanly. Every slash command goes through CommentCommandService.authorized to ManualReviewAuthorizer, which admits write access or an allowlisted login. The resolved directive goes through MaintainerReplyService to FollowUpAnalyzer.mayHoldWriteAccess, which reads author_association alone and never consults the allowlist; clearDirectiveUnauthorizedAck exists precisely to tell an allowlisted commenter that nothing will be cleared. The config table was wrong in the other direction, describing the key as permitting manual /review only. The allowlist gates /summary, /describe and /changelog on the same path. Both entries now say the same thing: slash commands yes, the directive no. The archived 0.6.0 and 0.6.1 copies keep the old wording, since an archive should read as the release shipped.
|
Contributor
🤖 ThrillhouseBot — changes since the last review
|
Contributor
There was a problem hiding this comment.
ThrillhouseBot noted 1 lower-confidence item(s) under Things to double-check in the PR summary (not posted as inline threads):
- LOW: Hand-added 0.4.0/0.5.0 sidebar entries reference pages not shown to exist in those snapshots (
website/src/content/versions/0.4.0.json:28)
The same PR that adds the archive script's new contract — "Entries whose page is absent from the snapshot are dropped, which is how older versions archive cleanly" (website/scripts/archive-docs-version.mjs) — hand-edits two script-owned version configs to ADD entries for pages that appear nowhere in the provided material: "Finding feedback" (slugfeedback) was added to both 0.4.0.json and 0.5.0.json (line 28-30 in each), and "Review-quality evaluation" (slugreview-eval) to 0.4.0.json (lines 39-42). Unlike the 0.6.0/0.6.1 archives, whose nine pages are all visible in this diff, no website/src/content/docs/0.4.0/feedback.md, 0.5.0/feedback.md, or 0.4.0/review-eval.md is shown to exist, and review-eval is not in the script's SIDEBAR either. If the snapshot directories lack these pages, the version picker for v0.4.0/v0.5.0 renders dead links, contradicting the PR's "all internal links valid" claim; if the pages exist, the backfill is correct. Verification request: list the committed snapshot dirs (git ls-tree -r v0.4.0 -- website/src/content/docsand the same for v0.5.0) and drop whichever entries have no matching page.
6 tasks
devops-thiago
added a commit
that referenced
this pull request
Aug 15, 2026
… published (#717) ## What type of PR is this? - [x] 🐛 Bug fix - [x] 🏗️ CI/CD - [x] 📝 Documentation ## Description The docs site has never deployed itself, including for v0.6.2 just now. `docs.yml` declares `release: published`, but the `release` job creates the release with the default `GITHUB_TOKEN`, and GitHub does not start workflow runs for events that token raises — the same recursion guard already documented for the bump PR. The trigger has fired **zero times** in the repo's history: ``` docs.yml runs by event: pull_request 96, workflow_dispatch 4, release 0 ``` Every release through v0.6.2 published its docs by hand. **On the `v*` tag policy from #715.** That was a real and separate bug — the build runs against the tag ref, so the deploy would have been refused by the `github-pages` environment even if the event had fired. But it was not why nothing ran, and my note in that PR saying the next release would deploy itself was wrong. What it did fix is the manual path: dispatching against a tag works now for the first time, which is how v0.6.2's docs went live. **The fix.** A `publish-docs` job in `release.yml` dispatches `docs.yml` against the release tag once the release exists. `workflow_dispatch` is exempt from the recursion guard. Three details: - **Gated on `update_latest`**, like `bump-version`. The live site tracks the highest release, so a patch cut on an older line must not republish the site from its tag. - **Fails loudly** rather than warning. A silent miss is what left the site four versions behind. - **Runs after `release`**, so the docs never go live for a version whose release did not complete. The declared `release: published` trigger stays on `docs.yml`, because a release published by hand in the UI does fire it. Its comment now says so instead of implying it is the live path. `docs/RELEASING.md` described only the tag policy and claimed the next release would deploy itself. It now separates the two conditions, records that the trigger does not fire on its own, and gives the command to republish a tag after a docs hotfix. ## Related Issues Follows #715, which added the `github-pages` tag policy and the docs-freeze procedure. ## How Has This Been Tested? - [x] Manual testing - `actionlint .github/workflows/release.yml .github/workflows/docs.yml` → clean - `npm run build` in `website/` → all internal links valid - The dispatch path itself was exercised by hand against `v0.6.2` (`gh workflow run docs.yml --ref v0.6.2`): build and deploy both succeeded, and the live site now serves v0.6.2 with v0.6.0 and v0.6.1 in the picker - End to end, the `publish-docs` job can only be proven by the next release No production code changes. ## Checklist - [x] My code follows the project's coding standards - [x] I have performed a self-review of my own code
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.
What type of PR is this?
Description
Prepares the 0.6.2 release and clears the docs-versioning backlog that has now slipped four releases
running.
Version and changelog.
pom.xmlmoves from0.6.2-SNAPSHOTto0.6.2, and[Unreleased]becomes
[0.6.2] — 2026-08-14. The section covers what a 0.6.1 user gains: the refused-reviewhandling (#704), delimiter-aware span stripping in the decline re-check (#697), mention triggers
built from the configured bot login (#698), four further injection-sink floor defeaters (#696), and
the release workflow failing loudly when the bump PR cannot be opened (#11). The SonarCloud pass on
main is behaviour-neutral and carries no entry.
A
Dependenciessection records the two bumps merged to main after this branch was cut: the Quarkusplatform 3.38.0 → 3.38.1 (#706) and
actions/attest-build-provenance4.1.1 → 4.2.2 (#708). Both aremerged in here, so the release builds on the same versions main is on. #707 (maven-minor-patch) is
still open and is not included; if you want it in 0.6.2, merge it and say so and I will add the
entry and re-merge.
Docs freeze, twice.
versions.jsonreadcurrent: v0.6.0with archives stopping at 0.5.0, whilev0.6.1 was already released. Both 0.6.0 and 0.6.1 shipped without a freeze, so both are taken here.
This is the third and fourth slip, after 0.4.0 was missed at the 0.5.0 cut and 0.5.0 at the 0.6.0 cut.
Because
archive-docs-version.mjsexpands the include markers at archive time, each snapshot comesfrom its own tag rather than the working tree: README,
docs/,CONTRIBUTING.mdand the docs pagesrestored to
v0.6.0, archived, restored tov0.6.1, archived, then returned to the live tree.One thing worth knowing: the doc sources are byte-identical between v0.6.0 and v0.6.1, so the two
archives hold the same nine pages. That is correct rather than duplicated work — both are released
versions and both belong in the picker — and it is why the 0.6.1 snapshot carries no
docs/RELEASING.md, which arrived with #208 after the tag. Neither restore resurrected a deletedfile, unlike the 0.4.0 archive.
current.labelmoves to v0.6.2.Release-triggered docs deploys now work. The
github-pagesenvironment permitted onlymain, sothe Docs workflow's
release: publishedtrigger — which runs against the tag ref — failed on everyrelease. v0.6.0's deploy failed twice with:
and was worked around by dispatching from
main, which publishes main's docs rather than therelease's and contradicts the workflow's stated design ("Live site tracks GitHub Releases only"). A
v*tag policy has been added alongside the existingmainbranch rule, so the next release deploysitself:
Both of these were undocumented, which is a large part of why the freeze slipped four times running.
docs/RELEASING.mdnow carries them: the freeze as a named step in the release checklist, with thecommands and the reason the snapshot has to come from the outgoing tag, and the
github-pagestagpolicy with the error it produces and the command to inspect it.
Related Issues
Part 1 of #11 (the bump PR failing loudly) shipped in #208; this carries its changelog entry.
How Has This Been Tested?
Unit tests
Manual testing
./mvnw -B clean test→Tests run: 3248, Failures: 0, Errors: 0, Skipped: 0, buildingthrillhousebot 0.6.2./mvnw -B clean compile spotbugs:check spotless:check→BugInstance size is 0npm ci && npm run buildinwebsite/→ 93 pages (up from 75; the two archives add 18), allinternal links valid
Archive content verified in both directions:
docs/RELEASING.mdis absent from the 0.6.1 snapshotand present in the live tree; nine pages in each archive with matching assets and version metadata
git statusafter the tag restores showed nothing outside the new archive directories andversions.jsonNo production code changes.
Checklist