GitHub Actions $/: Use Same-Repository Actions Without checkout

Use the same syntax for reusable workflows#

At the job level, call a reusable workflow in the same repository like this:

1
jobs:
2
  deploy:
3
    uses: $/.github/workflows/reusable-deploy.yml
4
    secrets: inherit

The reference must not include @main, @v1, or a commit suffix. GitHub resolves the file from the same repository and running commit. The reusable workflow documentation lists this as the recommended same-repository form and notes that it is not available on GitHub Enterprise Server.

GitHub’s workflow syntax reference summarizes the three common forms:

The new form is not a shorthand for a local filesystem path. It tells GitHub which repository object to load before the job’s workspace is available.

What “without checkout” does and does not mean#

$/ removes actions/checkout as a prerequisite for loading the action or reusable workflow. It does not populate the job workspace with every repository file.

Keep checkout when a step needs to read application source, package manifests, generated files, Dockerfiles, or scripts with run:. For example:

1
steps:
2
  - uses: $/.github/actions/lint
3
  - uses: actions/checkout@v4
4
  - run: pnpm lint

The first step can load the repository action directly. The second step is still required before pnpm lint can read the project files from the workspace. If the action itself needs files outside its own directory, either make those inputs explicit or retain checkout before calling it.

The same distinction applies to composite actions. A composite action can use $/ to call a sibling action without relying on the caller’s checkout, but a later run step still needs the files it reads to exist in the workspace.

Check the runner before rollout#

GitHub announced the feature on July 30, 2026 and requires GitHub Actions runner 2.336.0 or newer. That is a feature floor, not the same boundary as the 2.329.0 registration and enforcement work covered in the self-hosted runner minimum-version guide.

Before replacing local references across a fleet, verify:

1. The workflow runs on github.com, because the $/ form is not available on GitHub Enterprise Server.
2. Every self-hosted runner that can receive the workflow is at least 2.336.0.
3. The action path contains a valid action.yml or action.yaml.
4. Any reusable workflow declares the required workflow_call interface.
5. Steps that read source files still have an intentional checkout or another input mechanism.

If the same workflow must run on older runners or GHES, keep the workspace-relative ./ form with an explicit checkout, or use a repository reference supported by that environment. Do not add @ref to $/; it changes the syntax into an invalid reference.

Migrate one internal reference at a time#

Start with an action that does not need the caller’s source tree:

1
steps:
2
  - uses: $/.github/actions/setup-tooling

Run it from a branch and from a full-commit workflow invocation. Confirm that the action version matches the workflow commit, then migrate sibling actions and reusable workflows. Keep a checkout for jobs whose shell commands need the repository.

The Node24 self-hosted runner guide covers a separate runtime requirement for JavaScript actions. A workflow can satisfy the $/ feature floor and still fail because an action needs a newer Node runtime or a tool that is not installed on the host.

The practical benefit is consistency: internal actions and workflows follow the commit already being executed, so a caller pinned to a full-length SHA does not quietly load an internal action from a different branch. Treat the syntax as a repository-reference change, then verify the workspace assumptions independently.

FAQ#