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

**URL:** <https://travis-ci.community/t/use-all-parameters-of-a-job-to-calculate-cache-id-retire-shared-caches/9105>\
**Category:** Feature Requests\
**Tags:** caching, build-matrix\
**Created:** [June 23, 2020, 3:07pm UTC](https://travis-ci.community/t/use-all-parameters-of-a-job-to-calculate-cache-id-retire-shared-caches/9105 "2020-06-23T15:07:49Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![native-api](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/native-api/32/430_2.png) [@native-api](https://travis-ci.community/u/native-api)\
**Post date:** [June 23, 2020, 3:07pm UTC](https://travis-ci.community/t/use-all-parameters-of-a-job-to-calculate-cache-id-retire-shared-caches/9105/1 "2020-06-23T15:07:49Z")

</div>

In [A Rust job somehow uses wrong compiler version installed by another job](https://travis-ci.community/t/a-rust-job-somehow-uses-wrong-compiler-version-installed-by-another-job/9081/9), it turned out that in this unassuming config:

```auto
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](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.

---

<div class="post-metadata">

**Author:** ![RalfJung](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ralfjung/32/2036_2.png) [@RalfJung](https://travis-ci.community/u/RalfJung)\
**Post date:** [June 23, 2020, 3:23pm UTC](https://travis-ci.community/t/use-all-parameters-of-a-job-to-calculate-cache-id-retire-shared-caches/9105/3 "2020-06-23T15:23:35Z")

</div>

> [@native-api](#):
>
> 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.

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).