Offer: GitHub Actions CI acceleration experiment with Incredibuild runners

[zozo123]

Hi Tokio maintainers,

I’m working on a small GitHub Actions CI acceleration experiment and wanted to ask whether this would be useful for Tokio.

We tested tokio-rs/tokio externally on an Incredibuild-enabled GitHub Actions runner and built a private demo around it. The signal was strongest for fresh runners and touched-source rebuilds:

• Fresh compile baseline: ~46s
• Incredibuild restored-cache compile: ~13s
• Incredibuild hot-cache compile: ~3s
• Full test path baseline: ~75s
• Full test path with restored Incredibuild cache: ~43s
• Cargo warm after touching source files: ~38s
• Incredibuild restored after touching source files: ~13s

The idea is to restore compiler artifacts across fresh GitHub Actions runners so Rust projects do not rebuild the same compiler work from scratch every run.

If useful, I’d be happy to:

1. Share the benchmark details and workflow configuration.
2. Provide access to an Incredibuild-enabled runner for maintainers to test.
3. Open a draft PR with an optional/experimental workflow.
4. Compare against any Cargo/native cache setup you already prefer.

This would be fully opt-in and non-disruptive.

Contact: yossi.eliaz@incredibuild.com
GitHub: @zozo123
LinkedIn: https://www.linkedin.com/in/yossi-eliaz/

Thanks, and happy to adapt this to whatever would be most useful for the project.

[martin-g]

This would be fully opt-in and non-disruptive.

I'd expect changes only in the .github/workflows/ folder.

Currently the slowest workflow is the Miri one (~17mins). Does your accelerator help to make it faster ?

[zozo123]

Yes, exactly. If we open anything, it would be limited to .github/workflows/ only.

No source code changes, no required CI change, and no disruption to the existing workflow. I’d start with an optional/manual workflow_dispatch experiment so maintainers can inspect the configuration and decide whether it is useful.

[Darksonn]

We already cache build artifacts via the Swatinem/rust-cache@v2 step in most CI jobs.

[zozo123]

That makes sense, and Swatinem/rust-cache is exactly the right native-cache baseline to compare against.

The distinction I was trying to test is not “cache vs no cache”, but native Cargo target cache vs a compiler-artifact cache on fresh/invalidated runners.

In the external Tokio experiment we saw:

• Fresh compile baseline: ~46s
• Incredibuild restored compile: ~13s
• Native Cargo warm, unchanged target: ~0s
• Cargo warm after touching source files: ~38s
• Incredibuild restored after touching source files: ~13s
• Full test path: ~75s -> ~43s with restored Incredibuild cache

So I agree the existing Swatinem/rust-cache@v2 path is strong, especially when Cargo can reuse the target dir cleanly. The possible incremental value here is for cases where the runner starts fresh or source mtimes/config changes make Cargo rebuild meaningful work even though much of the compiler output is content-equivalent.

If this is not interesting for Tokio, no problem. If it is, I’d keep any experiment as a separate optional workflow_dispatch workflow and compare directly against the existing Swatinem/rust-cache@v2 jobs.