LailaTheElf/actions-rust-cross
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update README.md to talk about weird issue I saw with caching multiple crates

Browse Source
This commit is contained in:
Dave Rolsky 2025-01-11 13:01:14 -06:00
parent 242cf4bba9
commit cd04d1a926
No known key found for this signature in database
1 changed files with 31 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
README.md
View File

@ -99,13 +99,6 @@ build `cross`.
When compiling on Windows, it will do so in a Powershell environment, which can matter in some When compiling on Windows, it will do so in a Powershell environment, which can matter in some
corner cases, like compiling the `openssl` crate with the `vendored` feature. corner cases, like compiling the `openssl` crate with the `vendored` feature.
By default, it will use
[the `Swatinem/rust-cache@v2` action](https://github.com/Swatinem/rust-cache) to cache compiled
dependencies for this crate. Note that per the documentation for this action, it has fairly limited
value for crates without a `Cargo.lock` file. The `key` parameter passed to this action will always
include the value of the `target` input. If you specify a `key` parameter in
`rust-cache-parameters`, then the `target` input will be appended to the value you specify.
When running `cargo` on a Linux system, it will also include the output of running When running `cargo` on a Linux system, it will also include the output of running
`lsb_release --short --description` in the cache key. This is important for crates that link against `lsb_release --short --description` in the cache key. This is important for crates that link against
system libraries. If those library versions change across OS versions (e.g. Ubuntu 20.04 to 22.04), system libraries. If those library versions change across OS versions (e.g. Ubuntu 20.04 to 22.04),
@ -118,3 +111,34 @@ that we do not re-use the cache across changes when these images change.
Finally, it will run `strip` to strip the binaries it builds if the `strip` parameter is true. This Finally, it will run `strip` to strip the binaries it builds if the `strip` parameter is true. This
is only possible for builds that are not done via `cross`. In addition, Windows builds for `aarch64` is only possible for builds that are not done via `cross`. In addition, Windows builds for `aarch64`
cannot be stripped either. cannot be stripped either.
### Caching
By default, this action will use
[the `Swatinem/rust-cache@v2` action](https://github.com/Swatinem/rust-cache) to cache compiled
dependencies for a crate. Note that per the documentation for the `rust-cache` action, it has fairly
limited value for crates without a `Cargo.lock` file. The `key` parameter passed to this action will
always include the value of the `target` input. If you specify a `key` parameter in
`rust-cache-parameters`, then the `target` input will be appended to the value you specify.
#### Weird Caching Issue with Multiple Crates
In my testing, it seemed like in some cases restoring the cache would delete existing files in a
`target` directory. This manifested with this sequence of actions:
1. Run `actions-rust-cross` to compile a crate in a top-level directory.
2. Run `actions-rust-cross` to compile a crate in a subdirectory.
After step 2, the compiled binaries from step 1 were no longer present, _sometimes_. I'm not sure
exactly what's going on here, but my recommendation is to structure your workflows so that this
cannot affect you.
For example, if you have multiple crates, each of which builds a binary you want to release, then
you can avoid this issue by structuring your workflow as follows:
1. Run `actions-rust-cross` to compile crate A.
2. Run the release steps for crate A.
3. Run `actions-rust-cross` to compile crate B.
4. Run the release steps for crate B.
When structured this way, it does not matter if the output of crate A is deleted in step 3.