CACHEDIR.TAG is not written when using custom docker image
Closed this issue · 1 comments
Checklist
- I've looked through the issues and pull requests for similar reports
Describe your issue
Cross doesn't write CACHEDIR.TAG file when using a custom docker image, e.g. having a pre-build step in Cross.toml. The file is created if no custom image is used.
Steps to reproduce:
- Create an empty cargo project
- Create a Cross.toml with the following content
[target.x86_64-unknown-linux-gnu]
pre-build = ["echo"]
- Run
cross build --target x86_64-unknown-linux-gnu
- There is no CACHEDIR.TAG in
target/x86_64-unknown-linux-gnu/
I have encountered this issue while investigating why https://github.com/Swatinem/rust-cache was not caching cross-compilation targets during CI builds. rust-cache uses CACHEDIR.TAG to detect sub-target directories that need to be cached and stopped doing that after we have switched from cargo to cross.
I had a brief look into it and it looks like the code that writes CACHETAG.DIR (added in #836) doesn't write it if the target directory already exists (assumption is that it was created by cargo). However, from my debugging it looks like this directory is created before this check by Dockerfile::build
. Which causes the target directory to only have Dockerfile.*-custom
file.
I can submit a PR that changes the check in fn create_target_dir
from if !path.exists()
to if !cachedir_file.exists()
, but wanted to check if there is a better way to fix it since I only did a very shallow analysis of the issue.
Relates to #835.
What target(s) are you cross-compiling for?
aarch64-unknown-linux-gnu, x86_64-unknown-linux-gnu
Which operating system is the host (e.g computer cross is on) running?
- macOS
- Windows
- Linux / BSD
- other OS (specify in description)
What architecture is the host?
- x86_64 / AMD64
- arm32
- arm64 (including Mac M1)
What container engine is cross using?
- docker
- podman
- other container engine (specify in description)
cross version
cross 0.2.5
Example
No response
Additional information / notes
No response
Well spotted! This should probably be solved by writing the tag when writing the Dockerfile, feel free to create a PR :)