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.

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, ci settings set, ci rerun and ci usage.