Add FLS to /release skill - #868
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe release skill guide now documents an FLS-aware release path: it detects current FLS pins and release state, recommends an FLS action, adds phased FLS release and pin-bump steps, updates pre-tag file handling, renumbers later release steps, and expands the post-release checklist. ChangesRelease skill FLS workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/release/SKILL.md:
- Around line 95-109: The FLS release decision logic should compare CARGO and
LATEST using SemVer precedence rather than string ordering. Update the
version-comparison guidance in the release skill so the step that selects the
next version and checks whether CARGO matches LATEST explicitly treats versions
like 0.10.0 vs 0.9.0 and prereleases correctly, referencing the CARGO, LATEST,
and AHEAD rules in the decision table.
- Around line 56-75: The local FLS path still depends on GitHub via the release
lookup, which breaks the preferred offline checkout flow. Update the
release-check logic in SKILL.md so the branch that uses the local FLS repo
derives LATEST_FLS from locally fetched tags in the FLS_DIR checkout and uses
git only there; keep the gh release view and GitHub API comparison strictly in
the no-checkout fallback path. Focus the change around the FLS_DIR conditional
and the LATEST_FLS assignment.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 03a32b44-c4e0-4204-835e-da8d6600e115
📒 Files selected for processing (1)
.claude/skills/release/SKILL.md
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/release/SKILL.md:
- Around line 73-76: The fallback release lookup currently uses gh release view
in the release script, which can pick the latest published release instead of
the highest SemVer tag. Update the LATEST_FLS lookup in the release skill to use
the tag list with SemVer sorting, matching the local path logic, so the compare
and pin decision are based on the correct baseline. Use the existing fallback
block around LATEST_FLS, gh api, and the compare step to locate the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fdace75f-aa71-4063-9d71-422b6a1ea32f
📒 Files selected for processing (1)
.claude/skills/release/SKILL.md
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/release/SKILL.md:
- Around line 64-77: The release check in the SKILL script is reading Cargo
version data from the local checkout and from a plain grep, which can pick up
the wrong branch state or the wrong version key. Update the logic around the FLS
tag/version lookup to read Cargo.toml from origin/main and parse the TOML field
explicitly, using the existing LATEST_FLS and CARGO_VER flow as the anchor
points. Keep the same release comparison/reporting behavior, but ensure both the
local and fallback paths source the version from main and not the current
working tree.
- Around line 168-178: The release instructions only cover final FLS versions,
so add a separate GitHub Release path for RC tags like X.Y.Z-rc.N. Update the
release guidance around the release creation step to use the existing release
flow from SKILL.md but explicitly call out `gh release create` with the
prerelease flag for RCs, while keeping final releases on the current
non-prerelease path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 4b2a849d-9d2f-453d-b2e8-54be93259a47
📒 Files selected for processing (1)
.claude/skills/release/SKILL.md
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/release/SKILL.md:
- Around line 29-33: The release flow diagram in SKILL.md shows GitHub Release
after CI builds, but the actual process creates the release immediately after
the tag push and then waits on build-images. Update the diagram near the release
phases so the GitHub Release step appears alongside the tag push before image
builds, matching the behavior described by the release flow and the build-images
sequence.
- Around line 203-214: The asset verification step is hard-coded to a single
example release, so it can check the wrong tag for RC or other versions. Update
the release verification in the release guide to use the version chosen earlier
in the flow (the same version used in Phase 0/step 1) instead of the fixed 0.4.0
value, and keep the guidance aligned with the existing FLS CI watch/confirm
sequence.
- Around line 71-76: The local FLS detection in the release skill is too
narrowly checking for a .git directory, which misses valid worktree-style
checkouts and can incorrectly fall back to GitHub. Update the conditional around
the FLS_DIR fetch/version logic in the release script to use a git
plumbing-based existence check instead of filesystem shape, while keeping the
existing git -C "$FLS_DIR" operations and LATEST_FLS/CARGO_VER flow intact.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fc93bdfb-48b5-4221-b46c-0817ab644686
📒 Files selected for processing (1)
.claude/skills/release/SKILL.md
Check if FLS needs a new release, if it does make one and update the pins Signed-off-by: Benny Zlotnik <bzlotnik@redhat.com> Assisted-by: grok-4.5
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/release/SKILL.md:
- Around line 110-125: The release decision logic in the FLS guide needs to
distinguish final SemVer releases from prereleases so RC cycles don’t get
redirected to the next patch line. Update the recommendation flow around the
version comparison using the FLS release/version symbols (`CARGO`, `LATEST`, and
the Phase 0 Cargo.toml example) so that when `LATEST` is an `X.Y.Z-rc.N` tag,
the suggested next version and bump text continue the same prerelease series
instead of defaulting to a patch bump of the final version. Keep the
final-release path unchanged, but branch the fallback and Cargo.toml bump
wording on final vs RC versions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c08583b9-edbe-443f-8715-030d7a931927
📒 Files selected for processing (1)
.claude/skills/release/SKILL.md
| 4. **Decide FLS action** from the gathered evidence. Compute: | ||
| - `PINNED` = `FLS_VERSION` in `python/Containerfile` (must match flashers CLI/`flash()` defaults; warn if they diverge) | ||
| - `LATEST` = latest FLS release tag (from local tags when using a checkout; otherwise GitHub tags with SemVer sort) | ||
| - `CARGO` = `version` in FLS `Cargo.toml` on `main` | ||
| - `AHEAD` = commits on `main` since `LATEST` (count + short log) | ||
|
|
||
| **Version comparisons must use SemVer precedence**, not string/lexicographic order. | ||
| Examples: `0.10.0 > 0.9.0`; prereleases sort below the matching final (`0.4.0-rc.1 < 0.4.0`). | ||
| Prefer `git tag --sort=-version:refname`, `sort -V`, or an equivalent SemVer library — never raw string `>` / `<`. | ||
|
|
||
| Recommend exactly one action: | ||
|
|
||
| | Condition | Recommendation | | ||
| |---|---| | ||
| | `AHEAD > 0` (unreleased commits on FLS `main`) | **Cut new FLS release** (step 2B Phase 0), then bump Jumpstarter pins. Suggest next version: if SemVer(`CARGO`) > SemVer(`LATEST`), use `CARGO`; otherwise propose a patch bump of `LATEST`. | | ||
| | `AHEAD == 0` and `PINNED != LATEST` | **Bump pins only** to `LATEST` (no new FLS release needed). | |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Handle RC FLS releases as a separate version line.
The current fallback says “patch bump LATEST” whenever CARGO <= LATEST, but this guide also supports X.Y.Z-rc.N releases. That can steer an RC cycle onto X.Y.(Z+1) instead of continuing the same prerelease series, and the Phase 0 Cargo example still shows only a final version. Please make the recommendation and the Cargo.toml bump text branch on final vs RC releases so prerelease cycles stay on the correct version line.
Suggested fix
-| `AHEAD > 0` (unreleased commits on FLS `main`) | **Cut new FLS release** (step 2B Phase 0), then bump Jumpstarter pins. Suggest next version: if SemVer(`CARGO`) > SemVer(`LATEST`), use `CARGO`; otherwise propose a patch bump of `LATEST`. |
+| `AHEAD > 0` (unreleased commits on FLS `main`) | **Cut new FLS release** (step 2B Phase 0), then bump Jumpstarter pins. Suggest next version: if SemVer(`CARGO`) > SemVer(`LATEST`), use `CARGO`; otherwise, if `LATEST` is an RC, advance the RC suffix on the same base version; else propose a patch bump of `LATEST`. |
-1. **Bump `Cargo.toml` version** to the new FLS version (no `v` prefix), e.g. `version = "0.4.0"`.
+1. **Bump `Cargo.toml` version** to the new FLS version (no `v` prefix), e.g. `version = "0.4.0"` or `version = "0.4.0-rc.1"` for RCs.Also applies to: 180-200
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/skills/release/SKILL.md around lines 110 - 125, The release decision
logic in the FLS guide needs to distinguish final SemVer releases from
prereleases so RC cycles don’t get redirected to the next patch line. Update the
recommendation flow around the version comparison using the FLS release/version
symbols (`CARGO`, `LATEST`, and the Phase 0 Cargo.toml example) so that when
`LATEST` is an `X.Y.Z-rc.N` tag, the suggested next version and bump text
continue the same prerelease series instead of defaulting to a patch bump of the
final version. Keep the final-release path unchanged, but branch the fallback
and Cargo.toml bump wording on final vs RC versions.
Check if FLS needs a new release, if it does make one and update the pins