fix(ci): pre-build every frontend dir (web/ and ui/) for release binaries - #591
fix(ci): pre-build every frontend dir (web/ and ui/) for release binaries#591andersonleal wants to merge 1 commit into
Conversation
…ries The release web-build job built web/ OR ui/, but console now ships both (embedded SPA + injected config-form UI). Matrix shards set SKIP_UI_BUILD, so console/build.rs panicked on the missing ui/dist and console/v1.8.0 failed on all nine targets. Build every dir present, stage a fixed <dir>/dist artifact layout, and place each dist on the shards.
andersonleal
added
the
no-ticket
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
skill-check — worker0 verified, 48 skipped (no docs/).
Four for four. Nicely done. |
📝 WalkthroughWalkthroughThe Rust binary workflow now supports building and distributing ChangesWeb bundle build and restore
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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: 1
🤖 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/_rust-binary.yml:
- Around line 179-187: Update the checkout steps in both the web-build and build
jobs to use refs/tags/${{ inputs.tag_name }} instead of the default GITHUB_REF,
ensuring frontend assets and bundled Rust binaries are built from the same
release tag used by upload-rust-binary.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b399719a-e7f5-41ec-8cae-56a347c9aca7
📒 Files selected for processing (1)
.github/workflows/_rust-binary.yml
| - name: pnpm install + build | ||
| env: | ||
| WORKER: ${{ steps.dirs.outputs.worker }} | ||
| WEBDIRS: ${{ steps.dirs.outputs.webdirs }} | ||
| run: | | ||
| set -euo pipefail | ||
| for d in $WEBDIRS; do | ||
| (cd "$WORKER/$d" && pnpm install --frozen-lockfile && pnpm build) | ||
| done |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Files matching workflow/action names:"
fd -a '_rust-binary.yml|action.yml|upload-rust-binary-action' . | sed 's#^\./##' | head -200
echo
python3 - <<'PY'
from pathlib import Path
import re
for p in Path('.github/workflows').glob('*.yml'):
text = p.read_text()
if '_rust-binary.yml' in str(p) or 'upload-rust' in text or 'web-build' in text or 'build' in text:
lines = [f"{i+1}: {line}" for i,line in enumerate(text.splitlines()) if any(s in line for s in ['web-build', 'build', 'upload', 'checkout', 'inputs.tag_name', 'ref:', 'uses:'])]
print(f"\n== {p} ==")
for ln in lines[:220]:
print(ln)
PYRepository: iii-hq/workers
Length of output: 11853
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Tracked files under .github:"
git ls-files .github | sed -n '1,200p'
echo
echo "Relevant workflow lines:"
awk 'NR>=140 && NR<=420 {printf "%5d: %s\n", NR, $0}' .github/workflows/_rust-binary.yml
echo
echo "Potential uploaded composite action files:"
git ls-files | rg 'upload-rust|action\.yml|\.yml$|\.yaml$' | rg '(^|/)upload|action\.ya?ml' | sed -n '1,200p'Repository: iii-hq/workers
Length of output: 13070
🌐 Web query:
taiki-e upload-rust-binary-action v1 action.yml ref inputs composite action
💡 Result:
The taiki-e/upload-rust-binary-action is a composite GitHub Action designed to build and upload Rust binaries to GitHub Releases [1][2]. The action.yml file defines it as a composite action that executes a shell script (main.sh) [1][3]. Regarding the ref input specifically: The ref input is one of the many supported inputs for this action [1]. In the underlying main.sh script, the ref variable is assigned from INPUT_REF (the value provided to the ref input) or defaults to GITHUB_REF [3]. This value is subsequently used to determine the tag for the release, derived via tag="${ref#refs/tags/}" [3]. Key characteristics of the action's action.yml and operation include: - Inputs: The action accepts numerous inputs, such as bin (required), token, archive, target, features, profile, and ref [1][2][3]. - Implementation: It uses runs: using: composite and runs a bash script [1]. - Default Token: It defaults to ${{ github.token }} [1][4]. - List Inputs: Several inputs (like bin, package, include, asset, and checksum) support whitespace- or comma-separated lists [4][5]. For detailed usage, you can refer to the official repository documentation [2][6].
Citations:
- 1: https://github.com/taiki-e/upload-rust-binary-action/blob/main/action.yml
- 2: https://github.com/taiki-e/upload-rust-binary-action
- 3: https://github.com/taiki-e/upload-rust-binary-action/blob/main/main.sh
- 4: https://github.com/taiki-e/upload-rust-binary-action/blob/main/CHANGELOG.md
- 5: https://github.com/taiki-e/upload-rust-binary-action/releases
- 6: https://github.com/taiki-e/upload-rust-binary-action/blob/main/README.md
🌐 Web query:
github.com taiki-e upload-rust-binary-action v1 main.sh checkout upload tag
💡 Result:
The taiki-e/upload-rust-binary-action is a GitHub Action designed to build Rust binaries and upload them as assets to GitHub Releases [1][2]. The main.sh file serves as the core script for the action's execution [3], which is triggered by the action's composite step definition in action.yml [4]. Regarding your query on checkout, tag, and upload: 1. Checkout: In typical usage, you must include the actions/checkout step before calling this action [1][5]. This ensures the repository code is available for building the binary [1]. 2. Tag: The action identifies the target GitHub Release using the git tag [3]. By default, it uses the GITHUB_REF environment variable to determine the tag [6]. If you need to specify a different tag, the action provides a ref input option [6]. The action uses the GitHub CLI (gh release upload) to upload assets to the release associated with that tag [3]. 3. Upload: The upload process is handled automatically by the action once the build is complete [1]. It supports building and uploading multiple binaries (specified by the bin input) and allows for customization of the archive name using variables like $bin, $target, and
Citations:
- 1: https://github.com/taiki-e/upload-rust-binary-action
- 2: https://github.com/taiki-e/upload-rust-binary-action/blob/main/README.md
- 3: https://github.com/taiki-e/upload-rust-binary-action/blob/main/main.sh
- 4: https://github.com/taiki-e/upload-rust-binary-action/blob/main/action.yml
- 5: https://github.com/marketplace/actions/build-and-upload-rust-binary-to-github-releases
- 6: https://github.com/taiki-e/upload-rust-binary-action/blob/main/CHANGELOG.md
- 7: https://github.com/taiki-e/upload-rust-binary-action/releases
🌐 Web query:
raw.githubusercontent.com taiki-e upload-rust-binary-action v1 main.sh INPUT_REF gh release
💡 Result:
The ref input option in taiki-e/upload-rust-binary-action is used to specify a fully-formed tag reference for a release [1][2]. In the action's main.sh script, the ref variable is initialized using the INPUT_REF environment variable, which corresponds to the ref input provided in a GitHub Actions workflow [3]: ref="${INPUT_REF:-"${GITHUB_REF:-}"}" If INPUT_REF is not explicitly set, the action defaults to using GITHUB_REF [3]. The script then validates that the ref starts with refs/tags/. If it does not, the action will generally terminate with an error (unless running in dry-run mode) because it is designed to support events originating from tags or releases [3]. By specifying the ref input, you can override the default behavior and upload binaries to a specific, arbitrary tag reference (e.g., refs/tags/my_tag) [1][2].
Citations:
- 1: https://github.com/taiki-e/upload-rust-binary-action/blob/main/README.md
- 2: https://github.com/taiki-e/upload-rust-binary-action
- 3: https://github.com/taiki-e/upload-rust-binary-action/blob/main/main.sh
Build frontend assets from the release tag.
The workflow checks out the default GITHUB_REF for both web-build and build, while upload-rust-binary is invoked with ref: refs/tags/${{ inputs.tag_name }} and uses that ref only for release lookup. Check out refs/tags/${{ inputs.tag_name }} in both web-build and build so the bundled assets match the tagged Rust source.
🤖 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/_rust-binary.yml around lines 179 - 187, Update the
checkout steps in both the web-build and build jobs to use refs/tags/${{
inputs.tag_name }} instead of the default GITHUB_REF, ensuring frontend assets
and bundled Rust binaries are built from the same release tag used by
upload-rust-binary.
1 participant
Why
console/v1.8.0failed on all nine binary targets: the releaseweb-buildjob builds eitherweb/orui/(elif), but console now has both — the embedded SPA inweb/and the injectable config-form UI inui/(#579). The matrix shards setSKIP_UI_BUILD=1, soconsole/build.rspanicked on the missingui/dist/config-form.js.What
web-buildresolves all frontend dirs present (web,ui) and pnpm-builds each.<dir>/distartifact layout (single upload path ⇒ deterministic artifact root; multi-path uploads would re-root at the common ancestor and flatten the single-dir case).<worker>/.web-bundle/and move each dist into place beforecargo build.Single-dir workers (state:
ui/only; iii-directory:ui/only) keep working — the loop just finds one dir.After merge
Re-dispatch Release with the existing tag
console/v1.8.0(no new tag needed, per docs/sops/release.md).Summary by CodeRabbit