Skip to content

fix(ci): base nightly version on current stable, not v0.0.x line - #138

Merged
tkkhq merged 2 commits into
mainfrom
fix/nightly-version-base
Jul 29, 2026
Merged

fix(ci): base nightly version on current stable, not v0.0.x line#138
tkkhq merged 2 commits into
mainfrom
fix/nightly-version-base

Conversation

@tkkhq

@tkkhq tkkhq commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Problem

  • nightly builds from main are versioned v0.0.6-nightly.<date>.<seq> even though stable is already at v0.16.0; the Resolve release version step derives the nightly number by scanning only the v0.0.* tag glob (git tag --list 'v0.0.*' + ^v0\.0\.[0-9]+$), whose max is the frozen v0.0.5, so every nightly is stuck at 0.0.6 and sorts below the real stable line

Summary

  • derive the nightly base from package.json (the version release-please keeps in sync, already trusted as the source of truth on the stable path) instead of the v0.0.* tag glob, then bump the patch: stable 0.16.0 -> v0.16.1-nightly.<date>.<seq>
  • strip any prerelease suffix and validate the base is X.Y.Z before use, failing closed with a clear message if package.json is malformed
  • leave the per-day sequence-counting loop and all downstream release logic untouched; only the version prefix derivation changes

Verification

  • actionlint .github/workflows/publish-cli.yml (the two shellcheck infos on lines 69/259 are pre-existing and unrelated: SC2295 in the untouched seq-counting loop, SC2035 in publish-github-release)
  • extracted the derivation into a standalone shell function and asserted across 0.16.0 -> v0.16.1, 0.0.5 -> v0.0.6 (old behavior reproducible), 1.2.3 -> v1.2.4, 0.16.9 -> v0.16.10 (double-digit patch), and 2.0.0-rc.1 -> v2.0.1 (prerelease stripped)
  • confirmed the resulting tag is a proper semver prerelease of the next stable, so it sorts above the current stable and below the eventual release (0.16.0 < 0.16.1-nightly.X < 0.16.1)

Copilot AI review requested due to automatic review settings July 29, 2026 15:50
@tkkhq
tkkhq requested a review from a team as a code owner July 29, 2026 15:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates nightly releases to track the current stable version from package.json.

Changes:

  • Derives the nightly base version from package.json.
  • Validates components and increments the patch version.
  • Preserves existing nightly sequence logic.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/workflows/publish-cli.yml Outdated
BASE_MAJOR="${BASE_VERSION%%.*}"
BASE_MINOR="${BASE_MINOR_PATCH%%.*}"
BASE_PATCH="${BASE_MINOR_PATCH#*.}"
if ! printf '%s.%s.%s' "$BASE_MAJOR" "$BASE_MINOR" "$BASE_PATCH" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+$'; then

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 04ec2a6 — switched to (0|[1-9][0-9]*) per component, matching validate-release-ref's STABLE_SEMVER_RE at line 34, so leading zeroes are rejected. Also moved the check to validate the raw version string before splitting (rather than the reconstructed components): the old placement let a two-component value like 1.2 fabricate 1.2.2 and pass, and this ordering additionally keeps the $(( BASE_PATCH + 1 )) bump off a bad octal literal like 08. Verified across 01.2.3/0.16.08/1.2/1.2.3.4/abc -> reject and the valid cases -> correct bump.

@tkkhq tkkhq left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review — PR #138: fix(ci): base nightly version on current stable, not v0.0.x line

Verification: No user-level verificationBaselines are configured, so pr_review_verify is disabled (platform darwin); nothing was built or run in a sandbox. I validated the change by static analysis: read the full resolve-release step plus every downstream consumer of cli_version/release_tag (build-binaries, publish-github-release, publish-npm) in .github/workflows/publish-cli.yml, and traced the shell parameter-expansion parsing against the edge cases in the PR description (0.16.0, 0.0.5, 0.16.9, 2.0.0-rc.1).

Overview

This PR fixes nightly version derivation in the resolve-release step of .github/workflows/publish-cli.yml. Previously the nightly base was computed by scanning only the v0.0.* git tag glob, whose max was the frozen v0.0.5, so every nightly was stuck at v0.0.6-nightly.* and sorted below the real stable line (already at v0.16.0).

The new logic reads the current version from package.json (kept in sync by release-please), strips any prerelease suffix, splits it into major/minor/patch via shell parameter expansion, validates the result is numeric X.Y.Z (failing closed with a clear message otherwise), then bumps the patch to build NIGHTLY_PREFIX="v{MAJOR}.{MINOR}.{PATCH+1}-nightly.{date}.". The per-day sequence-counting loop and all downstream release logic are untouched.

The result is a valid semver prerelease of the next patch (e.g. 0.16.0 -> v0.16.1-nightly.<date>.<seq>), which sorts above current stable and below the eventual release. The new prefix also never collides with pre-existing v0.0.* nightly tags since the seq loop only lists ${NIGHTLY_PREFIX}*.

Strengths

  • Correct root-cause fix: derives from package.json (the same source release-please already trusts on the stable path) instead of a hardcoded tag glob, so nightlies now track the real release line automatically.
  • Fails closed — the parsed components are re-validated against ^[0-9]+\.[0-9]+\.[0-9]+$ and the step exits 1 with a clear message on a malformed version, rather than silently emitting a bad tag.
  • Tight scope: only the version-prefix derivation changes; the sequence-counting loop and all downstream jobs (build, GitHub release, npm publish) are left intact, and npm publish stays gated to stable releases only.
  • A clear comment explains why the change was made (the v0.0.6 freeze) and the intended sort ordering.

Findings — 1 total (0 inline, 1 summary-only)

Severity Summary-only finding Location
nit [nit] Consider parsing the version in the already-spawned node call .github/workflows/publish-cli.yml:81-86 RIGHT

[nit] Consider parsing the version in the already-spawned node call

.github/workflows/publish-cli.yml:81-86 RIGHT

The version is read with node -p and then split into major/minor/patch with a chain of shell parameter expansions (.github/workflows/publish-cli.yml lines 81-86). Since node is already invoked, the split-and-strip could be done there in one line (e.g. node -p "require('./package.json').version.split('-')[0]" then split), which removes the fragile expansion chain. This is purely optional — the current code is correct for any valid npm X.Y.Z version, and the explicit grep validation already fails closed on malformed input.

Correctness / Security / Performance

  • Correctness: Parsing and patch-bump produce valid semver prereleases for all realistic package.json versions; malformed input fails closed via the numeric X.Y.Z validation.
  • Security: No security-relevant change; reads a trusted repo file and derives a tag string.
  • Performance: No performance impact; replaces a tag-glob scan with a single package.json read.

Verdict

Suggested verdict: approve

The change correctly bases nightly versions on the current stable version from package.json, validates the parsed version and fails closed on malformed input, and leaves the sequence loop and all downstream jobs untouched. No blocking defects found; only one optional style nit.

Confidence: 0.90

@tkkhq
tkkhq merged commit 955cc74 into main Jul 29, 2026
9 checks passed
@tkkhq
tkkhq deleted the fix/nightly-version-base branch July 29, 2026 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants