Make CI runnable on the QuickNode fork

[McSim85]

Problem

Three independent issues prevented .github/workflows/{test,build,release}.yml from running on quiknode-labs/shredstream-proxy:

1. Self-hosted runner reference. All three workflows use `runs-on: ubuntu-22.04-16c-64g-public` — Jito's private runner pool. The fork has no access, so every job would queue indefinitely. Zero workflow runs exist on the fork today, confirming nothing is wired up.

2. Missing Rust toolchain installation. The `setup-rust` composite action only installs protoc; it assumes `rustc` is already present on the runner (true on Jito's self-hosted image). Stock `ubuntu-22.04` GitHub-hosted runners ship rustup but no pinned toolchain, so `cargo build` would fail to resolve the `1.84` channel from `rust-toolchain.toml` without explicit install.

3. Hardcoded Docker Hub publish. Both `build.yml` and `release.yml` push to `jitolabs/jito-shredstream-proxy:*` using `secrets.DOCKERHUB_USER` / `secrets.DOCKERHUB_PWD`. Those secrets don't exist on the fork and shouldn't — they're Jito's. Our deploy pipeline pulls binaries from an OCI bucket via the `role_chain_build` Drone job, not from Docker Hub, so the Docker push is irrelevant for QN production deploys.

Changes

`.github/actions/setup-rust/action.yaml`

• Added `dtolnay/rust-toolchain@1.84` step to explicitly install the pinned toolchain with rustfmt + clippy components.
• Comment block explains why the channel is hardcoded (rather than reading `rust-toolchain.toml`): `dtolnay/rust-toolchain` overrides toml-pinning when `toolchain:` is set, and we want predictable behavior on both stock and self-hosted runners.

`.github/workflows/test.yml`

• Switched runner to `ubuntu-22.04`.
• No other changes.

`.github/workflows/build.yml`

• Switched runner to `ubuntu-22.04`.
• Dropped the cpuinfo sanity print, the Docker Buildx setup, the Docker Hub login, and the `docker/build-push-action` step.
• Kept the clippy check.
• Added a `cargo build --release --locked --bin jito-shredstream-proxy` step to verify a full release build still succeeds — this covers the PR-validation purpose without publishing anything.
• Fixed the `caller-workflow-name` arg (was `test`, now `build`) so it generates a distinct cache key.

`.github/workflows/release.yml`

• Switched runner to `ubuntu-22.04`.
• Replaced the Docker-based binary extraction (build image → push to Docker Hub → `docker run --entrypoint cat …`) with a direct `cargo build --release`.
• The resulting binary is staged as `jito-shredstream-proxy-x86_64-unknown-linux-gnu` (same artifact name as before) and uploaded to the GitHub Release by `softprops/action-gh-release@v2` on tag push.
• Dropped multi-arch (arm64) build since the fleet is x86_64-only (znver3/4/5 per `role_chain_build`). If arm64 is ever needed, re-add via `cross` or QEMU emulation.
• Fixed `caller-workflow-name` to `release`.

Diff summary

```
.github/actions/setup-rust/action.yaml | +12 −1
.github/workflows/build.yml | +3 −24
.github/workflows/release.yml | +10 −28
.github/workflows/test.yml | +1 −1
```

25 lines added, 57 removed.

What this does NOT do

Actions still need to be enabled on the fork. GitHub disables Actions on every fork by default. Repo admin needs to go to Settings → Actions → General and pick "Allow all actions and reusable workflows". This is a one-time manual click that no PR can substitute for. Once enabled, the workflows in this PR will start running on subsequent pushes/PRs/tags automatically.

Test plan

Local YAML syntax check passed (`pyyaml.safe_load` on all four files). The workflows can't actually be executed until Actions is enabled on the fork — once it is, the next PR push to this branch should kick off `test` and `build` automatically.

Manual smoke test after enabling Actions:

• Trigger `test` by pushing a tiny no-op commit to this branch — verify it runs to completion (~5–8 min)
• Trigger `build` by the same — verify clippy + release build pass (~10–15 min)
• Push a temporary `v0.0.0-test` tag (in a throwaway branch) — verify `release` runs, produces the binary, and uploads to a GitHub Release. Delete the test release + tag afterward.

🤖 Generated with Claude Code

---

Note

Low Risk
CI-only changes: switches to GitHub-hosted runners, pins/install Rust toolchain explicitly, and removes Docker publish steps. Main risk is release workflow now builds binaries directly with cargo build, so artifact contents may differ from the prior container-based build.

Overview
Makes CI runnable on standard GitHub-hosted runners by switching all workflows to runs-on: ubuntu-22.04 and updating setup-rust to explicitly install Rust 1.84 (plus rustfmt/clippy) before running jobs.

Removes Docker Buildx/login/build-and-push steps from build.yml/release.yml, replacing them with a direct cargo build --release --locked --bin jito-shredstream-proxy, and stages/uploads the built binary to GitHub Releases. Also fixes caller-workflow-name values so cargo cache keys differ per workflow.

^{Reviewed by Cursor Bugbot for commit 7f8e6ea. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7f8e6ea. Configure here.}

[cursor]

Hardcoded toolchain version duplicates rust-toolchain.toml source of truth

Low Severity

The action description on line 2 says "Install Rust toolchain (from rust-toolchain.toml)" but the implementation uses dtolnay/rust-toolchain@1.84 which hardcodes the version and never reads rust-toolchain.toml. This creates a dual source of truth — rust-toolchain.toml declares channel = "1.84" and components ["rustfmt", "rustc-dev", "clippy", "cargo"], but the action independently pins @1.84 with only rustfmt, clippy. When someone bumps the channel in rust-toolchain.toml, CI will silently keep using the old version, causing local/CI divergence that's hard to diagnose.

 

^{Reviewed by Cursor Bugbot for commit 7f8e6ea. Configure here.}