fix: install soothfast 0.3.2 in CI - #493
Merged
Merged
Conversation
- The soothfast action resolves the CLI version from Cargo.lock, not from its own pinned ref, so CI was still installing 0.3.0. - 0.3.2 filters the bot's own commits out of the generated changelog.
Verdenroz
enabled auto-merge (squash)
September 12, 2026 02:19
Contributor
soothfast gatefinance-query |
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.
Description
#480 was closed by bumping the pinned soothfast action SHA to v0.3.2, and the first bot regeneration after that merge put the bot's own commits straight back into the changelog. The action picks which cargo-soothfast to install by grepping
Cargo.lock, not from its own pinned ref, andCargo.lockstill said 0.3.0. That made the SHA bump inert: the action's ownaction.ymland shell scripts are byte-identical between 0.3.1 and 0.3.2, so the CLI version named in the lockfile is the only thing that changes behavior. This moves the lockfile entry to 0.3.2, the release that filterssoothfast-bot[bot]out of the generated changelog.Type of Change
Changes
soothfastentry inCargo.lockfrom 0.3.0 to 0.3.2 withcargo update -p soothfast --precise 0.3.2.soothfast-macros,soothfast-measure, andsoothfast-registryfrom 0.3.0 to 0.3.2 in the same update. They are versioned in lockstep withsoothfastand are reachable only through it, as a dev-dependency of the three workspace crates. No package outside that subtree changed.Cargo.tomlalone. It declaressoothfast = { version = "0.3", features = ["runner"] }, and the caret requirement already admits 0.3.2.Breaking Changes
None.
soothfastis a dev-dependency used by the benchmark and living-docs tooling, so nothing in the published library or server graph is affected.Testing
cargo test)cargo metadata --locked --format-version 1exits 0, so the lockfile is self-consistent and nothing else needs resolving.prek run --files Cargo.lockpasses: large-file check, TOML check, end-of-file fixer, trailing-whitespace, and mixed-line-ending all ran and passed; the Rust and YAML hooks skipped with no matching files. No build or test suite was run, since the change only rewrites the lockfile.The real signal is post-merge. After the next bot regeneration lands on master,
CHANGELOG.md'sInternalsection must no longer gainRegenerate soothfast outputsorRegenerate derived artifactslines, andDependenciesmust still list its dependabot entries (Bump debian from ...,Bump rust from ...). The already-committed lines from earlier regenerations are expected to disappear as well, because the generator rewrites the whole Unreleased section rather than appending to it. If the dependabot entries disappear too, the filter over-matches and this should be reverted.Documentation
Checklist
cargo check)cargo test)cargo fmt)cargo clippy)cargo doc --no-deps)Related Issues
Closes #480