Convert Figma logo to code with AI

actions logocheckout

Action for checking out a repo

7,366
2,305
7,366
635

Top Related Projects

66,890

Run your GitHub Actions locally ๐Ÿš€

4,672

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

66,890

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.

4,672

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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Build and Test

Checkout v6

What's new

  • Improved credential security: persist-credentials now stores credentials in a separate file under $RUNNER_TEMP instead 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:

  1. We will be directing questions and support requests to our Community Discussions area

  2. 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.

  3. 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

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

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

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