feat(release): allow overriding a crate's bump level from the dispatch - #2508
Draft
iunanua wants to merge 2 commits into
Draft
feat(release): allow overriding a crate's bump level from the dispatch#2508iunanua wants to merge 2 commits into
iunanua wants to merge 2 commits into
Conversation
cargo-public-api, cargo-release, git-cliff and cargo-semver-checks were installed with taiki-e/cache-cargo-install-action, which runs `cargo install` and caches the result; its own README recommends install-action for any tool install-action can fetch. On the last dispatch those four steps cost 703s of the job's 3660s, all cache misses. The sibling pr-title-semver-check installs two of the same tools with install-action in 77s. cargo-semver-checks and git-cliff come from install-action's own manifest. cargo-release and cargo-public-api are not in it and resolve through the cargo-binstall fallback, so `fallback: none` is deliberately not set. Pin all four: cargo-release and git-cliff were unpinned, letting the tools that choose version numbers and render changelogs drift under the workflow that cuts releases. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Correcting a wrong level on a release proposal meant checking the branch out and running cargo-release by hand. Add a `level_overrides` input (CRATE=LEVEL,...); release-version-bumps.sh uses the given level for those crates instead of calling semver-level.sh, so a correction is a re-dispatch. Overriding the input rather than patching the branch keeps the cascade, the changelogs and the publication order consistent with the new level -- a level corrected to major can pull further crates into the release. Names are validated against the computed release set rather than the crates input, so a typo, or a crate the dependency closure never pulled in, fails with the candidate list instead of silently shipping the computed level. An override on the deferred or initial-release path warns rather than passing unnoticed, and the requested level is recorded in the row so the PR body can show that a level was set by hand. Also record the dispatch inputs in an HTML comment in the PR body, so a follow-up run can reconstruct them without an operator retyping the crate list. level_overrides is included so successive corrections accumulate instead of the newest one reverting the last. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Contributor
Artifact Size Benchmark Reportaarch64-alpine-linux-musl
aarch64-unknown-linux-gnu
libdatadog-x64-windows
libdatadog-x86-windows
x86_64-alpine-linux-musl
x86_64-unknown-linux-gnu
|
BenchmarksComparisonBenchmark execution time: 2026-09-11 10:50:55 Comparing candidate commit 4e23227 in PR branch Found 15 performance improvements and 7 performance regressions! Performance is the same for 134 metrics, 0 unstable metrics.
|
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 does this PR do?
Adds a
level_overridesinput to the release-proposal dispatch, so a wrong bump level can be corrected by re-running the workflow from the Actions tab instead of checking the proposal branch out and running cargo-release by hand.release-version-bumps.shgains--level-overrides CRATE=LEVEL,...and uses the given level for those crates instead of callingsemver-level.sh— which is also where the run's time goes, so an overridden crate gets cheaper as well as corrected.It also records the dispatch inputs in an HTML comment at the top of the generated PR body:
<!-- release-proposal-inputs: {"crates":"libdd-capabilities-impl, libdd-ipc","main_start_ref":"","level_overrides":"libdd-capabilities=minor","bypass_standard_checks":false} -->so a follow-up run can reconstruct them without an operator retyping the crate list.
The second commit is unrelated to the feature and can be reviewed on its own: the
cargo-releasejob installed its four tools withtaiki-e/cache-cargo-install-action, which runscargo installand caches the result. On the last dispatch those four steps cost 703s of the job's 3660s, all cache misses.pr-title-semver-checkinstalls two of the same tools withtaiki-e/install-actionin 77s. Switched to install-action, and pinned all four —cargo-releaseandgit-cliffwere unpinned, which let the tools that choose version numbers and render changelogs drift under the workflow that cuts releases.Motivation
Reviewing release proposal #2482 turned up
libdd-capabilitiesproposed aspatchwhen itshttprequirement had moved from^1to^1.1. Fixing one crate's level meant a local checkout, a manualcargo release version, regenerating that crate's changelog, and a push — for a branch whose whole diff isCargo.tomlandCHANGELOG.mdfiles.Overriding the input rather than patching the branch is the point: the cascade, the changelogs and the publication order are all recomputed from the corrected level, so a level raised to
majorcan pull further crates into the release, which hand-editing the branch would miss.Additional Notes
cratesinput. The crate you most often need to correct was never named incrates— in chore(release): proposal for libdd-capabilities-impl, libdd-crashtracker, libdd-data-pipeline, li... #2482,libdd-capabilities,libdd-ipc-macrosandlibdd-tinybyteswere all pulled in transitively. A name that is not a candidate fails with the candidate list rather than silently shipping the computed level.level_overridesis carried in the inputs block so successive corrections accumulate instead of the newest one reverting the last. That is a correctness requirement, not a convenience.-->-proof.>is escaped to the JSON sequence\u003e, which decodes to the same character for a parser but can no longer terminate the HTML comment.main_start_refis the one value with no charset validation upstream.semver-level.sh; this input can setmajorexplicitly, and the row records the requested level so the PR body can show that a level was set by hand even if the cascade later raises it.check-proposal-ongoingrejects a dispatch while any proposal branch exists — including the branches of the proposal being corrected — so today this works on a fresh proposal, or after cancelling the open one by hand. A follow-up branch makes the guard permit replacing a proposal it can prove is the same release, and retires it once the replacement exists. Worth knowing when judging whether this is complete.Also not covered by tests:
release-version-bumps.batsexists on a separate branch (#2507) and has no case for the override path yet.How to test the change?
shellcheck -e SC2086 --severity=warning scripts/*.shThe validation runs before any
cargo release, so it can be exercised directly against a hand-written candidate file:--level-overrideslibdd-alphaCRATE=LEVELlibdd-alpha=minr=minornope=minorlibdd-alpha=minoron a deferred crate" a=minor , b=major "The PR-body block was rendered through the real jq filter, including a hostile
main_start_refofref--> <!-- evil, and round-trips back throughjqwith exactly one-->on the line.🤖 Generated with Claude Code