ci: add Release Please stable release flow with GitHub App token [VOL-367]

[tkkhq]

Summary

Add a Release Please flow so stable CLI releases are cut from Conventional Commits on main via a release PR, and make publish-cli publish only from the resulting stable tag. Release Please authenticates with a short-lived GitHub App token instead of a personal access token, so the release tag/release triggers the tag-driven publish workflow without depending on an individual's credentials (VOL-367).

Why

• Stable versioning was manual; Release Please derives the next SemVer bump from Conventional Commits and opens a release PR.
• The default GITHUB_TOKEN cannot trigger follow-on workflows, so the release tag would not start publish-cli. A non-default token is required; a GitHub App token replaces the PAT and is not tied to a person.

Changes

• Add release-please-config.json and .release-please-manifest.json (@volcano.dev/cli, node release-type). Baseline reconciled to the already-published 0.1.0: bootstrap-sha points at the v0.1.0 commit, the manifest and package.json are set to 0.1.0, and richer changelog sections plus a Conventional-Commit release-PR title are configured.
• Add .github/workflows/release-please.yml: mint an installation token via actions/create-github-app-token (SHA-pinned, down-scoped to contents/pull-requests/issues) from VOLCANO_APP_ID (variable) and VOLCANO_APP_KEY (secret), run Release Please, and enable squash auto-merge on the release PR. Adds workflow_dispatch, a concurrency group, and a job timeout.
• publish-cli.yml: publish stable releases only from tags, validate the tag is stable SemVer (vMAJOR.MINOR.PATCH), reachable from origin/main, and matches package.json; reject tag/package.json drift; nightly builds from main are unchanged. Publish to npm with --provenance and fail the release on a publish error (trusted publishing is live).
• SHA-pin all first- and third-party actions in the release/publish workflows and add a github-actions Dependabot config to keep the pins current.
• Document the release process and the required App variable/secret in CONTRIBUTING.md.

Requirements

• VOLCANO_APP_ID (repository variable) and VOLCANO_APP_KEY (repository secret): a GitHub App installed on this repo with Contents and Pull requests read/write.
• VOLCANO_FIRST_PARTY_DEVICE_CLIENT_ID_PRODUCTION.

Release flow

1. Feature PRs merge to main.
2. release-please maintains a release PR that bumps package.json and CHANGELOG; squash auto-merge is armed on it.
3. Once the release PR has the required approval and green checks, it auto-merges and Release Please cuts the vX.Y.Z tag and GitHub Release.
4. The tag triggers publish-cli.yml: validate the tag, build and cosign-sign the multi-platform binaries, upload release assets and SHA256SUMS, and publish to npm via OIDC trusted publishing.

Verification

• git diff --check
• Parsed the Release Please JSON config and manifest
• bash -n on the release/publish shell steps
• npm pack --dry-run --ignore-scripts
• make build FIRST_PARTY_DEVICE_CLIENT_ID=volcano-cli VERSION=v0.1.0 and ./volcano --version
• CI green (check, localmode-e2e, CodeQL, analyze matrix)

[Copilot]

Pull request overview

This PR introduces a Release Please–based stable release flow. It adds Release Please configuration and a workflow that opens/updates release PRs on main, and refactors publish-cli.yml so it triggers only on SemVer tags (removing the previous main-branch/nightly path). Version integrity is now enforced by requiring the tag to match package.json. Documentation is updated to describe the new process and the required RELEASE_PLEASE_TOKEN.

Changes:

• Add release-please-config.json and .release-please-manifest.json (seeded at 0.0.4, matching package.json) plus a release-please.yml workflow using a PAT so tags trigger follow-on workflows.
• Make publish-cli.yml tag-only: drop the main trigger and nightly build/alias logic, and reject tag ↔ package.json version drift.
• Update CONTRIBUTING.md to document the Release Please process and required token/variable.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
release-please-config.json	Defines the root node package, tag format, and changelog path for Release Please.
.release-please-manifest.json	Seeds the tracked version at 0.0.4.
.github/workflows/release-please.yml	Adds the workflow that creates/updates release PRs and tags via a PAT.
.github/workflows/publish-cli.yml	Switches to tag-only publishing, adds version-match validation, removes nightly logic and now-unused append_historical_assets.
CONTRIBUTING.md	Documents the new Release Please release process and required secret/variable.

---

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

[tkkhq]

Code Review — PR #38: ci: add Release Please stable release flow with GitHub App token [VOL-367]

Verification: No baseline verification was run: pr_review_verify reported verification disabled because no user-level verificationBaselines are configured (platform darwin). No PR code was executed, so the unsandboxed-PR-code risk was not exercised. Review is source-grounded: I independently fetched the full publish-cli.yml at head SHA ef84306 to confirm the nightly early-exit and trigger-filter claims, and the heavy passes confirmed the release-please config, manifest/package.json (both 0.1.0), bootstrap-sha ancestry, and SHA pins against upstream tags.

Overview

