ci(fleet): guard example-suite tooling pins against drifting below the feature floor#427
Merged
Merged
Conversation
Each cascade-example repo bootstraps a cascade CLI in its scenario suite, pinned by hand to a fixed release. Nothing kept that pin moving forward, so a suite could sit on a release that predates a command it now invokes and fail a live fleet lane with a cryptic unknown-command error mid-fan-out. Add a shared check that fails when a suite's setup-cli pin is below the latest stable cascade release (the feature floor). Run it two ways: a daily Suite Tooling Floor workflow that surfaces drift off the release cadence, and a floor-check gate in fleet-e2e that reds an rc run before any repin or dispatch. A pin at or above the floor passes; a suite tracking a moving ref is not flagged. Signed-off-by: Joshua Temple <joshua.temple@stablekernel.com>
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
Closes #406. Adds a floor-consistency check so an example repo's scenario-suite setup-cli tooling pin can never silently drift below the current feature floor (the class that caused the 4env v0.5.1 and branch-protection v0.2.1 'unknown command' fleet failures).
Floor + mechanism
Floor = latest stable cascade release. The fleet repin rewrites each repo's manifest cli_version to the rc under test but never touches the suite's own stable setup-cli bootstrap pin; that pin is what drifts. Latest-stable is the right floor: every released command is present, and during an rc run the latest stable is the prior release (no chicken-and-egg with the unreleased rc), so at/above-floor suites pass. A moving ref (@main) is skipped; only strictly-below fails, so no false positives.
Current suites brought to floor (already live, bot-DCO)
All bumped to the current latest stable: 2env, artifact-a, 3env, single-env, release-only, no-env (from v0.2.1) and 4env (from v0.5.1). Already-current: primary, rollback-dispatch. No pin (@main, not flagged): artifact-b, callbacks. Each replacement targeted the exact stale value; scenario data literals untouched (0 collateral).
Fail-on-stale demonstration
FLOOR at current latest before bumps: FAIL exit 1, listed all 7 stale repos. FLOOR below all: PASS. After bumps: PASS, entire roster at/above floor, so the gate starts green and does not destabilize the fleet.
Verification
shellcheck + actionlint clean (fleet-e2e.yaml + suite-tooling-floor.yaml); no Go changed; injection-safe (floor passed via env); reuses CASCADE_STATE_TOKEN, no new secret.