Git snapshots are in early access. Reach out to enable them for your workspace.Git snapshots are intended to supersede Git checkout caching.Contact support →
Requirements
- A GitHub repository.
- A Namespace Linux, macOS, or Windows runner.
- A GitHub association that gives Namespace read-only access to the target organization and repositories.
Use Git snapshots in a workflow
Replaceactions/checkout with namespace-actions/code-checkout:
$GITHUB_SHA) into $GITHUB_WORKSPACE. It uses the runner’s Namespace credentials, so no GitHub token is needed.
The same step works on Linux and macOS runners, on both x64 and arm64. To run the job on macOS, replace runs-on with your Namespace macOS runner profile.
Inputs
For example, to check out into a subdirectory and also fetch
main for comparison:
ref: ${{ github.event.pull_request.head.sha }}.
Differences from actions/checkout
The action does not support everyactions/checkout option:
- It does not clean a nonempty destination or persist GitHub credentials.
- It does not expose submodule, LFS, sparse-checkout, or fetch-depth settings.
- GitHub Enterprise is not supported.
- Snapshot and authentication failures fail the step. There is no fallback to a direct Git clone.
How it works
Whenever a ref is requested, Namespace generates a snapshot of the repository contents and serves it from an internal Namespace cache. When multiple jobs request the same ref, as commonly happens in CI, the same snapshot is served to each job. This amortizes the checkout time across those jobs. Snapshots are ephemeral and are removed automatically after some time.Check out multiple private repositories
The runner’s default checkout credentials are scoped to the repository that triggered the workflow. To check out multiple private repositories, create a Namespace token with read access to each repository and pass its bearer token asNSGIT_CHECKOUT_TOKEN.
The GitHub association must allow Namespace to read every target repository. A checkout token does not expand the association’s access. Create the token in the same Namespace workspace as the runners and GitHub association.
Permissions with and without Git snapshots
Direct clones do not use the snapshot service and do not require Git snapshots to be enabled.
Git snapshots must be enabled for the runner’s workspace.
Create a token for Git snapshots
Installnsc, then sign in with nsc login and select the runner’s workspace. Create a token with one code/repository:read grant per repository and an ingress:*:access grant for the snapshot service:
.git, as the resource ID. To allow all repositories, replace the repository grants with:
NSGIT_CHECKOUT_TOKEN. Do not commit it to the workflow or print it in job logs. Keep the token ID for revocation, and replace the secret before the token expires.
Use the checkout action with Git snapshots
Use one action step per repository and distinct destination paths:Use nsgit with Git snapshots
Install or updatensgit on Linux or macOS:
Use nsgit without Git snapshots
Installnsgit as described above. Create a separate token with only repository read grants, without the ingress grant:
NSGIT_DIRECT_CHECKOUT_TOKEN and select --kind direct explicitly: