Diagnosing and Fixing Slow Travis CI Builds Caused by Bad Caching

Recognizing the Problem

When a Travis build starts with a fresh npm install, mvn install, or pip install every time, you’re likely not using the cache. The most common symptoms are:

• Log lines like No cache found for … or Restoring cache… missing entirely.
• Cache restore appears, but the tool still downloads everything.
• Build succeeds but the Saving cache step is skipped or reports a size error.

Symptom–Cause Table

Symptom	Likely Cause
No cache activity in logs	Missing or mis‑typed cache section
Cache restored, but dependencies reinstall	Cached path does not match tool’s expected location
Cache key changes every build	Key derived from volatile data (timestamps, hashes of non‑stable files)
Cache save fails or is truncated	Artifact exceeds Travis’s ~100 MB per‑repo limit

Step 1: Verify Cache Activity

First, confirm that Travis is attempting to use the cache. Search the build log for:

• Restoring cache from …
• Saving cache to …

If neither appears, the cache section is missing or incorrectly formatted. Add a minimal cache block to trigger activity:

cache:
  directories:
    - node_modules

Run the build again and look for the restore/saving lines.

Step 2: Audit Cache Keys

Travis generates a cache key from the values listed under cache: key:. If you include a file that changes on every build (like a log file or a lockfile with timestamps), the key will differ, causing a miss. The safest approach is to base the key on lockfiles that only change when dependencies change.

cache:
  key:
    files:
      - package-lock.json
      - Gemfile.lock
  paths:
    - node_modules
    - vendor/bundle

This tells Travis to look for a cache that matches the contents of the lockfiles. If no match is found, it falls back to a generic key for that OS and language version.

Step 3: Validate Directory Paths

Even with a correct key, the cached data must be placed where the tool expects it. For example, a Node project normally uses node_modules at the repo root. If you cache .node_modules or a custom global path, the restore will silently fail. Verify the tool’s default install location and adjust the paths list accordingly.

Step 4: Check Size Limits

Travis imposes a ~100 MB limit per repository cache. If you try to cache a larger directory, the save step will silently skip the rest of the data, leading to a cache hit that is incomplete. To check the current size:

• In the Travis UI, navigate to Repository Settings > Caches.
• Look at the Size column. If it’s close to 100 MB, consider pruning the cache.

To prune, add a before_install step that removes rarely used directories, e.g.,

before_install:
  - rm -rf /tmp/cache/*

Step 5: Clear or Update the Cache

If you suspect the cache is corrupted or stale, clear it from the Travis UI or via the API. After clearing, the next build will rebuild the cache from scratch, which may take longer but ensures correctness.

Escalation Criteria

Apply the following checklist to decide when to involve a senior engineer or open an issue with Travis support:

1. Cache activity appears but build time is still > 2× normal.
2. Cache key changes on every build and cannot be made stable.
3. Cache size consistently hits the 100 MB limit and cannot be reduced.
4. After clearing the cache, the build still fails to reuse dependencies.

If any of the above hold after following the steps, it’s time to dig deeper into custom caching solutions or consider alternative CI providers.

Practical Verification

After applying a change, run a single build and verify:

• The log contains Restoring cache from … and no dependency download steps.
• The Saving cache to … line appears at the end.
• Build time drops by at least 30 % compared to the baseline.

If any of these checks fail, revisit the corresponding step.