Skip to content

ci(release): add canary upgrade coverage #1981

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
krishicks wants to merge 1 commit into
base: main
Choose a base branch
from
+328 −22
Draft

ci(release): add canary upgrade coverage #1981

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions .agents/skills/test-release-canary/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,11 @@ on:
- **Automatic.** Every successful `Release Dev` run (on `main` or a manual dispatch of Release Dev) fires the canary. Each job gates on `github.event.workflow_run.conclusion == 'success'` so a failed Release Dev does not run the canary.
- **Manual.** `workflow_dispatch` lets you run the canary on demand against any branch's workflow definition.

When dispatched manually, `github.event.workflow_run.head_sha` is empty and the workflow falls back to `github.sha` (the branch tip) for the `install.sh` URL.
Stable installs use `STABLE_INSTALL_SH_URL`, which always points at
`main/install.sh`. Dev installs use `DEV_INSTALL_SH_URL`: automatic runs point
at the moving `dev` tag so the installer matches the published development
release, while manual dispatches use the dispatched ref name so branch changes
to the canary or dev installer can still be exercised.

## Manual dispatch

Expand All @@ -59,9 +63,12 @@ gh run view <run-id> --log-failed

## Iterating on the canary itself

When you change `release-canary.yml` on a branch, a manual dispatch on that branch tests *your branch's workflow logic* against *main's published artifacts* (`0.0.0-dev` chart, `:dev` images, latest tagged install.sh assets). This is what you want for iterating on the canary — you're validating that the canary still works against known-good artifacts.
When you change `release-canary.yml` on a branch, a manual dispatch on that branch tests *your branch's workflow logic* against *main's published stable artifacts* and the current published dev artifacts (`0.0.0-dev` chart, `:dev` images). This is what you want for iterating on the canary — you're validating that the canary still works against known-good artifacts.

Note `install.sh` is pulled from `raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh`, so changes to `install.sh` on your branch *are* exercised even though the binaries it downloads are from the latest public tag.
Note stable package installs always pull `install.sh` from `main`, while dev
package installs pull `install.sh` from the dispatched branch ref for manual
runs. Changes to dev installer behavior on your branch are exercised without
using that new installer to install an older stable release.

## Testing artifacts from a specific SHA

Expand Down
Loading
Loading