Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustup and interfaction with Swatinem/rust-cache #23

Open
jennydaman opened this issue Sep 8, 2024 · 3 comments
Open

rustup and interfaction with Swatinem/rust-cache #23

jennydaman opened this issue Sep 8, 2024 · 3 comments

Comments

@jennydaman
Copy link

Hi, I am wondering how to use this properly with Swatinem/rust-cache. The README says

## Caching Rust Compilation Output
You can use the [Swatinem/rust-cache](https://github.com/Swatinem/rust-cache) action with this one
seamlessly, whether or not a specific build target needs `cross`. There is no special configuration
that you need for this. It just works.

However, Swatinem/rust-cache README says

selecting a toolchain either by action or manual rustup calls should happen
before the plugin, as the cache uses the current rustc version as its cache key

https://github.com/Swatinem/rust-cache/blob/9bdad043e88c75890e36ad3bbc8d27f0090dd609/README.md?plain=1#L11-L12

I see that houseabsolute/actions-rust-cross calls dtolnay/rust-toolchain@master, which is a wrapper around rustup

uses: dtolnay/rust-toolchain@master
with:
targets: ${{ inputs.target }}
toolchain: ${{ inputs.toolchain }}

So if you have something like

- uses: Swatinem/rust-cache@v2
- uses: houseabsolute/actions-rust-cross@v0
  with:
    taget: x86_64-unknown-linux-musl

What ends up happening is rustup gets executed before Swatinem/rust-cache

@autarch
Copy link
Member

autarch commented Sep 8, 2024

Oh, that's a good question. I didn't actually notice this in the rust-cache docs! I've been using it the wrong way, I guess. See https://github.com/houseabsolute/ubi/blob/master/.github/workflows/ci.yml for an example.

It seems to be caching something. My guess is that it's using the rust version installed on the Actions image. I think the only way to fix this is to have actions-rust-cross integrate rust-cache. That's not very hard to do, so I'll look into that soon.

@jennydaman
Copy link
Author

jennydaman commented Sep 8, 2024

I think the only way to fix this is to have actions-rust-cross integrate rust-cache. That's not very hard to do, so I'll look into that soon.

That would be great! Supporting rust-cache would give houseabsolute/actions-rust-cross a feature over https://github.com/taiki-e/setup-cross-toolchain-action

@autarch
Copy link
Member

autarch commented Sep 21, 2024

So I looked into this a little more. I think that Swatinem/rust-cache is just not compatible with cross. The rust-cache action uses the output of rustc -vV as part of its cache key. But if the build is running via cross, then the output of rustc on the host isn't relevant to the compilation artifacts.

I'm not sure how to fix this. The "obvious" solution would be to tell rust-cache to run cross -vV instead. But that doesn't actually do anything useful, since it will just run cargo under the hood. What we really need is a way to ask cross to give us the same output for a given target, but cross only accepts a --target parameter when given a subcommand like build or test.

I tried capturing the output from the correct rustc with a simple crate using a build.rs script, but even then, it shows me info about an x86-64 host.

So I'm a bit stumped on this one. If there was a way to get the right rustc info from cross I think making a PR for rust-cache to use this info wouldn't be too hard. But I don't know how to get this info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants