Travis CI .travis.yml cache persistence and dependency invalidation

Answer

The documented mechanism is cache.key with a checksum helper that hashes your lockfile. When the lockfile contents change, the computed key changes and Travis restores a different cache bucket, so the old artifacts are not reused. If you cannot edit .travis.yml, the practical workaround is to delete the branch cache through the Travis CI API or the Travis CLI rather than the web UI.

Why updating a lockfile alone is not enough

By default Travis caches directories under a key derived from the job configuration and branch, not from the contents of files inside the cached directories. Changing package-lock.json or pom.xml therefore changes the repository but not the cache identity, so the runner restores the previous node_modules or .m2 snapshot.

Option 1: checksum-based cache key

Add a key entry that includes the checksum of the lockfile. Use the exact filename for your ecosystem.

cache:
  directories:
    - $HOME/.m2
  key:
    - "{{ checksum \"pom.xml\" }}"
    - "{{ checksum \"package-lock.json\" }}"
    - branch

When any listed file changes, the next build computes a new key and reports a cache miss for the old bucket. Keep the list narrow: broad globs cause unnecessary cache busts, and missing the real lockfile leaves stale artifacts in place.

Option 2: delete the cache programmatically

If the configuration is frozen, remove the existing cache for the branch before the next build. The Travis CLI exposes a cache subcommand:

travis cache delete --repo owner/repo --branch main

The equivalent API operation targets the repository cache endpoint for a branch. Because the exact route and required token scope can vary by Travis plan and API version, verify the current endpoint in your Travis CI documentation and use a token with repo scope. Deletion is immediate; concurrent builds on that branch will start without a cache.

Optional time-based fallback

cache.timeout accepts a number of seconds after which the cache is considered stale and removed. This does not react to dependency changes, but it bounds how long an old artifact can survive.

cache:
  timeout: 86400

Verify the behavior

1. Push a lockfile-only change after adding the checksum key.
2. Open the build log and look for a message such as "Cache key changed" or the absence of a restore step.
3. Confirm the install step runs from scratch rather than reusing the previous directory.

If the log still shows a cache restore, re-check that the filename in cache.key matches the file your build actually updates.