drone-cache
drone-cache copied to clipboard
why repeat build in rust?
Describe the bug I've tried 101 times, but all repeat build in rust.
To Reproduce Steps to reproduce the behavior:
steps:
- name: restore-cache-with-filesystem
image: meltwater/drone-cache
pull: true
settings:
backend: "filesystem"
restore: true
cache_key: "volume"
mount:
- target
volumes:
- name: cache
path: /tmp/cache
- name: rust-build
image: rust:1.57.0
pull: true
commands:
- cargo build --release
when:
event: [push, pull_request]
branch: [development]
volumes:
- name: cache
path: /tmp/cache
- name: rebuild-cache-with-filesystem
image: meltwater/drone-cache
pull: true
settings:
backend: "filesystem"
rebuild: true
cache_key: "volume"
mount:
- target
volumes:
- name: cache
path: /tmp/cache
Expected behavior Except for the first time, others should read the cache
Screenshots
Desktop (please complete the following information):
- OS: Ubuntu
- Version 18.0
Additional context No more
@rustdreamer Sorry for the delayed response, do you have any updates around this issue? I will look into duplicating the above, but wanted to see if you have had any changes?
I'm not sure I understand the issue here. Perhaps not all required directories are mounted as part of drone-cache
settings, or more likely this is an issue with the rust compiler seeing the files as out of date. Perhaps a Makefile could prove useful here though may yield similar behavior.
I am not familiar enough with rust to understand if the build command is selective with it's sources and output/target files. However, this does seem more like an issue to be resolved with cargo
rather than drone-cache
.
If this is still needed please address any attempts to resolve this with additional steps in Drone @rustdreamer
Two ideas:
-
Ensure those compiled / cached files are really under
target
and not e.g.$HOME/.cache/foobar
. I.e., are you really caching the data you assume you should? Note that absolute paths are not yet supported, see #141 -
The cache plugin doesn't restore timestamps, thus cargo could assume one file is modified when it's really not. However, the cache should have a newer file, thus the behaviour doesn't support this theory. Any how, more in #210 .