fix(release): separate release PRs and bootstrap fleet-agent at 0.1.0#382
Merged
Conversation
Two issues in the fleet-agent release train from #381: 1. release-please defaulted to one combined release PR covering both the main arcbox and fleet-agent components, so their versions had to be bumped and merged together — defeating the independent release cadence. 2. With the fleet manifest seeded at 0.0.0, release-please treats the component as unreleased and hard-codes the first tag to 1.0.0, ignoring bump-minor-pre-major. Enable separate-pull-requests so release-please opens one PR per component, and one-shot release-as: 0.1.0 on the fleet package so its bootstrap tag is fleet-agent-v0.1.0. Once that first release cuts, the release-as override should be removed so subsequent fleet releases advance via normal bump rules (0.1.0 + fix -> 0.1.1, 0.1.0 + feat -> 0.1.1 under bump-patch-for-minor-pre-major).
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes — a config-only fix to release-please-config.json addressing two release-please behaviors that surfaced after the fleet-agent / main-arcbox release split in #381.
- Split release PRs —
separate-pull-requests: trueat the top level replaces release-please's default combined manifest PR with one PR per component, restoring the independent release cadence #381 set up. - Bootstrap fleet-agent at
0.1.0—release-as: "0.1.0"on thefleetpackage forces the first tag to exactlyfleet-agent-v0.1.0, overriding release-please's default of hard-coding an unreleased component's first release to1.0.0.
Both keys are valid release-please manifest options, and the resulting fleet-agent-v0.1.0 tag matches the fleet-agent-v* push trigger in .github/workflows/release-fleet-agent.yml. The PR body accurately describes the post-merge behavior.
ℹ️ release-as is sticky and depends on a follow-up removal
release-as: "0.1.0" forces that version on every subsequent release-please run, not just the bootstrap — release-please will keep proposing 0.1.0 until the line is removed. The PR body already documents the required follow-up PR to delete it once fleet-agent-v0.1.0 is cut, so this is purely a reminder that the cleanup is load-bearing: if it's forgotten, fleet-agent releases will stall at 0.1.0 rather than advancing via the normal bump rules. No change needed here.
Claude Opus ｜ 𝕏
Greptile SummaryThis PR adjusts release-please behavior for the split fleet release. The main changes are:
Confidence Score: 5/5This looks safe to merge. No blocking issues found in the changed code.
 T-Rex LogsWhat T-Rex did
Important Files Changed
Reviews (1): Last reviewed commit: "fix(release): separate release PRs and b..." | Re-trigger Greptile |
PeronGH
added a commit
that referenced
this pull request
Jul 14, 2026
The Cargo.lock refresh step in release-please.yml was gated on steps.release.outputs.pr (singular), which under separate-pull-requests only ever exposes one of the release PRs. On master's post-#382 run the step successfully bumped Cargo.lock on the main-only PR #379 but never touched fleet-agent PR #383, which is why #383 shipped with a stale lockfile and would fail `cargo build --release --locked`. Switch to iterating steps.release.outputs.prs (array of every currently open release PR) and refresh Cargo.lock on each independently. Each iteration is scoped to its own temp workdir and git config is set once at the outer shell. This replaces the earlier attempt on this branch to enable the cargo-workspace release-please plugin. That plugin was suspected of misbehaving against this repo's virtual-workspace layout (root [workspace]-only manifest, members using version.workspace = true, inter-crate versions pinned via # x-release-please-version generic extra-files). The workflow step is a proven mechanism — the log from the last release-please run showed it correctly refreshing 51 packages on the main release PR — it just wasn't iterating.
PeronGH
added a commit
that referenced
this pull request
Jul 14, 2026
The Cargo.lock refresh step in release-please.yml was gated on steps.release.outputs.pr (singular), which under separate-pull-requests only ever exposes one of the release PRs. On master's post-#382 run the step successfully bumped Cargo.lock on the main-only PR #379 but never touched fleet-agent PR #383, which is why #383 shipped with a stale lockfile and would fail `cargo build --release --locked`. Switch to iterating steps.release.outputs.prs (array of every currently open release PR) and refresh Cargo.lock on each independently. Each iteration is scoped to its own temp workdir and git config is set once at the outer shell. This replaces the earlier attempt on this branch to enable the cargo-workspace release-please plugin. That plugin was suspected of misbehaving against this repo's virtual-workspace layout (root [workspace]-only manifest, members using version.workspace = true, inter-crate versions pinned via # x-release-please-version generic extra-files). The workflow step is a proven mechanism — the log from the last release-please run showed it correctly refreshing 51 packages on the main release PR — it just wasn't iterating.
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.
Follow-up to #381. Two issues surfaced once release-please processed the split.
Issue 1 — combined release PR
release-please's default is a single manifest-wide release PR, so PR #379 currently bundles both:
0.4.17 → 0.4.180.0.0 → 1.0.0They must be merged together, which defeats the independent release cadence that #381 set up.
separate-pull-requests: trueat the top level splits this into one PR per component.Issue 2 — fleet-agent bootstraps at
1.0.0instead of0.1.0With the fleet manifest seeded at
0.0.0, release-please treats the component as unreleased and hard-codes the first tag to1.0.0, ignoringbump-minor-pre-major. Neither0.0.1nor0.1.0as a seed produces0.1.0as the first release under the current bump flags.A one-shot
"release-as": "0.1.0"on the fleet package forces the bootstrap tag to be exactlyfleet-agent-v0.1.0.After merge
chore(main): release 0.4.18chore(fleet-agent): release 0.1.0.github/workflows/release-fleet-agent.ymlwith tagfleet-agent-v0.1.0.fleet-agent-v0.1.0is cut, a follow-up PR should remove therelease-asline so subsequent fleet releases advance via the normal bump rules (0.1.0 + fix → 0.1.1,0.1.0 + feat → 0.1.1underbump-patch-for-minor-pre-major).