`actions/checkout` retrieves repository sources into a job workspace. GitHub Actions does not automatically clone the repository, so add checkout before build, test, or other steps that need repository files. Workflows that only handle events, such as issue triage, can skip it and avoid the clone time. section 1.3
Use the action as a workflow step, typically near the start of a job. After checkout, shell steps can inspect the workspace and local actions can be addressed with `uses: ./`. A locally referenced action requires the repository to be checked out first; an action referenced through an owner, name, and Git reference does not. section 2.3 section 4.3.5
Check out only the source needed for CI
For compilation or integration work, retrieve the tip of `main` rather than full history. `fetch-depth: '1'` is the default and can significantly reduce retrieval time for long-lived repositories. Set `fetch-depth: 0` only when later work must traverse history or when another action requires it. section 8.4.1
Listing 8.1 The actions/checkout action
- uses: actions/checkout@v3
with:
ref: 'main' #not naming the ref will fetch the default branch
fetch-depth: '1' #1 is default and 0 fetches the full depth of the repo
This listing shows a minimal checkout step with an explicit branch and shallow fetch depth, including the full-history alternative. section 8.4.1
On a self-hosted runner, action code is downloaded separately from the repository sources that checkout retrieves. The runner downloads the referenced action version, stores it under its `_work\_actions` area, and cleans that action area at the start of each job. Version references therefore affect what is downloaded and stored. section 6.1.5
