Skip to content
Latchkey

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: recursive

On 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

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →