Use all parameters of a job to calculate cache ID; retire "shared caches"

Travis CI Discussions & Feedback Feature Requests
,
1

In A Rust job somehow uses wrong compiler version installed by another job, it turned out that in this unassuming config:

matrix:
  include:
  - name: miri
    rust: nightly
    os: linux
    script:
      - sh ci/miri.sh
  - name: all-features
    rust: nightly
    os: linux
    script:  # `--lib` added to prevent doctests from being compiled.
             # This is due to `unstable_const` requiring extra `feature(...)` directives
             # which the doctests do not have.
      - cargo test --verbose --all-features --lib

the two jobs use the same cache!

The ability to use “shared cache” was left in as an unintentional feature to allow data passing between jobs. Now we have workspaces for that.

So I guess it’s time to make each job’s cache truly unique. And retire “shared cache” as hacky, implicit (leading to hard-to-catch bugs like the above) and, most importantly, unreliable: if a few builds work in parallel, later jobs from one build can end up using cache from earlier jobs from another build.

The implementation could be to e.g. use the entire config dictionary instead of just envvars in [https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/script.rb]::cache_slug to calculate cache ID.

As a possibly less controversial alternative, I’m fine with incorporating just job name into cache ID. The rationale is:

  • previously, envvars were used to tell jobs apart in job list, making them an intuitive expression of a job’s identity. Now, names can be used for this as well, making them another intuitive expression of a job’s identity.
3

In particular, using env vars for this can be problematic – I switched to job names because the MIRI env var I was using at some point became meaningful to the Miri tool this job was running, interpreting it as the location of the Miri binary (so when it was set to empty from env: MIRI, things just failed).