ci: publish the viewer as its own upgrade channel - #17
Merged
Conversation
Uploads the native tarballs and a `viewer-version.txt` to the rewire-releases bucket, so `rewire upgrade` can pick up a viewer release that ships without a matching bridge release.
alvgaona
force-pushed
the
feature/rew-213
branch
from
July 26, 2026 13:08
7a7d4e7 to
4c66d51
Compare
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
A viewer-only release could never reach anyone through
rewire upgrade. The bridge CLI compared its own version against the bridge version file and returned early on a match, and the viewer existed on the release host only as a copy bundled inside the bridge tarball, pinned to whatever was latest when the bridge was tagged. A viewer released after the last bridge tag lived in no archive the CLI would ever fetch, so users hitting a viewer bug had no upgrade path short of re-running the install script.This gives the viewer its own upgrade channel on the release host, alongside the bridge's.
Changes
r2job, mirroring the bridge's, uploading the native per-target tarballs and a viewer version file to therewire-releasesbucket.buildandrelease, so the bucket only receives artifacts that already made it onto a GitHub release.deploy-wasmjob and the wasm bucket are untouched. This adds the native binaries to a different bucket and does not change the web viewer.The archive glob picks up only the three native tarballs. The wasm artifact contributes loose files, so it cannot leak into the upload loop.
This job is the first thing in this repo to write to
rewire-releasesrather thanrewire-viewer, so the repo'sCLOUDFLARE_API_TOKENneeds R2 write on that bucket and not only on the wasm one.Related
Checklist
cargo fmt --checkis cleancargo clippy --all-targets -- -D warningsis clean (native)cargo build --lib --target wasm32-unknown-unknown --no-default-featuresbuilds (wasm)cargo testpasses///docsThe wasm box is unticked because that build cannot run on this machine. Compiling ring's C sources for
wasm32-unknown-unknownneeds an LLVM clang that targets wasm, which the workflow installs from apt and wires up through the wasm compiler env vars. Apple clang fails on the first C object. The diff is one workflow file with no Rust in it, so the wasm build has nothing to regress against, andbuild-wasmwill confirm it in CI.Breaking changes
None. No ports, flags, or protocol surface are touched.