Skip to content

chore: release v1.14.2#545

Merged
avihut merged 1 commit into
masterfrom
release-pr
May 22, 2026
Merged

chore: release v1.14.2#545
avihut merged 1 commit into
masterfrom
release-pr

Conversation

@wheatley-the-moronic-ci-bot
Copy link
Copy Markdown
Contributor

@wheatley-the-moronic-ci-bot wheatley-the-moronic-ci-bot Bot commented May 22, 2026 •
edited
Loading

🤖 New release

  • daft: 1.14.1 -> 1.14.2
Changelog

1.14.2 - 2026-05-22

Bug Fixes

Miscellaneous

  • Ignore .understand-anything/ knowledge graph artifacts

Automatically maintained release PR. Merging adds the chore: release v1.14.2 commit to master; the tag-merged-release job in .github/workflows/release-flow.yml then tags that commit v1.14.2 and pushes the tag, which triggers release.yml (cargo-dist) to build the binary release.

New commits to master update this PR continuously (force-pushed) — the version bump, changelog entries, man pages, and CLI docs all re-derive from current master state. The next version was computed from conventional commits via git-cliff --bumped-version; when no releasable commits remain, this PR is closed automatically.

@wheatley-the-moronic-ci-bot wheatley-the-moronic-ci-bot Bot added the release Automated release PR label May 22, 2026
@avihut avihut mentioned this pull request May 22, 2026
Merged
8 tasks
avihut added a commit that referenced this pull request May 22, 2026
@avihut
ci(release): skip heavy test jobs on release PRs; clean up release-pl…
4e4b481 
…z residue

Bundled with the changelog-section change since both target release-PR
ergonomics:

1. **Skip heavy jobs on PRs labeled `release`.** dep-age-check,
   dep-license-check, lint, msrv-check, windows-check, build, and
   homebrew-simulation now gate on
   `!contains(github.event.pull_request.labels.*.name, 'release')` in
   addition to their existing change-detection gate. Release PRs only
   touch Cargo.toml/Cargo.lock/CHANGELOG/man/CLI docs — running the full
   ~15-minute suite is redundant (src/ hasn't changed since the last
   green master push).

   `xtask-test` and `changes` still run on release PRs: `xtask-test`
   includes the verify-man / verify-cli-docs checks that actively
   validate the release PR's own regenerated content; `changes` is the
   gate-derivation job.

2. **Remove stale release-plz-* branch matches from xtask-test verify
   steps.** They were skipping verify-man / verify-cli-docs on release-plz-
   branded branches; our new release-pr branch doesn't match. PR #545
   demonstrated those verifications now pass cleanly on the new flow's
   release PRs because the pre-release-hook regenerates docs in the same
   commit as the version bump (no temporal mismatch).

3. **Repo-wide scrape and cleanup of stale release-plz references.**
   - `.github/workflows/bench.yml` paths-ignore: `release-plz.yml` →
     `release-flow.yml` (the old file no longer exists)
   - `.github/workflows/test.yml` paths-ignore: same
   - `CLAUDE.md` Release Process section: rewritten to describe the new
     cargo-release flow + manual-override input + conventional-commit
     parser rules
   - `mise-tasks/test/version-format` comment: release-plz →
     cargo-release
   - `docs/.vitepress/config.ts` comment: dropped tool-specific
     attribution in favor of describing the format itself

Comments in `release.toml`, `Cargo.toml`, `.github/workflows/release-flow.yml`
that reference `release-plz` intentionally remain — they document the
migration context and the upstream issue
(release-plz/release-plz#2595) that motivated it. Historical planning
documents under `docs/superpowers/` also stay unchanged — they are
snapshots of decisions made when release-plz was the active tool.

YAML quoting note: the new `!contains(...)` conditions use `if: >-` block
scalar so the leading `!` isn't parsed as a YAML tag.
avihut added a commit that referenced this pull request May 22, 2026
@avihut
ci(release): address review findings on PR #547
094c692 
1. Escape dots in awk version regex so `1.14.2` matches a literal
   `1.14.2` rather than `1X14Y2` etc. Defense in depth — no real
   CHANGELOG heading would actually collide, but technically correct.

2. Add `--add-label release` to the `gh pr edit` path so the `release`
   label is self-healing. The CI-skip logic in this same PR gates on
   that label; if it were ever manually removed, subsequent
   force-pushes would silently start running the heavy jobs again
   without it.

Verified locally: awk extraction still produces the same correct
section against the live PR #545 CHANGELOG.md, and a synthetic
`## [1X14X2]` heading no longer false-matches.
avihut added a commit that referenced this pull request May 22, 2026
@avihut
ci(release): include changelog in PR body + skip heavy tests on relea…
e229db9 
…se PRs + clean up release-plz residue (#547)

* ci(release): include changelog section in release PR body

Restores the release-plz-style expandable Changelog block in the release
PR body. Reviewers can now see exactly which conventional-commit entries
are going into the release without clicking through to CHANGELOG.md in
the PR diff.

Mechanics:
- The "Compute next version" step now also exports `current_version` to
  $GITHUB_OUTPUT (both the auto-compute path and the manual-override path)
  so the body can render the "X.Y.Z -> A.B.C" line.
- The "Open or update release PR" step extracts the new version's section
  from the freshly-regenerated CHANGELOG.md via awk (matches the
  `## [<NEXT_VER>]` heading, prints lines until the next `## [` heading)
  and embeds it inside a <details><summary>Changelog</summary> block.

Body shape matches the release-plz format we used to have (see PR #520
for the canonical example) — the 🤖 prefix, the version-bump line, the
expandable details/blockquote nesting, the explanatory footer.

Backtick-safety verified: bash double-quoted variable expansion does not
re-evaluate the expanded content, so future commit messages containing
backticks (e.g. `feat: improve \`gwco\` shortcut`) won't trigger
command substitution at body-build time.

Fixes #546.

* ci(release): skip heavy test jobs on release PRs; clean up release-plz residue

Bundled with the changelog-section change since both target release-PR
ergonomics:

1. **Skip heavy jobs on PRs labeled `release`.** dep-age-check,
   dep-license-check, lint, msrv-check, windows-check, build, and
   homebrew-simulation now gate on
   `!contains(github.event.pull_request.labels.*.name, 'release')` in
   addition to their existing change-detection gate. Release PRs only
   touch Cargo.toml/Cargo.lock/CHANGELOG/man/CLI docs — running the full
   ~15-minute suite is redundant (src/ hasn't changed since the last
   green master push).

   `xtask-test` and `changes` still run on release PRs: `xtask-test`
   includes the verify-man / verify-cli-docs checks that actively
   validate the release PR's own regenerated content; `changes` is the
   gate-derivation job.

2. **Remove stale release-plz-* branch matches from xtask-test verify
   steps.** They were skipping verify-man / verify-cli-docs on release-plz-
   branded branches; our new release-pr branch doesn't match. PR #545
   demonstrated those verifications now pass cleanly on the new flow's
   release PRs because the pre-release-hook regenerates docs in the same
   commit as the version bump (no temporal mismatch).

3. **Repo-wide scrape and cleanup of stale release-plz references.**
   - `.github/workflows/bench.yml` paths-ignore: `release-plz.yml` →
     `release-flow.yml` (the old file no longer exists)
   - `.github/workflows/test.yml` paths-ignore: same
   - `CLAUDE.md` Release Process section: rewritten to describe the new
     cargo-release flow + manual-override input + conventional-commit
     parser rules
   - `mise-tasks/test/version-format` comment: release-plz →
     cargo-release
   - `docs/.vitepress/config.ts` comment: dropped tool-specific
     attribution in favor of describing the format itself

Comments in `release.toml`, `Cargo.toml`, `.github/workflows/release-flow.yml`
that reference `release-plz` intentionally remain — they document the
migration context and the upstream issue
(release-plz/release-plz#2595) that motivated it. Historical planning
documents under `docs/superpowers/` also stay unchanged — they are
snapshots of decisions made when release-plz was the active tool.

YAML quoting note: the new `!contains(...)` conditions use `if: >-` block
scalar so the leading `!` isn't parsed as a YAML tag.

* ci(release): address review findings on PR #547

1. Escape dots in awk version regex so `1.14.2` matches a literal
   `1.14.2` rather than `1X14Y2` etc. Defense in depth — no real
   CHANGELOG heading would actually collide, but technically correct.

2. Add `--add-label release` to the `gh pr edit` path so the `release`
   label is self-healing. The CI-skip logic in this same PR gates on
   that label; if it were ever manually removed, subsequent
   force-pushes would silently start running the heavy jobs again
   without it.

Verified locally: awk extraction still produces the same correct
section against the live PR #545 CHANGELOG.md, and a synthetic
`## [1X14X2]` heading no longer false-matches.
@avihut avihut merged commit 577eafa into master May 22, 2026
10 checks passed
@avihut avihut deleted the release-pr branch May 22, 2026 08:35
@avihut avihut mentioned this pull request May 22, 2026
Closed
avihut added a commit that referenced this pull request May 22, 2026
@avihut
fix(ci): allow squash-merge ' (#nnn)' suffix in tag-merged-release regex
a72e94d 
PR #545 was merged via GitHub's default squash-merge UI. The resulting
HEAD subject is `chore: release v1.14.2 (#545)` — the `(#545)` suffix
is added by GitHub itself, not by anyone editing the title. My existing
regex anchored at `$` immediately after the version, so it didn't match:

  HEAD commit subject: chore: release v1.14.2 (#545)
  Not a release commit, nothing to tag

Result: v1.14.2 tag had to be pushed manually. Reviewer for #547 had
warned about squash-subject foot-guns but missed that GitHub itself
edits the subject in this way.

Fix: append `(\ \(#[0-9]+\))?` to the regex so the optional PR-number
suffix is matched. Verified locally against:

  MATCH: "chore: release v1.14.2"             -> v1.14.2
  MATCH: "chore: release v1.14.2 (#545)"      -> v1.14.2
  MATCH: "chore: release v2.0.0-rc.1 (#999)"  -> v2.0.0-rc.1
  no:    "feat: add thing (#100)"
  no:    "chore: release v1.14.2 stuff"

Fixes #548.
@avihut avihut mentioned this pull request May 22, 2026
Merged
3 tasks
avihut added a commit that referenced this pull request May 22, 2026
@avihut
fix(ci): allow squash-merge ' (#nnn)' suffix in tag-merged-release re…
5799f37 
…gex (#549)

PR #545 was merged via GitHub's default squash-merge UI. The resulting
HEAD subject is `chore: release v1.14.2 (#545)` — the `(#545)` suffix
is added by GitHub itself, not by anyone editing the title. My existing
regex anchored at `$` immediately after the version, so it didn't match:

  HEAD commit subject: chore: release v1.14.2 (#545)
  Not a release commit, nothing to tag

Result: v1.14.2 tag had to be pushed manually. Reviewer for #547 had
warned about squash-subject foot-guns but missed that GitHub itself
edits the subject in this way.

Fix: append `(\ \(#[0-9]+\))?` to the regex so the optional PR-number
suffix is matched. Verified locally against:

  MATCH: "chore: release v1.14.2"             -> v1.14.2
  MATCH: "chore: release v1.14.2 (#545)"      -> v1.14.2
  MATCH: "chore: release v2.0.0-rc.1 (#999)"  -> v2.0.0-rc.1
  no:    "feat: add thing (#100)"
  no:    "chore: release v1.14.2 stuff"

Fixes #548.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@avihut avihut

Labels

release Automated release PR

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@avihut