Skip to content

fix(ci): pre-build every frontend dir (web/ and ui/) for release binaries - #591

Closed
andersonleal wants to merge 1 commit into
mainfrom
fix/release-multi-frontend-bundle
Closed

andersonleal wants to merge 1 commit into
mainfrom
fix/release-multi-frontend-bundle

Conversation

@andersonleal

@andersonleal andersonleal commented Jul 24, 2026 •

Copy link
Copy Markdown
Collaborator

Why

console/v1.8.0 failed on all nine binary targets: the release web-build job builds either web/ or ui/ (elif), but console now has both — the embedded SPA in web/ and the injectable config-form UI in ui/ (#579). The matrix shards set SKIP_UI_BUILD=1, so console/build.rs panicked on the missing ui/dist/config-form.js.

What

  • web-build resolves all frontend dirs present (web, ui) and pnpm-builds each.
  • Dists are staged into a fixed <dir>/dist artifact layout (single upload path ⇒ deterministic artifact root; multi-path uploads would re-root at the common ancestor and flatten the single-dir case).
  • Shards download to <worker>/.web-bundle/ and move each dist into place before cargo 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

  • Bug Fixes
    • Improved build and packaging reliability for projects containing either or both supported frontend directories.
    • Ensured all detected frontend assets are included in distributed bundles.
    • Improved cross-compilation builds by consistently restoring pre-built frontend assets without rebuilding them.

…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 andersonleal added the no-ticket PR deliberately has no Linear ticket (bump/typo/CI-only) label Jul 24, 2026
@vercel

vercel Bot commented Jul 24, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
workers Ready Ready Preview, Comment Jul 24, 2026 2:32pm
workers-tech-spec Ready Ready Preview, Comment Jul 24, 2026 2:32pm

Request Review

@github-actions

Copy link
Copy Markdown
Contributor

skill-check — worker

0 verified, 48 skipped (no docs/).

Layer Result
structure ✓
vale ✓
ai ✓
render ✓

Four for four. Nicely done.

@coderabbitai

coderabbitai Bot commented Jul 24, 2026 •

Copy link
Copy Markdown

Review Change Stack

📝 Walkthrough

Walkthrough

The Rust binary workflow now supports building and distributing web and ui frontend bundles together. It stages both outputs in a shared artifact and restores each bundle into the corresponding worker directory during downstream builds.

Changes

Web bundle build and restore

Layer / File(s) Summary
Detect and stage frontend bundles
.github/workflows/_rust-binary.yml
The web-build job detects web, ui, or both directories, builds each detected frontend, and stages their dist/ outputs under a deterministic shared artifact root.
Restore bundles into worker directories
.github/workflows/_rust-binary.yml
The build job downloads the shared artifact and moves available web and ui distributions into their expected worker paths.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: sergiofilhowz, ytallo

Poem

A rabbit packed two bundles bright,
Web and UI in one neat flight.
Build them both, then ship with care,
Restore each where it belongs there.
Hop, hop—no frontend left behind!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly states the CI workflow change to pre-build both frontend directories for release binaries.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/release-multi-frontend-bundle

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot 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.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 6452708 and cb35adb.

📒 Files selected for processing (1)
  • .github/workflows/_rust-binary.yml

Comment on lines +179 to +187
- 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

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🎯 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)
PY

Repository: 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:


🌐 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 $tag [1][2]. Note that this action does not strictly require a manual token input anymore; it defaults to ${{ github.token }} [7][6]. Additionally, ensure your workflow has the necessary permissions (specifically contents: write) to create or upload to releases [1][5].

Citations:


🌐 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:


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.

This branch was successfully deployed

2 active deployments
Preview – workers-tech-spec — cb35adb4 Deployed Jul 24, 2026 by vercel[bot]
Preview – workers — cb35adb4 Deployed Jul 24, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no-ticket PR deliberately has no Linear ticket (bump/typo/CI-only)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant