ci: publish nightly CLI releases#14
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the CLI release pipeline to publish nightly GitHub Releases from main pushes using tags like v0.0.<next>-nightly.<YYYYMMDD>.<n>, and ensures nightly releases are marked as prerelease and not latest, with release titles matching the tag.
Changes:
- Extend ref/tag validation to allow both stable
vMAJOR.MINOR.PATCHand nightlyv0.0.N-nightly.YYYYMMDD.NUMBERformats. - Add a release “resolver” job to compute the nightly tag/title/flags on
main, and pass the resolved version into the build. - Update GitHub release publishing to set
--prereleaseand--latest=falsefor nightly releases and keep titles aligned with the tag.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| scripts/ci/resolve-cli-build-env.sh | Accepts nightly tags and supports resolving a nightly version on main (or using a provided CLI_VERSION). |
| .github/workflows/publish-cli.yml | Triggers publishing on main pushes, resolves nightly/stable release metadata, and publishes GitHub Releases with correct prerelease/latest settings. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Addressed the latest review feedback:
Left as acceptable:
|
swkeever
left a comment
swkeever
left a comment
There was a problem hiding this comment.
Found one actionable issue in the nightly release path.
| NIGHTLY_ALIAS_NOTES="$(printf 'Latest nightly build: %s\n\nCommit: %s' "$RELEASE_TITLE" "$GITHUB_SHA")" | ||
| git tag -f nightly "$GITHUB_SHA" | ||
| git push origin refs/tags/nightly --force | ||
| publish_release nightly "$RELEASE_TITLE" "$NIGHTLY_ALIAS_NOTES" --prerelease --latest=false |
There was a problem hiding this comment.
Publishing the nightly release here makes install.sh part of the alias assets, but the bundled installer still only accepts latest or stable vMAJOR.MINOR.PATCH selectors and only verifies tag-signed identities. VOLCANO_VERSION=nightly currently exits with unsupported Volcano CLI version selector: nightly; running this alias installer without that env installs the latest stable release instead. Please update the installer to support the nightly selector and the refs/heads/main signing identity, or omit/replace the installer asset for nightly releases.
There was a problem hiding this comment.
Valid catch. I updated scripts/install-volcano.sh so the bundled installer now supports VOLCANO_VERSION=nightly via /releases/download/nightly/..., accepts immutable nightly versions like v0.0.N-nightly.YYYYMMDD.NUMBER, and verifies nightly artifacts against the main-branch workflow identity (publish-cli.yml@refs/heads/main). Stable latest and stable tag behavior is unchanged.
marckong
left a comment
marckong
left a comment
There was a problem hiding this comment.
Review: nightly CLI releases (ci/nightly → main)
Summary: Extends the publish workflow to cut nightly prereleases from main pushes (v0.0.N-nightly.YYYYMMDD.M), adds a resolve-release job to compute the version/flags, and reworks release publishing into a reusable publish_release helper plus a moving nightly alias tag. The two prior Copilot findings are both addressed.
Verification of the addressed feedback:
- ✅ Recursion guard — the new
!v*.*.*-nightly.*trigger exclusion matches the generated tagv0.0.N-nightly.YYYYMMDD.M(positivev*.*.*matches, negative excludes), and thenightlyalias tag doesn't matchv*.*.*at all. The self-trigger loop is genuinely prevented. - ✅ Tag/version mismatch — the
refs/tags/*path inresolve-cli-build-env.shnow unconditionally setsCLI_VERSION="$REF_NAME", so an injectedCLI_VERSIONcan no longer desync the embedded version from the triggering tag. Therefs/heads/mainpath correctly requires the workflow-resolved value. - ✅ Serialized numbering —
concurrency: publish-cli-${{ github.ref_name }}withcancel-in-progress: falseserializes allmainruns under one group, soresolve-releasereads the prior run's pushed nightly tags before incrementing. The stated mitigation holds. - ✅
gh release edit(existing-release path) only runs afterviewsucceeds, and static notes for nightly / generated notes for stable are wired correctly.
Review: Looks correct and the prior feedback is properly resolved — no blocking findings. A couple of non-blocking observations:
- Each
mainpush creates a new permanentv0.0.N-nightly...tag + prerelease with no cleanup, so these will accumulate indefinitely. Appears intentional, but a retention/prune step may be worth a follow-up if the releases page gets noisy. gh release edit --target(used for the moving alias) is supported in currentgh; worth pinning/being aware of the runner'sghversion since it was flagged as version-dependent.
Overall correctness: CORRECT — existing stable-tag releases are unaffected, the new nightly path is self-consistent, and both reviewed issues are fixed without introducing new blocking bugs.
|
Addressed the installer review finding in
Validation:
|
Summary
nightlyrelease alias at/releases/tag/nightlywith the latest nightly assetsValidation