Top Related Projects
Run your GitHub Actions locally ๐
Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton
Workflow Engine for Kubernetes
Concourse is a container-based automation system written in Go. It's mostly used for CI/CD.
Quick Overview
actions/checkout is a GitHub Action that allows you to check out a repository in your workflow. It's designed to be used in GitHub Actions workflows to clone the repository and set up the working directory for subsequent steps. This action is essential for most GitHub Actions workflows that need to interact with the repository's code.
Pros
- Easy to use with minimal configuration required
- Supports checking out submodules and LFS objects
- Allows specifying a different repository or branch to checkout
- Optimized for performance with fetch-depth and sparse checkout options
Cons
- Limited to GitHub-hosted runners by default (requires additional setup for self-hosted runners)
- May have issues with large repositories or complex submodule structures
- Doesn't provide advanced Git operations out of the box
- Can be slower for repositories with extensive history when full clone is needed
Getting Started
To use the actions/checkout action in your workflow, add the following step to your job:
steps:
- uses: actions/checkout@v3
For more advanced usage, you can specify additional options:
steps:
- uses: actions/checkout@v3
with:
repository: myorg/myrepo
ref: 'release/v1'
token: ${{ secrets.ACCESS_TOKEN }}
fetch-depth: 0
submodules: 'recursive'
This example checks out a specific repository and branch, uses a custom access token, fetches the entire history, and recursively checks out submodules.
Competitor Comparisons
Run your GitHub Actions locally ๐
Pros of act
- Allows local testing of GitHub Actions workflows without pushing to a repository
- Supports running workflows in Docker containers, simulating the GitHub Actions environment
- Enables faster iteration and debugging of workflows
Cons of act
- May not perfectly replicate the GitHub Actions environment, leading to potential discrepancies
- Requires Docker to be installed and running on the local machine
- Limited support for certain GitHub-specific features and secrets management
Code comparison
checkout:
- uses: actions/checkout@v3
with:
fetch-depth: 0
act:
act -j build
Summary
checkout is a GitHub Action used to check out a repository in a workflow, while act is a tool for running GitHub Actions locally. checkout is essential for accessing repository contents in workflows, whereas act focuses on local testing and development of workflows. While act provides valuable local testing capabilities, it may not fully replicate the GitHub Actions environment and requires additional setup. checkout, being an official GitHub Action, integrates seamlessly with the platform but lacks local testing features.
Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton
Pros of jx
- Provides a comprehensive CI/CD solution for Kubernetes environments
- Offers automated GitOps workflows and environment promotion
- Includes built-in support for preview environments and canary deployments
Cons of jx
- Steeper learning curve due to its broader scope and complexity
- Requires more resources and setup compared to lightweight actions
- May be overkill for simple projects or non-Kubernetes deployments
Code Comparison
checkout:
- uses: actions/checkout@v3
with:
fetch-depth: 0
jx:
- name: Setup jx
uses: jenkins-x-plugins/jx-setup-action@v1.1.1
- name: Promote to Production
run: jx promote --env production --version ${{ github.sha }}
Summary
While checkout is a focused action for fetching repository contents in GitHub Actions workflows, jx is a comprehensive CI/CD tool for Kubernetes-native applications. jx offers more advanced features but requires more setup and resources. checkout is simpler and more lightweight, suitable for a wider range of projects and workflows. The choice between them depends on the specific needs of your project and deployment environment.
Workflow Engine for Kubernetes
Pros of Argo Workflows
- Supports complex, multi-step workflows with dependencies
- Provides a visual UI for workflow management and monitoring
- Offers native Kubernetes integration and scalability
Cons of Argo Workflows
- Steeper learning curve due to more complex configuration
- Requires Kubernetes cluster setup and management
- Heavier resource usage compared to simple GitHub Actions
Code Comparison
Checkout (GitHub Actions):
- uses: actions/checkout@v3
with:
repository: myorg/myrepo
ref: main
Argo Workflows:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
spec:
entrypoint: main
templates:
- name: main
steps:
- - name: checkout
template: git-clone
- name: git-clone
container:
image: alpine/git
command: [sh, -c]
args: ["git clone https://github.com/myorg/myrepo.git"]
Summary
Checkout is a simple, lightweight action for fetching repository contents in GitHub Actions workflows. Argo Workflows, on the other hand, is a comprehensive workflow engine for Kubernetes, offering more advanced features and flexibility for complex, distributed workflows. While Checkout is easier to use for basic CI/CD tasks, Argo Workflows provides greater scalability and control for larger, more complex projects.
Concourse is a container-based automation system written in Go. It's mostly used for CI/CD.
Pros of Concourse
- More flexible and scalable for complex CI/CD pipelines
- Supports multiple platforms and cloud providers
- Offers a visual interface for pipeline management
Cons of Concourse
- Steeper learning curve and more complex setup
- Requires dedicated infrastructure to run
- Less integrated with GitHub ecosystem
Code Comparison
Checkout:
- uses: actions/checkout@v3
with:
fetch-depth: 0
Concourse:
resources:
- name: repo
type: git
source:
uri: https://github.com/user/repo.git
branch: main
jobs:
- name: build
plan:
- get: repo
Key Differences
- Checkout is specifically designed for GitHub Actions, while Concourse is a standalone CI/CD system
- Checkout focuses on fetching repository content, while Concourse manages entire pipelines
- Concourse requires more configuration but offers greater customization
Use Cases
- Checkout: Ideal for GitHub-centric projects and simpler workflows
- Concourse: Better suited for complex, multi-platform CI/CD pipelines and enterprise-level deployments
Community and Support
- Checkout: Backed by GitHub, extensive documentation, and large user base
- Concourse: Active open-source community, regular updates, but smaller ecosystem
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Checkout v6
What's new
- Improved credential security:
persist-credentialsnow stores credentials in a separate file under$RUNNER_TEMPinstead of directly in.git/config - No workflow changes required รขยย
git fetch,git push, etc. continue to work automatically - Running authenticated git commands from a Docker container action requires Actions Runner v2.329.0 or later
Checkout v5
What's new
- Updated to the node24 runtime
- This requires a minimum Actions Runner version of v2.327.1 to run.
Checkout v4
This action checks-out your repository under $GITHUB_WORKSPACE, so your workflow can access it.
Only a single commit is fetched by default, for the ref/SHA that triggered the workflow. Set fetch-depth: 0 to fetch all history for all branches and tags. Refer here to learn which commit $GITHUB_SHA points to for different events.
The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.
When Git 2.18 or higher is not in your PATH, falls back to the REST API to download the files.
Note
Thank you for your interest in this GitHub action, however, right now we are not taking contributions.
We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features weรขยยre working on and what stage theyรขยยre in.
We are taking the following steps to better direct requests related to GitHub Actions, including:
-
We will be directing questions and support requests to our Community Discussions area
-
High Priority bugs can be reported through Community Discussions or you can report these to our support team https://support.github.com/contact/bug-report.
-
Security Issues should be handled as per our security.md
We will still provide security updates for this project and fix major breaking changes during this time.
You are welcome to still raise bugs in this repo.
What's new
Please refer to the release page for the latest release notes.
Usage
- uses: actions/checkout@v6
with:
# Repository name with owner. For example, actions/checkout
# Default: ${{ github.repository }}
repository: ''
# The branch, tag or SHA to checkout. When checking out the repository that
# triggered a workflow, this defaults to the reference or SHA for that event.
# Otherwise, uses the default branch.
ref: ''
# Personal access token (PAT) used to fetch the repository. The PAT is configured
# with the local git config, which enables your scripts to run authenticated git
# commands. The post-job step removes the PAT.
#
# We recommend using a service account with the least permissions necessary. Also
# when generating a new PAT, select the least scopes necessary.
#
# [Learn more about creating and using encrypted secrets](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)
#
# Default: ${{ github.token }}
token: ''
# SSH key used to fetch the repository. The SSH key is configured with the local
# git config, which enables your scripts to run authenticated git commands. The
# post-job step removes the SSH key.
#
# We recommend using a service account with the least permissions necessary.
#
# [Learn more about creating and using encrypted secrets](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets)
ssh-key: ''
# Known hosts in addition to the user and global host key database. The public SSH
# keys for a host may be obtained using the utility `ssh-keyscan`. For example,
# `ssh-keyscan github.com`. The public key for github.com is always implicitly
# added.
ssh-known-hosts: ''
# Whether to perform strict host key checking. When true, adds the options
# `StrictHostKeyChecking=yes` and `CheckHostIP=no` to the SSH command line. Use
# the input `ssh-known-hosts` to configure additional hosts.
# Default: true
ssh-strict: ''
# The user to use when connecting to the remote SSH host. By default 'git' is
# used.
# Default: git
ssh-user: ''
# Whether to configure the token or SSH key with the local git config
# Default: true
persist-credentials: ''
# Relative path under $GITHUB_WORKSPACE to place the repository
path: ''
# Whether to execute `git clean -ffdx && git reset --hard HEAD` before fetching
# Default: true
clean: ''
# Partially clone against a given filter. Overrides sparse-checkout if set.
# Default: null
filter: ''
# Do a sparse checkout on given patterns. Each pattern should be separated with
# new lines.
# Default: null
sparse-checkout: ''
# Specifies whether to use cone-mode when doing a sparse checkout.
# Default: true
sparse-checkout-cone-mode: ''
# Number of commits to fetch. 0 indicates all history for all branches and tags.
# Default: 1
fetch-depth: ''
# Whether to fetch tags, even if fetch-depth > 0.
# Default: false
fetch-tags: ''
# Whether to show progress status output when fetching.
# Default: true
show-progress: ''
# Whether to download Git-LFS files
# Default: false
lfs: ''
# Whether to checkout submodules: `true` to checkout submodules or `recursive` to
# recursively checkout submodules.
#
# When the `ssh-key` input is not provided, SSH URLs beginning with
# `git@github.com:` are converted to HTTPS.
#
# Default: false
submodules: ''
# Add repository path as safe.directory for Git global config by running `git
# config --global --add safe.directory <path>`
# Default: true
set-safe-directory: ''
# The base URL for the GitHub instance that you are trying to clone from, will use
# environment defaults to fetch from the same instance that the workflow is
# running from unless specified. Example URLs are https://github.com or
# https://my-ghes-server.example.com
github-server-url: ''
Scenarios
- Checkout V5
- Checkout V4
- What's new
- Usage
- Scenarios
- Fetch only the root files
- Fetch only the root files and
.githubandsrcfolder - Fetch only a single file
- Fetch all history for all tags and branches
- Checkout a different branch
- Checkout HEAD^
- Checkout multiple repos (side by side)
- Checkout multiple repos (nested)
- Checkout multiple repos (private)
- Checkout pull request HEAD commit instead of merge commit
- Checkout pull request on closed event
- Push a commit using the built-in token
- Push a commit to a PR using the built-in token
- Recommended permissions
- License
Fetch only the root files
- uses: actions/checkout@v6
with:
sparse-checkout: .
Fetch only the root files and .github and src folder
- uses: actions/checkout@v6
with:
sparse-checkout: |
.github
src
Fetch only a single file
- uses: actions/checkout@v6
with:
sparse-checkout: |
README.md
sparse-checkout-cone-mode: false
Fetch all history for all tags and branches
- uses: actions/checkout@v6
with:
fetch-depth: 0
Checkout a different branch
- uses: actions/checkout@v6
with:
ref: my-branch
Checkout HEAD^
- uses: actions/checkout@v6
with:
fetch-depth: 2
- run: git checkout HEAD^
Checkout multiple repos (side by side)
- name: Checkout
uses: actions/checkout@v6
with:
path: main
- name: Checkout tools repo
uses: actions/checkout@v6
with:
repository: my-org/my-tools
path: my-tools
- If your secondary repository is private or internal you will need to add the option noted in Checkout multiple repos (private)
Checkout multiple repos (nested)
- name: Checkout
uses: actions/checkout@v6
- name: Checkout tools repo
uses: actions/checkout@v6
with:
repository: my-org/my-tools
path: my-tools
- If your secondary repository is private or internal you will need to add the option noted in Checkout multiple repos (private)
Checkout multiple repos (private)
- name: Checkout
uses: actions/checkout@v6
with:
path: main
- name: Checkout private tools
uses: actions/checkout@v6
with:
repository: my-org/my-private-tools
token: ${{ secrets.GH_PAT }} # `GH_PAT` is a secret that contains your PAT
path: my-tools
${{ github.token }}is scoped to the current repository, so if you want to checkout a different repository that is private you will need to provide your own PAT.
Checkout pull request HEAD commit instead of merge commit
- uses: actions/checkout@v6
with:
ref: ${{ github.event.pull_request.head.sha }}
Checkout pull request on closed event
on:
pull_request:
branches: [main]
types: [opened, synchronize, closed]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
Push a commit using the built-in token
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- run: |
date > generated.txt
# Note: the following account information will not work on GHES
git config user.name "github-actions[bot]"
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git add .
git commit -m "generated"
git push
NOTE: The user email is {user.id}+{user.login}@users.noreply.github.com. See users API: https://api.github.com/users/github-actions%5Bbot%5D
Push a commit to a PR using the built-in token
In a pull request trigger, ref is required as GitHub Actions checks out in detached HEAD mode, meaning it doesnรขยยt check out your branch by default.
on: pull_request
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
with:
ref: ${{ github.head_ref }}
- run: |
date > generated.txt
# Note: the following account information will not work on GHES
git config user.name "github-actions[bot]"
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
git add .
git commit -m "generated"
git push
NOTE: The user email is {user.id}+{user.login}@users.noreply.github.com. See users API: https://api.github.com/users/github-actions%5Bbot%5D
Recommended permissions
When using the checkout action in your GitHub Actions workflow, it is recommended to set the following GITHUB_TOKEN permissions to ensure proper functionality, unless alternative auth is provided via the token or ssh-key inputs:
permissions:
contents: read
License
The scripts and documentation in this project are released under the MIT License
Top Related Projects
Run your GitHub Actions locally ๐
Jenkins X provides automated CI+CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton
Workflow Engine for Kubernetes
Concourse is a container-based automation system written in Go. It's mostly used for CI/CD.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot