From b376cab92a2bcfdc2868b08706517adc498c2ea7 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 5 Jun 2026 16:30:20 -0400 Subject: [PATCH 1/2] chore(skills): update cutting-releases for fullsend-ai @main switch fullsend-ai/.fullsend now references reusable workflows via @main instead of @v0. This means: - Pre-flight: fullsend-ai runs are now a signal that main is healthy before moving the v0 tag (new step E) - Post-flight: fullsend-ai runs no longer tell us anything about v0 resolution, so step C is replaced with an explanatory note and downstream verification is moved to step D with inline commands Assisted-by: Claude Opus 4.6 Signed-off-by: Ralph Bean --- skills/cutting-releases/post-flight.md | 61 ++++++++++++-------------- skills/cutting-releases/pre-flight.md | 32 +++++++++++--- 2 files changed, 56 insertions(+), 37 deletions(-) diff --git a/skills/cutting-releases/post-flight.md b/skills/cutting-releases/post-flight.md index e565f86ca..edba8bb1a 100644 --- a/skills/cutting-releases/post-flight.md +++ b/skills/cutting-releases/post-flight.md @@ -4,7 +4,7 @@ Part of the [cutting-releases](SKILL.md) skill. Run after the version tag is pushed, the `v0` tag is moved, and the CI workflows complete. Focus on the areas identified during pre-flight -step E. +step F. ## A. Wait for CI workflows @@ -29,49 +29,44 @@ gh release view Check that the title, changelog, and binary assets look correct. Verify the release is not marked as a draft. -## C. Check fullsend-ai repos +## C. Note on fullsend-ai repos -The skill user is a fullsend repo admin, so fullsend-ai org repos -are always accessible. Check recent workflow runs in the org's repos -that consume `@v0` reusable workflows: +The `fullsend-ai/.fullsend` repo references reusable workflows via +`@main`, not `@v0`. Its runs do **not** exercise the `v0` tag and +cannot confirm that the tag move worked. (Those runs are checked +during pre-flight instead, as a signal that `main` is healthy.) -``` -gh run list --repo fullsend-ai/fullsend --limit=3 -gh run list --repo fullsend-ai/.fullsend --limit=3 -``` - -Look for runs that started **after** the `v0` tag move. Confirm they -completed without workflow-resolution errors (e.g. "could not find -reusable workflow"). If no runs occurred naturally, check for any -recent failed or cancelled runs that can be retriggered: +Skip fullsend-ai for post-flight `v0` verification. Focus on other +downstream consumers in step D. -``` -gh run list --repo fullsend-ai/.fullsend --status=failure --limit=3 -``` +## D. Check additional downstream repos (optional) -Present any candidate to the user for confirmation before retriggering: +Use `AskUserQuestion` to ask if the user has access to additional +downstream orgs: -> I found run `` (failed) in `fullsend-ai/.fullsend`. -> Retrigger it to verify `@v0` resolves? +> Do you have access to any other downstream orgs/repos to verify? +> (e.g. "konflux-ci, redhat-developer/rhdh-agentic") +> Leave blank to skip. -Once confirmed: +For each repo provided, check recent workflow runs that started +**after** the `v0` tag move: ``` -gh run rerun --failed --repo fullsend-ai/.fullsend +gh run list --repo --limit=5 ``` -## D. Check additional downstream repos (optional) +Confirm they completed without workflow-resolution errors (e.g. +"could not find reusable workflow"). If no runs occurred naturally, +check for recent failed runs that can be retriggered: -Use `AskUserQuestion` to ask if the user has access to additional -downstream orgs: +``` +gh run list --repo --status=failure --limit=3 +``` -> Do you have access to any other downstream orgs/repos to verify? -> (e.g. "konflux-ci, redhat-developer/rhdh-agentic") -> Leave blank to skip. +Present any candidate to the user for confirmation before retriggering. -If the user provides repos, repeat the same checks from step C for -each one. If blank, skip this step — not all admins have access to -every enrolled org. +If blank, skip this step — not all admins have access to every +enrolled org. ## E. Present post-flight summary @@ -79,9 +74,11 @@ Summarize results to the user: | Org/Repo | `@v0` Refs | Status | |----------|-----------|--------| -| fullsend-ai/.fullsend | Confirmed | Passing | | ... | ... | ... | +Note: `fullsend-ai` repos are excluded from this table — they use +`@main` and were checked during pre-flight. + Distinguish between: - **Release-related failures** — workflow resolution errors, missing secrets, or permission failures caused by the tag move. diff --git a/skills/cutting-releases/pre-flight.md b/skills/cutting-releases/pre-flight.md index ae9e3e74f..b573950fc 100644 --- a/skills/cutting-releases/pre-flight.md +++ b/skills/cutting-releases/pre-flight.md @@ -102,13 +102,31 @@ gh run list --branch=main --limit=5 All recent runs should be passing. If E2E tests are failing, investigate before releasing. -## E. Identify post-flight check areas +## E. Check fullsend-ai runs as a main-branch signal + +The `fullsend-ai/.fullsend` repo references reusable workflows via +`@main` (not `@v0`). This means its recent runs already exercise the +exact commit we are about to tag. Use this as a pre-flight signal: + +``` +gh run list --repo fullsend-ai/.fullsend --limit=5 +gh run list --repo fullsend-ai/fullsend --limit=5 +``` + +If recent runs are passing, that is evidence the reusable workflows on +`main` work correctly and moving `v0` to this commit is low-risk. + +If recent runs are failing, investigate whether the failures are related +to reusable workflow changes. Workflow-resolution errors or permission +failures are blockers. Unrelated agent runtime errors are not. + +## F. Identify post-flight check areas Based on the changes found in steps A–C, determine what needs post-flight verification after the `v0` tag moves: -- **Reusable workflow changes** → verify workflow runs in fullsend-ai - repos resolve `@v0` correctly and pass. +- **Reusable workflow changes** → verify workflow runs in downstream + `@v0` consumers (outside fullsend-ai) resolve correctly and pass. - **New secrets or permissions** → verify affected workflows don't fail on missing secrets. - **CLI default changes** → note migration steps for existing @@ -116,7 +134,11 @@ post-flight verification after the `v0` tag moves: - **No reusable workflow changes** → post-flight can be limited to confirming the release artifacts built correctly. -## F. Present summary +Note: `fullsend-ai/.fullsend` uses `@main`, not `@v0`, so its runs +are not useful for post-flight `v0` verification. Post-flight checks +should focus on other downstream consumers that reference `@v0`. + +## G. Present summary Summarize findings to the user in a table: @@ -126,6 +148,6 @@ Summarize findings to the user in a table: | Scaffold templates | ... | No/Yes | | CLI / internal | ... | No/Yes | -List the post-flight check areas identified in step E. +List the post-flight check areas identified in step F. Give a **GO / NO-GO** verdict. Do not proceed until the user confirms. From 9e42931667d96c2435d8dbd912e3c0e1e387467d Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 5 Jun 2026 16:42:01 -0400 Subject: [PATCH 2/2] chore(skills): address review feedback on post-flight doc - Rename heading to "Skip fullsend-ai repos" to match action-verb pattern - Add rerun command template and prompt to step D for self-containment Assisted-by: Claude Opus 4.6 Signed-off-by: Ralph Bean --- skills/cutting-releases/post-flight.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/skills/cutting-releases/post-flight.md b/skills/cutting-releases/post-flight.md index edba8bb1a..7bd92cd66 100644 --- a/skills/cutting-releases/post-flight.md +++ b/skills/cutting-releases/post-flight.md @@ -29,7 +29,7 @@ gh release view Check that the title, changelog, and binary assets look correct. Verify the release is not marked as a draft. -## C. Note on fullsend-ai repos +## C. Skip fullsend-ai repos The `fullsend-ai/.fullsend` repo references reusable workflows via `@main`, not `@v0`. Its runs do **not** exercise the `v0` tag and @@ -63,7 +63,16 @@ check for recent failed runs that can be retriggered: gh run list --repo --status=failure --limit=3 ``` -Present any candidate to the user for confirmation before retriggering. +Present any candidate to the user for confirmation before retriggering: + +> I found run `` (failed) in ``. +> Retrigger it to verify `@v0` resolves? + +Once confirmed: + +``` +gh run rerun --failed --repo +``` If blank, skip this step — not all admins have access to every enrolled org.