This PR introduces a Release Please based stable-release flow for the CLI. It adds release-please-config.json (node release-type, @volcano.dev/cli, changelog sections) and .release-please-manifest.json (seeded at 0.1.0), plus .github/workflows/release-please.yml, which runs on pushes to main/workflow_dispatch, mints a short-lived GitHub App installation token (down-scoped to contents/pull-requests/issues) via actions/create-github-app-token, runs release-please-action, and enables squash auto-merge on any created release PR. A GitHub App token is used instead of the default GITHUB_TOKEN specifically so the release tag/release triggers the follow-on publish workflow.

publish-cli.yml is refactored so stable publishing happens only from stable SemVer tags: the removed nightly regex in validate-release-ref is inert (that job early-exits for main, and nightly tags are excluded by the !v*.*.*-nightly.* trigger filter), resolve-release now reads package.json via a newly added setup-node and rejects tag/package.json drift, the old imperative npm version step is replaced by a verify-only guard, and npm publish now runs --provenance --access public with continue-on-error removed now that OIDC trusted publishing is live. All third-party actions are pinned to commit SHAs with trailing version comments and a new dependabot.yml keeps them current. CONTRIBUTING.md documents the flow and required App variable/secret; package.json is bumped 0.0.5 -> 0.1.0.

The nightly-from-main path is preserved unchanged, and the stable tag-driven flow is internally consistent across validate-release-ref, resolve-release, and publish-npm.

Strengths

• All third-party GitHub Actions are pinned to commit SHAs with matching version comments, and a new dependabot.yml group keeps the pins current — verified pins match upstream tags.
• The GitHub App token is explicitly down-scoped (permission-contents/pull-requests/issues: write) and the workflow default token is least-privilege contents: read, with the PEM in a secret and app-id in a repo variable.
• The stable tag <-> package.json version-match guard is consistent across resolve-release and publish-npm, and replaces the imperative npm version mutation with a fail-loud verify-only check.
• npm publish --provenance --access public with OIDC trusted publishing (no NPM_TOKEN) and removal of continue-on-error so publish failures now fail the release.
• Nightly-from-main is deliberately preserved: validate-release-ref early-exits on main and nightly tags are excluded at the trigger, so removing NIGHTLY_SEMVER_RE breaks nothing.
• release-please.yml serializes runs via a stable concurrency group with cancel-in-progress: false, bounds runtime with timeout-minutes: 10, and consumes RELEASE_PRS via env: (not inline ${{ }}) with numeric jq parsing — no injection surface.
• Manifest (0.1.0) matches package.json (0.1.0), and bootstrap-sha is a real ancestor of main; CONTRIBUTING.md clearly documents the process and required secret/variable.

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

No issues found.

Correctness / Security / Performance

• Correctness: Nightly-from-main path preserved; job ordering acyclic; tag<->package.json version-match guards consistent across resolve-release and publish-npm.
• Security: Least-privilege default token + down-scoped App token, secrets/vars handled correctly, actions SHA-pinned, and untrusted inputs consumed via env with no shell/command-injection surface.
• Performance: Release job is bounded (timeout-minutes: 10), concurrency serialized without cancellation, and the auto-merge loop is bounded by created release PRs with no retrigger loop.

Verdict

Suggested verdict: approve

This is an internally consistent CI/config change with no substantiated blocking defects across all five passes; the nightly path is provably preserved and the stable tag-driven flow, token scoping, and SHA pins are correct. The PR body's stale references to a 0.0.4 seed are cosmetic (the actual code uses a consistent 0.1.0) and are not code defects.

Confidence: 0.90

[swkeever]

Overview

Adds a Release Please stable-release flow: Conventional Commits on main drive a release PR (auto-merged via squash) that bumps package.json/CHANGELOG/manifest, then Release Please cuts the vX.Y.Z tag using a GitHub App installation token so the tag-driven publish-cli.yml actually fires (the default GITHUB_TOKEN can't trigger follow-on workflows). publish-cli.yml is tightened to publish stable only from tags that match package.json, and all actions are SHA-pinned with a Dependabot config to keep pins current.

Assessment

Well-constructed and the design is sound. Verified against the live repo/registry:

• Baseline fully reconciles — npm latest is 0.1.0, package.json/manifest are 0.1.0, and bootstrap-sha (0d63cdf) dereferences from the existing v0.1.0 annotated tag. No version drift; the first post-merge run won't cut a spurious release (only ci/docs/chore since bootstrap).
• --provenance is safe: repository.url is present in package.json, so provenance generation won't error.
• Removing NIGHTLY_SEMVER_RE from publish-cli.yml is safe — nightly tags are excluded from the tag trigger (!v*.*.*-nightly.*) and only ever flow through the refs/heads/main path, so the tag branch never sees them.
• App token is down-scoped to contents/PRs/issues; workflow-level GITHUB_TOKEN is read-only; concurrency serializes release runs. Good hygiene.
• Removing continue-on-error and the npm version step is the right call now that trusted publishing is live and Release Please owns the version.
• Pinned release-please-action SHA resolves to a real v4 release (4.4.1); create-github-app-token → v3.2.0. Pins are valid.

One cosmetic consistency nit inline; non-blocking. Approving.

Minor, non-blocking (no action required)

• npm publish --access public is redundant with publishConfig.access: "public" already in package.json; --provenance is likewise implicit under OIDC trusted publishing. Both are harmless/defensive.