# Using unified cache / Control cache identity **URL:** \ **Category:** Feature Requests\ **Tags:** caching\ **Created:** [December 20, 2018, 8:08am UTC](https://travis-ci.community/t/using-unified-cache-control-cache-identity/1531 "2018-12-20T08:08:39Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ladar](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/ladar/32/806_2.png) [@ladar](https://travis-ci.community/u/ladar)\ **Post date:** [December 20, 2018, 8:08am UTC](https://travis-ci.community/t/using-unified-cache-control-cache-identity/1531/1 "2018-12-20T08:08:39Z")
I’d like to comment on [GH issue #7590](https://github.com/travis-ci/travis-ci/issues/7590) … with my builds, installing dependencies can take between 2 and 15 minutes. Because my actual build process takes around ~40 minutes, that variance is the difference between a pass and failure. So I worked around this issue by creating a cache job, which runs first. Because my build matrix is dictated by environment variables, I need to create two identical jobs for every set of environment variables. The first warms the dependency cache, the second performs the test build. Because the dependencies are shared, they could, and probably should all use a single cache job. I understand the cache corruption issue discussed in [GH issue #7590](https://github.com/travis-ci/travis-ci/issues/4393) and would like to propose several possible solutions. First adding the ability to dictate a cache identifier through an environment variable (TRAVIS\_CACHE\_IDENTIFIER), or yaml value (cache\_id) should be implemented. BUT to avoid corruption I would propose several solutions. Namely, if multiple jobs share a cache identifier, they run single file by default. This would avoid the corruption, at the expense of performance. The single file buld behaviour should be used UNLESS jobs with a shared identifier are in multiple stages. In this scenario, only the first stage with a particular identifier would run single file. Subsequent stages wouldn’t start until the first was completed, and would be run in parallel by default. I would also propose that if the identifier is controlled by the yaml file (preferred), a sub key boolean could be created (read\_only). With this approach Travis would build jobs lacking a “read\_only: true” in single file mode, but know that it was safe to build any of the “read\_only: true” jobs in parallel. Naturally read only jobs would still pull/use the cache, but would not update the cache when they complete. In addition, you could optionally dictate that if “read\_only: false” is explicitly false, jobs would run in single file, even if they span build stages. With my libcore project, I use Travis to ensure compatibility. To do that I’m building this library with 7 different compilers (GCC 4.8, 4.9. 5, 6, 7, 8 and Clang 6.0). For each compiler I’m verifying builds work with all 4 optimization flags, -O0, -O1, -O2, -O3. I’m also ensuring that both pedantic, and production configurations build properly. The result is 56 build jobs, which could, in theory share a single cache job. Unfortunately, because I currently can’t control the cache identifier, I have to create [56 additional cache jobs](https://travis-ci.org/lavabit/libcore.build/builds/470393024). That’s a lot of extra processing that could and should be avoided. With my larger [magma](https://github.com/lavabit/magma/) project, I have a smaller [build matrix](https://github.com/lavabit/magma.build/), because each entry takes ~40 minutes per run, but I’m still building 28 different variants. That means I need [28 cache jobs, for my 28 build jobs](https://travis-ci.org/lavabit/magma.build/builds/470301015). So in my case, implementing this feature means I could literally eliminate 82 build jobs. Please. Pretty please. ---
**Author:** ![vladimiry](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/vladimiry/32/1716_2.png) [@vladimiry](https://travis-ci.community/u/vladimiry)\ **Post date:** [April 29, 2019, 1:32pm UTC](https://travis-ci.community/t/using-unified-cache-control-cache-identity/1531/2 "2019-04-29T13:32:15Z")
See here an idea of sharing the public dynamic data between the jobs [Is it guaranteed that jobs ids of the same build are sequential (share data between the jobs purpose)?](https://travis-ci.community/t/is-it-guaranteed-that-jobs-ids-of-the-same-build-are-sequential-share-data-between-the-jobs-purpose/3222/3) ---
**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:** [April 29, 2019, 1:55pm UTC](https://travis-ci.community/t/using-unified-cache-control-cache-identity/1531/3 "2019-04-29T13:55:40Z")
Explicitly specifying cache identity conflicts with the principle of build matrix. Related: [Allow a next-stage job read-only access to the cache of a previous-stage one; or make exported/imported artifacts](https://travis-ci.community/t/allow-a-next-stage-job-read-only-access-to-the-cache-of-a-previous-stage-one-or-make-exported-imported-artifacts/905) ---
**Author:** ![vladimiry](https://sea1.discourse-cdn.com/flex015/user_avatar/travis-ci.community/vladimiry/32/1716_2.png) [@vladimiry](https://travis-ci.community/u/vladimiry)\ **Post date:** [April 29, 2019, 2:03pm UTC](https://travis-ci.community/t/using-unified-cache-control-cache-identity/1531/4 "2019-04-29T14:03:49Z")
@native-api, of course, that would solve a need, but we need to live somehow until such feature is implemented. ---
**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:** [July 18, 2019, 2:02am UTC](https://travis-ci.community/t/using-unified-cache-control-cache-identity/1531/5 "2019-07-18T02:02:20Z")
> [@Introducing Workspaces](https://travis-ci.community/t/introducing-workspaces/4249): > > We are working on workspaces, a new way of sharing files within a build. Workspaces allow jobs within a build to share files. They are useful when you want to use build artifacts from a previous job; for example, you create a cache that can be used in multiple jobs later. Example configurations and further information can be found in [https://docs.travis-ci.com/user/using-workspaces/](https://docs.travis-ci.com/user/using-workspaces/). We very much appreciate your feedback here. Thank you! should be solving this.