Choosing the Right Cache Strategy in Travis CI for Java Projects

Problem & Decision

Java projects that use Maven often pull dozens of dependencies on every build. In Travis CI, the default behaviour is to download each dependency from Maven Central for every job, which can add 15–30 minutes to a CI run. The core decision is whether to enable a cache, and if so, how to configure it so that build times stay low while the cache never exceeds Travis’s 5 GB limit.

Constraints

• Travis CI imposes a hard 5 GB limit on each cache key.
• All branches share a cache unless a unique key is specified.
• Cache invalidation is automatic when the key changes; manual invalidation requires explicit steps.
• Build artifacts (e.g., target/) should not be cached because they are regenerated each job.

Cache Options

• Cache Maven’s local repo (~/.m2) – the most common strategy.
• Cache a custom directory – useful if you want to split dependencies from build outputs.
• Disable cache – for projects with very few dependencies or when cache corruption is a concern.

Trade‑offs Table

Option	Pros	Cons	Typical Use‑Case
Cache ~/.m2	30–60% faster builds; automatic dependency reuse.	Risk of stale or corrupted artifacts; can hit 5 GB limit quickly.	Medium‑to‑large Maven projects with many dependencies.
Cache custom dir (e.g., ~/.m2/repository + ~/.m2/settings.xml)	Fine‑grained control; can exclude settings.xml to avoid caching credentials.	More configuration; still subject to 5 GB limit.	Projects that need different Maven settings per branch.
Disable cache	No risk of corrupted cache; always fresh dependencies.	Longest build times; wasted network bandwidth.	Small projects or when debugging dependency issues.

Choosing the Right Option

If your project has a moderate number of dependencies and you can tolerate a 5 GB cache, caching ~/.m2 is usually the best balance. Use a unique key to avoid stale artifacts on feature branches:

cache:
  key: "${TRAVIS_COMMIT_SHA}/${TRAVIS_BRANCH}/build-${TRAVIS_BUILD_NUMBER}"
  paths:
    - ~/.m2

For very large dependency trees that might exceed the quota, split the cache:

cache:
  key: "${TRAVIS_COMMIT_SHA}/${TRAVIS_BRANCH}/repo-${TRAVIS_BUILD_NUMBER}"
  paths:
    - ~/.m2/repository

If you suspect cache corruption or need to force a clean build, add cache: false or delete the cached directory in the repo and trigger a new build.

Concrete .travis.yml Example

language: java
jdk:
  - openjdk17
cache:
  key: "${TRAVIS_COMMIT_SHA}/${TRAVIS_BRANCH}/build-${TRAVIS_BUILD_NUMBER}"
  paths:
    - ~/.m2
script:
  - mvn clean install -DskipTests
after_success:
  - echo "Build succeeded"

Replace openjdk17 with the JDK version your project requires. The key uses the commit SHA, branch name, and build number to ensure a fresh cache per job, while still allowing reuse of dependencies across jobs that share the same key.

Verification & Monitoring

1. Run a baseline build without cache:

   travis build --no-cache
   

   Check the log for the line Downloading cache – it should be absent.
2. Enable cache and run again. Verify that the log contains Downloading cache and that the cache size reported is below 5 GB.
3. Measure build time difference. A 30–60% reduction is typical for Maven‑heavy projects.
4. To confirm cache integrity, run mvn dependency:tree in a clean job and compare the output to a cached run.

Travis CI’s UI also shows the cache size next to each build. If the size climbs close to 5 GB, consider pruning older items by adding mvn dependency:purge-local-repository to a nightly job.

Limitations & Best Practices

• Cached artifacts can become corrupted. Schedule a nightly clean build that runs mvn dependency:purge-local-repository to reset the cache.
• Never cache directories that change on every build (e.g., target/, dist/).
• Use explicit cache keys to avoid stale dependencies on long‑lived feature branches.
• If your project uses custom Maven settings that contain credentials, exclude settings.xml from the cache or store it in a separate secure location.
• Remember that Travis CI’s cache is shared across all jobs for a given key; parallel jobs may see the same cached data.

Conclusion

For most Java projects on Travis CI, caching Maven’s local repository with a unique key that combines commit SHA, branch, and build number offers the best trade‑off between speed and safety. Keep an eye on cache size, and prune or split the cache when you approach the 5 GB limit. By following the verification steps above, you can confidently rely on Travis’s caching mechanism to accelerate your CI pipeline without compromising build reliability.