actions/checkout: Inputs & Workflow Usage
actions/checkout clones your repo onto the runner. It is the first step in almost every workflow.
checkout fetches your repository so later steps can build, test, and lint it. Most jobs only need the defaults, but a handful of inputs solve the common gotchas.
Key inputs (with:)
- ref: branch, tag, or SHA to check out (defaults to the triggering ref).
- fetch-depth: history depth; 0 fetches all history and tags.
- submodules: true or recursive to check out submodules.
- token: a PAT or app token for private submodules or pushing back.
- path: subdirectory to clone into (for multi-repo jobs).
- persist-credentials: keep the token for later git operations (default true).
Example workflow
.github/workflows/ci.yml
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
submodules: recursiveOn any runner
checkout runs identically on GitHub-hosted and self-hosted runners. Latchkey managed runners run it unchanged, cheaper and self-healing.
Key takeaways
- checkout@v4 is the standard first step in a job.
- fetch-depth: 0 is needed for tags, blame, and version tools.
- Pass a token for private submodules or pushing back to the repo.
Related guides
actions/setup-node: Install Node.js in CIReference for actions/setup-node: pin a Node.js version, enable built-in npm/yarn/pnpm caching, and register…
tj-actions/changed-files: List Changed Files in CIReference for tj-actions/changed-files: get the list of files added, modified, or deleted in a push or PR to…