Make CI runnable on the QuickNode fork (re-opened, targets main-qn)#4
Merged
Conversation
Three independent problems prevented these workflows from running on quiknode-labs/shredstream-proxy: 1. **Custom self-hosted runner**: all three workflows used `ubuntu-22.04-16c-64g-public`, which is Jito's private runner pool. The fork has no access — jobs would queue indefinitely. 2. **Missing Rust toolchain**: the `setup-rust` composite action only installed protoc and assumed rustc was already present on the runner (true on Jito's custom runner). Stock GitHub-hosted runners ship rustup but no specific toolchain; the build would fail to find 1.84. 3. **Hardcoded Docker Hub push**: build.yml and release.yml pushed 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. The QN deploy pipeline pulls binaries from an OCI bucket via the `role_chain_build` Drone pipeline, so the Docker Hub path is irrelevant for QN production deploys. Changes: - `setup-rust/action.yaml`: add `dtolnay/rust-toolchain@1.84` step to explicitly install the toolchain pinned in `rust-toolchain.toml`. Stays compatible with self-hosted runners that already have rust. - `test.yml` / `build.yml`: switch to stock `ubuntu-22.04` runner. Drop Docker login/build/push from build.yml — clippy + a fresh `cargo build --release` cover the PR-validation purpose without publishing artifacts anywhere. - `release.yml`: switch to stock runner. Replace the Docker-based binary extraction (build image → push to Docker Hub → docker run cat) with a direct `cargo build --release`. The resulting binary is staged as `jito-shredstream-proxy-x86_64-unknown-linux-gnu` and uploaded to the GitHub Release by `softprops/action-gh-release@v2` on tag push — same artifact name as before, no behavior change for consumers reading the Release page. Dropped multi-arch (arm64) builds since the QN fleet is x86_64-only (znver3/4/5 targets per `role_chain_build`). If arm64 is ever needed, re-add via `cross` or QEMU. Note: Actions must be enabled on the fork (Settings → Actions → General → "Allow all actions and reusable workflows") for any of these to run. That's a one-time manual click — no PR can do it. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Switches the Rust install step from dtolnay/rust-toolchain@1.84 to actions-rust-lang/setup-rust-toolchain@v1, which reads rust-toolchain.toml when no explicit toolchain input is given. Why this matters: the previous version hardcoded `@1.84` and only declared `components: rustfmt, clippy` — duplicating the source of truth held by `rust-toolchain.toml` (`channel = "1.84"`, components `[rustfmt, rustc-dev, clippy, cargo]`). Bumping the toml without also bumping the action would silently leave CI on the old toolchain, producing local/CI drift that's painful to diagnose. With this change, `rust-toolchain.toml` is the only place to edit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
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 66de22d. Configure here.
actions-rust-lang/setup-rust-toolchain@v1 already enables Swatinem/rust-cache by default, which caches ~/.cargo and target/ using Rust-aware logic (workspace member detection, smart target invalidation on dependency changes, garbage collection). The composite action also had two explicit actions/cache@v4 steps caching the same paths — two systems independently saving and restoring overlapping directories, causing cache conflicts, stale restores, and wasted GHA cache storage. Fix: remove the manual actions/cache@v4 steps. Swatinem/rust-cache is strictly better than the previous naive ~/.cargo + target/ caching for this workload — the same paths get cached, but with smarter keys. Followups that became unnecessary: - The `caller-workflow-name` input only existed to feed the cache-key generator. Now unused; removed from the action interface and from the three callers (test.yml, build.yml, release.yml). - The "Generate cache key" and "Check cache key" steps are gone. Net: 9 lines added, 37 removed. Simpler action, no behavior change besides faster and more correct caching. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
quick-pawiromitchel
approved these changes
May 12, 2026
McSim85
added a commit
that referenced
this pull request
May 12, 2026
Adds two sections to CONTRIBUTING.md that became relevant after PR #4 (CI fixes) landed and branch protection rulesets were configured: - "What's currently QN-specific" — lists the three categories of changes on main-qn that diverge from upstream: the metric label patch (eligible for upstream), the CI workflow overrides (fork-specific), and the policy docs themselves. Future contributors can use this as a reference for what "broadly useful" looks like vs "QN-only". - "Branch protection" — explains the two rulesets (master-mirror-lock and main-qn-pr-review), why direct pushes to master fail, and which CI checks must pass on PRs to main-qn. No content changes elsewhere in the doc — the two-branch model and gh CLI invocations are unchanged. 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
2 participants
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.
Re-opens PR #2, which was auto-closed by GitHub when the branch was renamed from `ci-make-runnable-on-fork` to `qn/ci-make-runnable-on-fork` via the rename API. Branch reference on the original PR didn't follow the rename, so GitHub closed it. The branch still has all the commits — this is just a fresh PR pointing it at the new default base (`main-qn`).
Problem
Three independent issues prevented `.github/workflows/{test,build,release}.yml` from running on `quiknode-labs/shredstream-proxy`:
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.
Missing Rust toolchain installation. The `setup-rust` composite action only installed protoc; it assumed `rustc` was already present on the runner (true on Jito's self-hosted image, not on stock GitHub-hosted `ubuntu-22.04`).
Hardcoded Docker Hub publish. Both `build.yml` and `release.yml` pushed 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 `role_chain_build`, not Docker Hub.
Changes
`.github/actions/setup-rust/action.yaml`
`.github/workflows/test.yml`
`.github/workflows/build.yml`
`.github/workflows/release.yml`
Diff summary
25 lines added, 57 removed.
Note on Cursor feedback from the original PR
Cursor flagged that the previous attempt (`dtolnay/rust-toolchain@1.84` with explicit components) duplicated the source of truth held by `rust-toolchain.toml`. That feedback is addressed in the second commit on this branch — `actions-rust-lang/setup-rust-toolchain@v1` reads the toml directly, no duplication.
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 enabled, this PR's check runs will start working.
🤖 Generated with Claude Code
Note
Medium Risk
Medium risk because it changes the release/build pipeline (removes Docker build/push and alters artifact staging), which could impact produced artifacts and release automation despite being CI-only code.
Overview
Makes CI runnable on stock GitHub-hosted runners by switching
test,build, andreleasejobs toruns-on: ubuntu-22.04and updating thesetup-rustcomposite action to install the Rust toolchain viaactions-rust-lang/setup-rust-toolchain@v1(driven byrust-toolchain.toml).Simplifies
build.ymlandrelease.ymlby removing Docker Buildx/login/build-and-push steps and instead performing acargo build --release --locked --bin jito-shredstream-proxy;release.ymlnow stagestarget/release/jito-shredstream-proxyasjito-shredstream-proxy-x86_64-unknown-linux-gnuforaction-gh-releaseupload.Reviewed by Cursor Bugbot for commit 66de22d. Bugbot is set up for automated code reviews on this repo. Configure here.