why repeat build in rust?

[rustdreamer]

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

[cydowens]

@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?

[bdebyl]

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

[raphendyr]

Two ideas:

1. 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 archive: Add absolute path mode #141

2. 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 Tar archive does not restore file (or directory) modification time stamps #210 .