Repository navigation
fix(release): publish Linux x64 host-root candidate - #28
Conversation
|
Warning Review limit reached
Next review available in: 51 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe PR adds an Changesamd64 prerelease release flow
Estimated code review effort: 4 (Complex) | ~60 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 364-369: Route workflow inputs through step-level env variables to
avoid interpolating them directly in shell commands. In
.github/workflows/release.yml lines 364-369, add BROWSER_SOURCE_VERSION and use
it for --version; lines 507-511, add RELEASE_VERSION and use it in the archive
filename; lines 553-557, add RELEASE_VERSION and BROWSER_SOURCE_VERSION and use
both in the imagetools tags; lines 612-617, add RELEASE_VERSION and use it for
--version.
In `@docs/public-release.md`:
- Around line 73-88: Update the earlier generic publication-order guarantees so
the linux/amd64 and linux/arm64 inclusion and verification requirements apply
only to full releases, or explicitly exempt the amd64-core-cli prerelease mode.
Ensure the documentation does not require nonexistent arm64 artifacts for the
0.1.15-hostroot.2 publication while preserving the existing full-release
requirements.
In `@scripts/tests/public-package-metadata.test.mjs`:
- Around line 56-59: Update the host-root install assertion in the
public-package metadata test to reject any version-pinned run-spaceapp host-root
install command, rather than only version 0.1.15-hostroot.0. Keep the existing
command and --access host-root constraints while generalizing the version match
in the doesNotMatch pattern.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: d611d933-97bc-4ce2-a443-907ac49cfa07
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (21)
.github/workflows/release.ymlCHANGELOG.mdREADME.mddocs/clean-room-testing.mddocs/getting-started.mddocs/operations.mddocs/public-release.mddocs/security-model.mdpackages/run-spaceapp/README.mdpackages/run-spaceapp/package.jsonpackages/run-spaceapp/tests/cli.test.mjspackages/run-spaceapp/tests/command-contracts.test.mjspackages/run-spaceapp/tests/package-info.test.mjsscripts/public-release-readiness.mjsscripts/release-artifact-preflight.mjsscripts/tests/public-package-metadata.test.mjsscripts/tests/public-release-readiness.test.mjsscripts/tests/public-workflows.test.mjsscripts/tests/published-container-verification.test.mjsscripts/tests/release-artifact-preflight.test.mjsscripts/verify-published-containers.mjs
| - name: Verify the reusable browser architectures, SBOMs, and provenance | ||
| run: >- | ||
| node scripts/verify-published-containers.mjs | ||
| --version "${{ inputs.browser_source_version }}" | ||
| --targets browser | ||
| --architectures amd64,arm64 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Route inputs.version / inputs.browser_source_version through env: instead of interpolating them directly into run: scripts. All four new amd64-core-cli steps expand workflow_dispatch inputs directly via ${{ }} inside shell command text; zizmor flags this as template injection at each site. The existing release-policy step in the same file already demonstrates the safe pattern (passing inputs via env: and referencing $VAR).
.github/workflows/release.yml#L364-L369: addenv: BROWSER_SOURCE_VERSION: ${{ inputs.browser_source_version }}and reference"$BROWSER_SOURCE_VERSION"in the--versionargument..github/workflows/release.yml#L507-L511: addenv: RELEASE_VERSION: ${{ inputs.version }}and reference"$RELEASE_VERSION"in the tar archive filename..github/workflows/release.yml#L553-L557: addenv:entries for bothRELEASE_VERSIONandBROWSER_SOURCE_VERSIONand reference$RELEASE_VERSION/$BROWSER_SOURCE_VERSIONin thedocker buildx imagetools createtags..github/workflows/release.yml#L612-L617: addenv: RELEASE_VERSION: ${{ inputs.version }}and reference"$RELEASE_VERSION"in the--versionargument.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 367-367: code injection via template expansion (template-injection): may expand into attacker-controllable code
(template-injection)
📍 Affects 1 file
.github/workflows/release.yml#L364-L369(this comment).github/workflows/release.yml#L507-L511.github/workflows/release.yml#L553-L557.github/workflows/release.yml#L612-L617
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 364 - 369, Route workflow inputs
through step-level env variables to avoid interpolating them directly in shell
commands. In .github/workflows/release.yml lines 364-369, add
BROWSER_SOURCE_VERSION and use it for --version; lines 507-511, add
RELEASE_VERSION and use it in the archive filename; lines 553-557, add
RELEASE_VERSION and BROWSER_SOURCE_VERSION and use both in the imagetools tags;
lines 612-617, add RELEASE_VERSION and use it for --version.
Source: Linters/SAST tools
| ## Personal x64 core and CLI prerelease | ||
|
|
||
| For `0.1.15-hostroot.2`, dispatch `release.yml` from `main` with: | ||
|
|
||
| - `version`: `0.1.15-hostroot.2`; | ||
| - `runtime_version`: `0.1.15-hostroot.2`; | ||
| - `browser_source_version`: `0.1.15-hostroot.0`; | ||
| - `release_mode`: `amd64-core-cli`; | ||
| - `npm_tag`: `personal`. | ||
|
|
||
| The workflow builds and scans only `core` and `cli` for `linux/amd64`. It | ||
| copies the already verified `.0` browser manifest to the new runtime tag | ||
| without rebuilding the browser. It verifies amd64 SBOM and provenance evidence | ||
| for all three published tags before npm OIDC publication. The npm package is | ||
| x64-only and enables host-root because the launcher and runtime versions match. | ||
| Do not change `latest` or `next`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Scope the generic publication guarantees to avoid contradicting amd64-core-cli.
The earlier publication-order section says every image includes linux/amd64 and linux/arm64 and that both architectures are verified, while this mode intentionally publishes and verifies only amd64 core/cli artifacts. Clarify that those guarantees apply only to full releases, or explicitly document the exception so operators do not reject a valid .2 publication or expect nonexistent arm64 tags.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/public-release.md` around lines 73 - 88, Update the earlier generic
publication-order guarantees so the linux/amd64 and linux/arm64 inclusion and
verification requirements apply only to full releases, or explicitly exempt the
amd64-core-cli prerelease mode. Ensure the documentation does not require
nonexistent arm64 artifacts for the 0.1.15-hostroot.2 publication while
preserving the existing full-release requirements.
| assert.doesNotMatch( | ||
| content, | ||
| /npx --yes run-spaceapp@0\.1\.15-hostroot\.0 install --access host-root/, | ||
| path |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Reject every pinned host-root install command.
This only blocks 0.1.15-hostroot.0; a stale run-spaceapp@0.1.15-hostroot.1 install --access host-root instruction would still pass. Reject version-pinned host-root commands generically in these active docs.
Proposed fix
- /npx --yes run-spaceapp@0\.1\.15-hostroot\.0 install --access host-root/,
+ /npx --yes run-spaceapp@\d+\.\d+\.\d+-hostroot\.[\w.-]+ install --access host-root/,📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| assert.doesNotMatch( | |
| content, | |
| /npx --yes run-spaceapp@0\.1\.15-hostroot\.0 install --access host-root/, | |
| path | |
| assert.doesNotMatch( | |
| content, | |
| /npx --yes run-spaceapp@\d+\.\d+\.\d+-hostroot\.[\w.-]+ install --access host-root/, | |
| path |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/tests/public-package-metadata.test.mjs` around lines 56 - 59, Update
the host-root install assertion in the public-package metadata test to reject
any version-pinned run-spaceapp host-root install command, rather than only
version 0.1.15-hostroot.0. Keep the existing command and --access host-root
constraints while generalizing the version match in the doesNotMatch pattern.
Publishes run-spaceapp 0.1.15-hostroot.2 for x64 hosts. The release workflow builds only SpaceApp core and CLI for linux/amd64, reuses the verified 0.1.15-hostroot.0 browser manifest without rebuilding it, and keeps the npm release on the personal tag.
Summary by CodeRabbit
New Features
coreandclicontainer images while reusing the existing signed browser image.Documentation