Skip to content
Cloning at a Specific Commit
step 1/5

Reading — step 1 of 5

Read

~1 min readExecution

Cloning at a Specific Commit

CI starts by cloning the repo at the EXACT commit being tested.

git clone --depth=1 --branch=<branch> <repo>
git checkout <commit_sha>

--depth=1 (shallow clone): saves bandwidth + time by skipping history. Most CI doesn't need history.

--branch=<branch> is faster than cloning everything then branching.

For PR builds: clone the BASE branch, then merge the PR. This tests "what would happen if we merged" — sometimes different from "the PR branch alone".

Caching:

  • Dependency cache: node_modules, .cargo, ~/.m2 reused across builds. Hash package-lock.json/Cargo.lock for cache key.
  • Build cache: incremental compilation (sccache, ccache, Bazel cache). Saves minutes per build.
- uses: actions/cache@v4
  with:
    path: ~/.cache/pip
    key: pip-${{ hashFiles('requirements.txt') }}

When the file changes, cache key changes → fresh install. Otherwise restore old cache.

Self-hosted runners can persist disk between jobs (faster but security concerns). Cloud runners are stateless (slower but secure).

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…