Build frontend in release workflow so binaries actually get produced#1159
Merged
Conversation
release.yml runs `go build` directly with no node steps, so internal/admin.go's `//go:embed build/*` fails — the Dockerfile builds the SvelteKit app first, but the workflow doesn't, so tag pushes never actually produce binaries. Add Node 22 + npm ci + the two vite builds (matching the Dockerfile), align Go to 1.25 (matched in Dockerfile, devenv), and inject the same buildVersion/buildTime ldflags the Dockerfile sets so the resulting binaries report their version. Use github.ref_name as PRIMO_VERSION, mirroring tag.yml's Docker build-args. The release upload step now sets draft: true and drops generate_release_notes so an existing draft (e.g. v3.2.0 with hand-written notes) is updated in place rather than published or having notes mangled. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe release workflow now builds frontend assets (Node.js v22, npm ci, SvelteKit, Vite) before compiling Go binaries. Go toolchain upgrades from v1.21 to v1.25, and the Go build injects build timestamp and version via ldflags. The release step now uploads ChangesRelease Workflow Enhancement
Sequence Diagram(s)sequenceDiagram
participant Actions as GitHub Actions
participant Node as Node.js (v22)
participant Frontend as SvelteKit/Vite build
participant Go as Go toolchain (1.25)
participant Release as GitHub Release
Actions->>Node: setup-node (v22)
Actions->>Node: run `npm ci`
Actions->>Frontend: sveltekit sync & build, vite build
Frontend->>Actions: frontend artifacts
Actions->>Go: go build with -ldflags (internal.buildTime, internal.buildVersion)
Go->>Actions: binaries/*
Actions->>Release: upload binaries to draft release (draft: true)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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: 2
🧹 Nitpick comments (1)
.github/workflows/release.yml (1)
42-47: 🏗️ Heavy liftBuild frontend once and fan out as an artifact to matrix jobs.
The frontend build runs in every OS/arch leg, but embedded assets are platform-independent. Splitting this into a single frontend job (upload
build/) plus per-target Go build jobs will reduce release time/cost and lower flake surface.🤖 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 42 - 47, The workflow currently runs the "Build frontend" steps (npm ci; npx svelte-kit sync; npx vite ... build) in every matrix job; instead create a single dedicated CI job named e.g. "build-frontend" that runs those steps once, uploads the produced frontend artifact (upload the build/ directory) using actions/upload-artifact, and remove the frontend build steps from the per-target Go matrix jobs; then in each Go build job add a step to download the artifact (actions/download-artifact) and place the frontend assets where the Go build expects them before building. Use the existing "Build frontend" run steps as the body of the single job and reference the artifact name "build" when uploading/downloading so matrix jobs can consume it.
🤖 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 89-90: Update the GitHub Actions step named "Upload assets to
release" to use the newer action version by changing the uses value from
softprops/action-gh-release@v1 to softprops/action-gh-release@v3 (or
softprops/action-gh-release@v2.6.2 if you must stay on Node 20); locate the step
by the step name "Upload assets to release" and the uses field and replace the
version tag accordingly, then run the workflow to verify compatibility on
GitHub-hosted runners.
- Line 38: Replace floating action tags with immutable commit SHAs for all
referenced actions: locate uses: entries for actions/checkout@v4,
actions/setup-node@v4, actions/setup-go@v5, actions/upload-artifact@v4,
actions/download-artifact@v4, and softprops/action-gh-release@v1 and swap the
tag (e.g., `@v4` or `@v1`) for the corresponding full commit SHA from each action's
GitHub repo (use the commit that matches the intended tag/release), updating the
uses: lines accordingly; ensure you pin each occurrence to a full 40-character
SHA and verify the workflow still runs by testing the workflow or running a
local lint.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 42-47: The workflow currently runs the "Build frontend" steps (npm
ci; npx svelte-kit sync; npx vite ... build) in every matrix job; instead create
a single dedicated CI job named e.g. "build-frontend" that runs those steps
once, uploads the produced frontend artifact (upload the build/ directory) using
actions/upload-artifact, and remove the frontend build steps from the per-target
Go matrix jobs; then in each Go build job add a step to download the artifact
(actions/download-artifact) and place the frontend assets where the Go build
expects them before building. Use the existing "Build frontend" run steps as the
body of the single job and reference the artifact name "build" when
uploading/downloading so matrix jobs can consume it.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 08f68e94-62b7-4aa8-ab0b-6d5e9bfe20cf
📒 Files selected for processing (1)
.github/workflows/release.yml
v1 predates the current GitHub Actions runtime updates and actionlint flags it as too old to run on hosted runners. v3 (April 2026) moved the action to Node 24; same inputs, same draft+existing-release behavior. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
npm ci+ the twovite buildsteps to the matrix job sointernal/admin.go's//go:embed build/*has the SvelteKit output to embed.buildVersion/buildTimeldflags so released binaries report their version (mirrors Dockerfile and tag.yml).draft: trueand dropgenerate_release_notesso an existing draft (e.g. the current v3.2.0 with hand-written notes) gets assets uploaded in place rather than published or having auto-generated notes appended.The existing workflow has never produced working binaries — every
v*tag push must have failed atgo buildbecause there's nointernal/build/directory until the frontend has been built. This is why the v3.1.0 release has empty assets andprimo dev(in primo-cli) currently 404s.Test plan
v3.2.0tag.Summary by CodeRabbit