---
title: "Caching, flaky tests and CI cost"
description: "How cache keys work, what happens to a flaky test, and the controls that stop CI waste (superseded runs, affected tests and the per-pull-request cost gate)."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.overlane.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Caching, flaky tests and CI cost

## Caching

A job with a `cache` block restores its cached paths before the first step and saves them after the last step when the job passed. The cache key is built from the team, the repository, the content of the lockfiles you list in `keyFiles`, and the job name. Change a lockfile and the key changes, so the next run misses and rebuilds. Two teams never share a cache entry, even with the same lockfile. A job that failed saves nothing, so a broken install is never cached.

`overlane ci show` prints a cache hit or miss for each job, and a hit shortens the job and the minutes it is billed.

## Flaky tests

A step marked `test: true` that fails is run once more.

- If the second run passes, the job passes and the test gets a flaky mark. `ci show` shows both attempts.
- If the second run fails too, it is a real failure. Nothing is marked flaky.
- Steps that are not marked as tests are never re-run.

Two flaky marks on the same test within a week open an issue in the project's tracker, once for that week. `overlane ci usage` lists the tests marked in the last 7 days.

## Waste controls

These are rules, not model calls.

- **Superseded runs are cancelled.** A push to a branch cancels older queued or running runs on it, so minutes are not spent on a commit nobody will merge. Turn it off with `overlane ci settings set --cancel-superseded false`, or set `concurrency: queue` in the file.
- **Path filters.** A job with `paths` runs only when a changed file matches, and counts as passed otherwise, so a required check never waits for a job that had nothing to do.
- **Affected tests only.** With `affectedTests: true`, `{affected}` in a test step becomes the tests the change can affect: a changed test runs itself, a changed source file runs the tests with its name in its package, and a documentation-only change runs none. A change that cannot be mapped, such as a lockfile, a config file or a source file with no matching test, runs everything, so narrowing never hides a failing test. The server measures the change from the pull request's base or the push's previous commit; a caller cannot supply it.
- **Cost gate per pull request.** Once a pull request has used its minutes, further runs are held with a plain reason and the command to raise the limit, instead of spending silently. A held run exits 6.

```sh
overlane ci settings
overlane ci settings set --max-minutes-per-pull 120
overlane ci rerun run_abc123
overlane ci usage
```

The minutes are metered per team, per job, at the runner's rate, and `ci usage` shows the month's total.

Command reference: [ci settings](/cli/ci-settings/), [ci settings set](/cli/ci-settings-set/), [ci rerun](/cli/ci-rerun/) and [ci usage](/cli/ci-usage/).

Source: https://docs.overlane.app/git-ci-deploy/caching-and-flaky-tests/index.mdx