Path to action in the same repository as workflow

[raquelhortab]

I’d like to explain something I went through as I think the documentation could maybe specify this case a bit more or it could even be a bug (not sure though).

I have a repository with a rails app. The repository has its own action to run tests in a docker container. The workflow’s path would be /.github/workflows/main.yml while the action’s path would be /.github/actions/automatic-tests/action.yml. 

The thing is, I tried following the documentation, where it says:

Selection_306.png866×333 25.3 KB

So, in the workflow’s main.yml I set:

uses: ./.github/actions/automatic-tests@master

However, when the action was triggered, I got the following error:

Can't find 'action.yml' or 'Dockerfile' under
'/home/runner/work/hello_world_github_actions/hello_world_github_actions/.github/actions/automatic-tests@master'.
Did you forget to run actions/checkout before running your local action?

I fond it weird that the repository name got duplicated in the path (…/hello_world_github_actions/hello_world_github_actions/…). I also tried setting it to ./…/.github to workaround this second hello_world_github_actions directory but it still failed, I believe it was because there is no reference to raquelhortab, which is my github account name.

I got it to work by setting the whole repository reference, as I would do if I wanted to use an action in another repository (with a previous checkout as well):

uses: raquelhortab/hello_world_github_actions/.github/actions/automatic-tests@master

However, I’d like to know if this is the expected behaviour or whether I did something wrong.

[Yanjingzhu]

Hi raquelhortab,

When use action in the same repository as workflow, we need to add actions/checkout before running your local action. And you don’t need to add @master behind your action path.

Please see my example:

name: use my action
on: push
jobs:

my_first_job:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v1

- name: My first step

uses: ./.github/actions/my-action

>> I fond it weird that the repository name got duplicated in the path (…/hello_world_github_actions/hello_world_github_actions/…).

For this question, the path is as expected. It is the default directory path .

workspace.png765×217 7.96 KB

Please refer to this document: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/using-environment-variables

[adehad]

I struggled to see the key difference here in indentation level when reviewing all other docs and comments (except this one). Thanks.

For anyone else maybe this is a helpful example image from what I needed to change:

From the PR here:
pycontribs/jira#2339

[gblikas]

This issue seems to be related and was something I ran into. Is there any chance get the a real feature? 

[raquelhortab]

The thing is I did add actions/checkout, and it didn’t work. I tried it again today and it doesn’t work if I use a relative path (./.github/…), only when using the whole path (raquelhortab/hello_world_github_actions/.github/…).

Here’s the code for .github/workflows/main.yml that I can’t get to work with your solution (I know that adding @master it’s not necessary but this is not the problem):

name: CI
on:

push:

branches:

- master
jobs:

build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@master
  name: Checkout
- uses: ./.github/actions/automatic-tests@master
  name: Test

Meanwhile, this is working perfectly:

name: CI
on:

push:

branches:

- master
jobs:

build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@master
  name: Checkout
- uses: raquelhortab/hello_world_github_actions/.github/actions/automatic-tests@master
  name: Test

[Yanjingzhu]

When you use relative path,  there is no need to specific branch. It will find the path in the Github workspace.  Just use next code snippet: 

- uses: ./.github/actions/automatic-tests

When adding @master , it will look for a folder named automatic-tests@master.

[raquelhortab]

Thanks for replying, but what should I use instead of @master? If I don’t add any tag it complains.

With the following code:

name: CI
on:

push:

branches:

- master
jobs:

build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout
  name: Checkout
- uses: ./.github/actions/automatic-tests@master
  name: Test

I get:

Your workflow file was invalid: The pipeline is not valid. .github/workflows/main.yml (Line: 14, Col: 13): Expected format {org}/{repo}[/path]@ref. Actual 'actions/checkout',Input string was not in a correct format.

In your first answer you used @v1. I created a release named v3 and used its tag (actions/checkout@v3) and it doesn’t work either. 

Failed to download action 'https://api.github.com/repos/actions/checkout/tarball/v3'

It seemed like the tag was referent to the actions repo not to my repo so I tried your exact example (actions/checkout@v1) and got the original error as well…

The code:

name: CI
on:

push:

branches:

- master
jobs:

build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v1
  name: Checkout
- uses: ./.github/actions/automatic-tests@master
  name: Test

The errror:

##[error]Can't find 'action.yml' or 'Dockerfile' under '/home/runner/work/hello_world_github_actions/hello_world_github_actions/.github/actions/automatic-tests@master'. Did you forget to run actions/checkout before running your local action?

Using your @v1 option but with the full path it works again.

[airtower-luna]

I think what @yanjingzhu meant was not to use a tag in your action path, like so:

steps:
    - uses: actions/checkout@v1
      name: Checkout
    - uses: ./.github/actions/automatic-tests
      name: Test

[raquelhortab]

**bleep**, you meant the tag in the tests step… I had really not seen it, thought you were talking about the one in actions/checkout@v1. It works now, thanks! However, what about if I wanted to use another branch different from master? where would I specify it? is that the “@v1” in actions/checkout@v1 ?

[Yanjingzhu]

If you want to checkout other branches, you could specify ref of checkout action:

- uses: actions/checkout@v1
  with:
    ref: my-branch

For more checkout scenarios , please refer to https://github.com/actions/checkout#scenarios 

[hyst3ric41]

For everybody facing this issue, as the official documentation says here https:// docs . github . com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow:

You call a reusable workflow by using the uses keyword. Unlike when you are using actions within a workflow, you call reusable workflows directly within a job, and not from within job steps.

This means that using the form ./.github/workflows/my-workflow.yml will not work if you use it with the structure:

jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
      - uses: ...
      - uses: ./.github/workflows/my-workflow.yml
      - run: ...
      - uses: ...

You should use instead:

jobs:
  my-job:
    uses: my-job: ./.github/workflows/my-workflow.yml

I know, this makes no sense, anyways…

[neil90-db]

The docs for this are utterly useless.

[vignesh-desk]

• name: Get azure Test product config
  id: config1
  uses: ./.azure/actions/config/${{ github.event.inputs.stage }}/

Unrecognized named-value: ‘github’. Located at position 1 within expression: github.event.inputs.stage .github/workflows/azure-build.yml (Line: 55, Col: 15): Unrecognized named-value: ‘github’. Located at position 1 within expression: github.event.inputs.stage

how to give the dynamic path to the the uses attribute ? Any idea ?

[BL-marcusrogers]

Solution for me was to use a trailing slash:

uses: ./.github/actions/my-action/

instead of

uses: ./.github/actions/my-action

Also if you aren't committing your build output directory, make sure you are building (tsc) your action in the workflow before you reference it if it's in typescript and you aren't using @master (i.e. the version you want hasn't yet been built and merged to your master branch).

[ZhaoKunLong]

Preview:

-. Your actions yml is in here /.github/actions/automatic-tests/action.yml.
-. In the Main.yml want to use it.

Key point:

1. If we want to use the repo code, need to use checkout to download the repo.
   1. default will use the master/main branch code. If you want another branch, should use ref to define it.
2. The - use support the relative path. and it's based on the root path. Also just need the action.yml folder path.
3. For the action.yml if use Dockerfile, When building the image in the Dcokerfile the root path is the Dockerfile folder.

Solution, I'm doing it in my local and tested it.

• the main workflow
• path: github/workflows/main.yml
• The ref is not necessary

name: use my action
on: push

jobs:
  my_first_job:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
      with:
        ref: 'master'
    - name: My first step
    - uses: ./.github/actions/automatic-tests

• This is the action
• path: .github/actions/automatic-tests/action.yml

name: "Hello My Actions"
description: "Greet someone"
author: "xxxxx@github.com"

runs:
  using: "docker"
  image: "Dockerfile"

branding:
  icon: "mic"
  color: "purple"

• If you use Docker, DockerFile should be in the .github/actions/automatic-tests/
• Docker file

FROM debian:9.5-slim
RUN echo 'hello'

[kalanatd]

@ZhaoKunLong @josegpulido @Yanjingzhu Tagging you since all of you have given detailed answers which resembles closely with my issue.

I am facing the same issue when trying to find a workaround for using a Reusable workflow between two private repos:

Context: I am trying to use a central repo for all the Workflows and refer to that location from other repos.

Legend:
Central Repo: Contains all the Reusable Workflows. (If we edit a file in here we should not have to edit each and every repo's workflow files)
Calling Repo: A repo which runs Workflows, This repo will try to refer the workflows from the Central repo.

I executed a 'cat' command of the workflow and I can see that the workflow file exists and it is readable. But the 'uses' command does not identify the file.

Caller Workflow from Calling repo: [There are some comments I added]

name: Calling Reusable Workflows

on: [ push ]

jobs:
  download-remote-repo:
    runs-on: ubuntu-latest
    steps:
    - name: Get private repo with action
      uses: actions/checkout@v2
      with:
        repository: kalanatd/central-repo
        ref: main
        token: ${{ secrets.PAT_TOKEN }}
    - name: List Files After remote Checkout
      run: |
        pwd
        ls -a                 // I can see the checked out remote repo files in here
        ls -al .github/workflows
        cat ./.github/workflows/workflow.yml             // Can read the file without any issue
    - name: Run a workflow file
      uses: ./.github/workflows/workflow.yml 

Note: In aboe scenario ./.github/workflows/workflow.yml is dynamically checked out to the Runner's workspace. Even though 'run' commands can see that file 'uses' command does not use it.

[1] Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/caller-repo/caller-repo/workflow.yml'. Did you forget to run actions/checkout before running your local action?

[2] https://github.github.io/actions-cheat-sheet/actions-cheat-sheet.pdf

[airtower-luna]

    - name: Run a workflow file
      uses: ./.github/workflows/workflow.yml

You're trying to run a reusable workflow as a step, that's not possible. A reusable workflow must be called at the job level, contrary to custom actions (which must be called as steps). See: https://docs.github.com/en/actions/using-workflows/reusing-workflows#calling-a-reusable-workflow

As a side note, mentioning people just because they answered similar questions is rather impolite.

[iSuslov]

If you like me can't read long posts about github actions anymore:

For composite actions (not workflows):

Checkout is mandatory. Only on step level.

This works:

      - uses: actions/checkout@v3

      - name: Reuse action
        uses: ./.github/actions/build

      - uses: actions/checkout@v3

      - name: Reuse action
        uses: ./.github/actions/build/

This doesn't work:

      - uses: actions/checkout@v3

      - name: Reuse action
        uses: ./.github/actions/build/action.yml

      - uses: actions/checkout@v3

      - name: Reuse action
        uses: .github/actions/build

PS: Github actions documentation sucks! I wish in the era of AI layoffs those devs who designed github actions won't lose their jobs. Especially those who designed sharing across jobs. Humanity won't make it if these people happen to build cars or houses.

[Dmitry1987]

also a full path doesn't work in a linux machine. i am caching the repo in AMI image specifically to avoid checkout action and shorten build time (gigantic monorepo) but referencing an existing folder somewhere else is impossible with a full path, so I would need to trick it with ./../../../../home/ubuntu/myrepo/.github/etc 😆

[usualdesigner]

Can confirm that ../ does not work on MacOS too.

[0xZaak]

Hi,

Am facing same issue here, and opened an issue here https://github.com/orgs/community/discussions/59942.

The issue was not there, until i have added the notification script to run and it gives me the issue even on the checkout? any ideas?

[0xZaak]

This is my yaml am using and facing issue with!

#Issue Type Name
name: Issue
#Declaring the branches and types
on:
  issues:
    types: 
      - "opened"
#Declaring all jobs and flows
jobs:
  issue:
    name: Issue Opened
    runs-on: ubuntu-22.04
    permissions:
      issues: write
    steps:
      #Checkout Code
      - name: Checkout Code
        uses: actions/checkout@v2

      #Auto Assignation
      - name: Auto Assign Issue
        uses: pozil/auto-assign-issue@v1
        with:
            repo-token: ${{ secrets.GITHUB_TOKEN }}
            assignees: iimrx
            numOfAssignee: 1

      #Setting up python version and action setup
      - name: Set up Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.10.6'

      #Installing all needed dependencies
      - name: Installing Dependencies
        run: |
          python3 -m pip install --upgrade pip
          pip install requests argparse

      #Push notification to discord channel
      - name: Push Notification To Discord
        run: python3 extra/scripts/notification/DiscordNotifications.py -u ${{secrets.DOCKER_USER}} -t issues -i ${{github.event.issue.title}} -l ${{secrets.DISCORD_BUILD_WEBHOOK_URL}}

[0xZaak]

In my case it was a Permission issue, where in the above script we can see i have added permissions of the issue to be write which overwrites the permissions of content and thats why it cant see the path. So i have added the following permission and it solves the problem (Note: in my case the workflow is running in private repo and thats why it needs the content permissions) :

permissions: contents: read

[axherrm]

In case some does the same mistake getting the described error message but above answers do not help:

My error was that my action was at ./folder/my-action.yml and I called it by ./folder/my-action when the action should've been at ./folder/my-action/action.yml

[thejeff77]

For anyone wanting to know how to run the action in the root (main repo is the action), use this:

      - uses: actions/checkout@v4
      - id: testLocalAction
        uses: ./

[gardo984]

Here are the details on the official documentation:

• https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-an-action-in-the-same-repository-as-the-workflow

[fhg-isi]

I got

Error: Failed to load /home/runner/work/foo/foo/./.github/actions/my-custom-action/action.yml

and assumed that the path was wrong. However, there has been an issue inside the file.
A clearer error message might be "Error: Invalid syntax in action file /home/runner/work/foo/foo/./.github/actions/my-custom-action/action.yml"

[Lumi669]

in my case, i simply put the name the file as action.yml and put it in .github/actions/aws-credentials dir, then the error is gone.

[ericsciple]

Hi everyone 👋

Thank you for all the feedback! The engagement on this thread helped us prioritize it, and we've been working on a solution. We'd love your input.

The problem

Reusable workflows and composite actions can't reference other actions in the same repo at the same version. Today you have two options, and neither works well:

1. ./path — Resolves to the workflow run's workspace, not the reusable workflow's or action's repo.
2. Hardcoded refs like my-org/repo/setup@v1 — Requires manual updates on every release, can't be tested before tagging, and defeats SHA pinning.

What we're proposing

We're exploring a new $/ syntax that means "this repo, at this SHA".

Reusable workflow example:

# my-org/shared/.github/workflows/ci.yml

on: workflow_call

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: $/build   # → my-org/shared/build@<same-SHA>

When someone calls this workflow at v2, the $/ references resolve to the same SHA. The actions stay in sync with the workflow automatically.

Composite action example:

# my-org/repo/build/action.yml

runs:
  using: composite
  steps:
    - uses: $/shared-setup    # → my-org/repo/shared-setup@<same-SHA>
    - uses: $/helpers/lint    # → my-org/repo/helpers/lint@<same-SHA>

The same syntax works in composite actions. If build/action.yml calls $/shared-setup, both resolve to the same SHA.

How it works:

The $/ resolves based on where it appears, using the same repo and SHA as the YAML file containing it.

Key points:

Syntax	Meaning
./	Filesystem relative (whatever's checked out)
$/	This repo, at this SHA
org/repo/path@ref	Explicit remote reference

Benefits:

• Build composable action libraries from smaller, reusable pieces
• Version-safe: sibling actions automatically match the caller's ref
• No checkout required
• SHA pinning propagates throughout: if a caller pins @abc123, internal refs use @abc123 too
• No breaking changes: existing workflows continue to work unchanged

Will this work for your scenarios?

We think this addresses the core pain points, but want to make sure we're not missing anything:

1. Does the $/ syntax make sense to you?
2. Does this fully solve the problem, or would you still need workarounds?

Thanks again for the feedback and helping prioritize this! We're looking forward to hearing your thoughts.

— The GitHub Actions Team

[avishj]

Hi @ericsciple, I was wondering if there's an update on this feature/timelines. It would be immensely useful. Thanks.

[neilime]

Hi @ericsciple, I am very interested to having some news on this feature too, can you give us some news? Thanks a lot.

[ericsciple]

I'm hopeful soon. This solution is a key part of a larger set of work, that is currently in progress.

[mnahkies]

Also really looking forward to this - it would make testing changes to repositories that contain sibling actions much simpler, as well as reducing general toil around bumping versions

[asdkant-bf]

any update on this? what should I follow to get notified of any further progress?

[jsoref]

• @ericsciple Path to action in the same repository as workflow #26245 (reply in thread) wrote:

  In the private repo containing your actions, go to Settings → Actions → General → Access and select "Accessible from repositories owned by [user]" (or "Accessible from repositories in the [org] organization" for org-owned repos).

Unfortunately, no one told the /edit/ endpoint about this change:

Selects an action to run as part of a step in your job. An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a published Docker container image.

[ericsciple]

Thanks! I opened an issue:

• Update step uses description and link to docs actions/languageservices#319

[jsoref]

@ericsciple, I tried to use the private actions access... Our world looks like this:

GarnerCorp/build-actions

is a public repository with a number of handy github actions

GarnerCorp/private-test-action

is a composite action

runs:
  using: composite
  steps:
    - name: Retrieve GarnerCorp/build-actions
      uses: actions/checkout@v6
      with:
        repository: GarnerCorp/build-actions
        path: ${{ github.action_path }}/build-actions

    - name: Validate Inputs
      env:
        INPUTS: ${{ toJSON(inputs) }}
      shell: bash
      run: |
        "$GITHUB_ACTION_PATH/build-actions/scripts/report-missing-inputs.pl"

    - name: Add action scripts to path
      shell: bash
      run: echo "$GITHUB_ACTION_PATH/scripts" >> "$GITHUB_PATH"

....
    - name: Configure Kubernetes Pull secrets
      uses: GarnerCorp/build-actions/google-k8s-pull-secrets@main
      id: pull-secrets
      with:
        ...

The private action here is trying to use the public action, in two ways, one because it wants access to the path to a script (to reuse Validate Inputs).

If there was an easy way for me to get the path for GarnerCorp/build-actions (which I implicitly use via Configure Kubernetes Pull secrets / GarnerCorp/build-actions/google-k8s-pull-secrets@main later), I could skip that checkout. But, I don't think I have access to that. So, I have to checkout a public action in addition to having github retrieve the same action earlier (because the uses: statements trigger eager downloads before any steps actually run).

The obvious change of my workflow in GarnerCorp/something-private to:

    steps:
      - uses: GarnerCorp/private-test-action@main
        with:
          ...

GarnerCorp/something-private

this private repository uses the private-test-action repository which in turn uses the public build-actions repository:

    steps:
      - uses: actions/checkout@v6
        with:
          repository: GarnerCorp/private-test-action
          ssh-key: "${{ secrets.CHECKOUT_PRIVATE_ACTION_KEY }}"
      - uses: ./
        with:
          ...

---

Unfortunately, the obvious change to private-test-action fails because:

Error: Repository path '/home/runner/work/_actions/GarnerCorp/private-test-action/main/build-actions' is not under '/home/runner/work/something-private/something-private'
(an error thrown by actions/checkout).

If I want to migrate this stuff to work, I need to be able to not break my many consumers of the GarnerCorp/private-test-action action, which means I will need to do some really interesting acrobatics for the - name: Retrieve GarnerCorp/build-actions step. I guess I can use:

    - name: Retrieve GarnerCorp/build-actions
      uses: actions/checkout@v6
      with:
        repository: GarnerCorp/build-actions
        path: ${{ contains(github.action_path, '/work/_actions') && github.workspace || github.action_path }}/build-actions

    - name: Validate Inputs
      env:
        INPUTS: ${{ toJSON(inputs) }}
        BUILD_ACTIONS: ${{ contains(github.action_path, '/work/_actions') && github.workspace || github.action_path }}/build-actions
      shell: bash
      run: |
        "$BUILD_ACTIONS/scripts/report-missing-inputs.pl"

    - name: Add action scripts to path
      shell: bash
      run: echo "$GITHUB_ACTION_PATH/scripts" >> "$GITHUB_PATH"

That's a lot of bending over backwards. Note that both the Validate Inputs step would really benefit from a context that allowed access to the path for an action in the same manner that github.action_path is available (and used in Add action scripts to path). Certainly, having to re-evaluate the same expressions twice kinda sucks. Yes, I can sometimes use env:, but often the contexts I need aren't available at various places where I could use env:, but I also don't really want to pollute all steps with env: vars just because I want to share a resolved expression between two steps.

[jsoref]

Yeah, I'm not terribly interested in bundling, I'd much rather have a single current version. I don't want to have to cascade updates. It's a waste of my time and our money.

(I do use curl to retrieve things when necessary: https://github.com/check-spelling/gh-program-downloader -- GarnerCorp/build-actions uses it heavily)

But, as noted, the workflow + action already need to use the action for other purposes, so it'd be nice if I could get easy action to items in the thing. In the end, I'll probably wrap the script into its own action, it just seems silly to write another action to wrap that script -- probably 10-20 lines of extra yaml to wrap an 80 line file.

[ericsciple]

Thanks @jsoref for helping me understand the scenario better. Those are fair points.

[jsoref]

• Fwiw, I did switch the private action to use "$GITHUB_WORKSPACE/../../_actions/GarnerCorp/build-actions/main/scripts/report-missing-inputs.pl" per Path to action in the same repository as workflow #26245 (reply in thread)
• And I changed the workflows to directly use the private action per Path to action in the same repository as workflow #26245 (reply in thread)

I suspect that the lack of a $/ is part of the reason report-missing-inputs.pl is the way it is -- i.e. Adding the feature would let me wrap it and use it within the various build-actions and test the changes without having to bend over backwards.

[jsoref]

Fwiw, here's my attempt to make report-missing-inputs into an action: GarnerCorp/build-actions@main...report-missing-inputs-action -- I'd only really do this once $/ is available, because then I could change:

      uses: GarnerCorp/build-actions/report-missing-inputs@report-missing-inputs-action

to

      uses: $/report-missing-inputs

and theoretically commit both things in the same commit (I wouldn't, but it's important not to ask the runner to get two copies of the repository)

[jsoref]

• Fwiw, Refactor report-missing-inputs GarnerCorp/build-actions#96 ended up more or less exactly as I expected. I really don't know that it improved things. Certainly the nesting shown in Path to action in the same repository as workflow #26245 (reply in thread) is of questionable value.

[nyarly]

@ericsciple You've raised a design desire for SHA pinning with regard to sibling actions. One thing I'm trying to follow with that feature is how it would distinguish from a context variable that contained the local path to the checkout of the action's repository.

Intuitively, I expect that checking out an action is effectively a git clone of the appropriate action repository, and that it happens in the pre phase of the workflow run. Based on conversations here, I'm reminded that github.action_path doesn't make other actions in the repository available (despite the documentation about contexts saying "access files located in the same repository"), but a context variable like github.action_workspace or ..._checkout might provide that capability.

Also, I assume this would be abusing an implementation detail even if it did work, but I'd kind of expect that if uses: allowed expressions, ${{github.action_path}}/../sibling_action would do what one wants, but I can see arguments for an actual implementation now or in the future where the subdirectory of the repo gets pulled out by itself, and that the directories above action_path would be at best unknown.

All that said, if only so that I can understand better, how would you distinguish successfully SHA pinning an action from providing a single checkout of the action's repository?

[nyarly]

I'm asking "what are SHA pins good for" and I don't understand your previous bullets arguing for their value.

Presume for a moment that uses: allowed limited expressions.

Presume also (and this might be true, AFAIK) that uses: nyarly/actionpack/one@main performs a checkout of nyarly/actionpath somewhere in the runner's file system (before doing anything for the run), and that github.action_path points to <somewhere>/actionpack/one.

What I'm asking is, within one/action.yaml what would the difference be between:

uses: ${{github.action_path}}/../two
uses: $/two

Specifically, as a action author, what behavior could I benefit from by using $/ that I couldn't get with ${{github.action_path}}/..?

What I've understood so far is: "SHA pinning" and potentially static analysis.

It sounds like SHA pinning means that uses: $/two is equivalent to uses: nyarly/actionpack/two@<this SHA> - it's a second remote reference, so it calls for a second git clone of nyarly/actionpack, which incurs network traffic and delay. How is that better for me than an appropriate relative path reference? We already have a clone of nyarly/actionpack so a second pull seems unnecessary. A more cynical person might wonder if the slowdown of the run and charge against minutes weren't part of Github's motivation. ;)

Potential static analysis is perhaps more interesting, but I also wonder how strong a motivation that really is. Analysis would either have to pull the actions or be agnostic about their behavior. If the pull behavior were well defined (in other words if github.action_path does point to /actionpack/onein our examples), then resolving straightforward relative paths would be able to determine thatoneandtwoare sibling actions and treat them the same../foils static analysis anyway, so it's hard to accept SA as an argument againstuses:expressions unless./` is being disallowed.

[ericsciple]

Thanks @nyarly for the follow-up! Let me address your points:

1. No second fetch: $/ reuses the existing download

This might be the key misunderstanding to clear up: $/sibling does not mean another fetch.

When you call my-org/actions/build@v2, the runner downloads the repo content once. If build/action.yml contains uses: $/helper, the runner resolves that to the same repo at the same SHA. No extra network round-trip.

Note, since the beginning the runner has downloaded a full repo tarball because that's what the GitHub REST API offers. But that's an implementation detail. In the future we could potentially switch to fetching only the specific folder, if there is a strong reason. The $/ syntax abstracts over this: you're declaring a dependency, not relying on filesystem layout.

2. SHA pinning

SHA pinning matters because the caller controls the version. When you call my-org/actions/build@a1b2c3d4e5f..., any $/helper references inside build/action.yml automatically resolve to that same SHA. The caller remains in control.

Today ./ is incompatible with SHA pinning because it uses whatever happens to be checked out in the runner's workspace. The disk layout may not match the SHA.

3. Static analysis

$/ solves two problems:

1. The immediate need: Reusable workflow authors and composite action authors need a way to reference sibling actions from the same repo at the same SHA. Today there's no good solution for this.

2. Alignment with SHA pinning: $/ keeps the caller in control of the version, which enables future tooling and policy options.

[nyarly]

@ericsciple I'd like to candidly ask: are you using Co-pilot (or some other LLM) to compose your responses here?

[ericsciple]

@nyarly I've worked on this product for several years, and the details in my responses reflect my understanding of how it works. I've also spent many hours reading through the comments here and crafting responses to understand the real-world use cases and whether this fits.

[nyarly]

Thanks for addressing that and I apologize for any negative implication. I do appreciate the time and attention you're putting into this discussion.

[nyarly]

The $/ syntax abstracts over this: you're declaring a dependency, not relying on filesystem layout.

Conversely, $/ means that I rely on whatever new behavior it introduces, compared to "how a filesystem works" which I have long experience with, and have to rely on elsewhere in Actions.

In terms of examining alternatives, adding the $/ syntax and adding support for ${{github.action_path}}/.. both involve changes to Actions. They both would both effect the same requested feature. They would both allow the caller to control the version of the indirect action dependency.

To be clear, I only raise ./ because it is a) required by existing GHA use cases, as elaborated by @jsoref and b) it's an obstacle to future policy work. I sympathize with that design challenge, but I've avoided ./ in that past because it struck me as somewhat "unsafe."

I can see the argument that expressions in uses: would be somehow similarly unsafe, since it would allow build behavior to rely on files we can't know about in a static analysis context, but the reverse is also true: expressions in uses: are no worse than ./

[ChristopherHX]

adding the $/ syntax and adding support for ${{github.action_path}}/.. both involve changes to Actions. They both would both effect the same requested feature.

For reusable workflows we would need ${{ github.job_workflow_repo }}/..@${{ github.job_workflow_sha }} instead of existing github vars (lack of both lead to workaround using checkout + extracting oidc claims + adding oidc permissions recursively)

e.g. I had files in the reusable workflows repo that are not part of the calling repository, usually I added a fallback to the default branch, because pull_request could not even make use of the workaround.

I know this is feasible for a single person to implement within a month at least for composite actions, with pre step support, can provide an actions/runner prototype if you want to try this as I have written such code in my free time.

---

I would certainly upvote expressions in uses, but the reusable workflows file access problem is a very important problem as well that needs to be solved. ($/ at least provides a workaround via an child action to read the files, but still suboptimal that I cannot use an actions/checkout of the revision as well)

Expressions in uses looks less like an foreign body than the $/ proposal, since what happens with ./ for reusable workflow refs? They behave like $/ on job level, contradictory to step level ./ operating on file system.

[wei18]

Really glad to see $/ proposed — resolving against the same repo at the same SHA is exactly the right semantics for the fork problem, and it removes the hardcoded-ref duplication that has plagued composite actions for years.

One adjacent scenario worth keeping on the radar after $/ lands: cross-repository references. A common layout is a central "actions library" repo whose composite actions are consumed from many other repos; those still need org/repo/path@ref with the ref duplicated at every call site. I understand why it's out of scope here (the same-SHA guarantee doesn't translate across repos), just flagging it as the remaining gap once $/ covers the same-repo case.

In the meantime, for anyone who needs relative references working today: I maintain wei18/local-composite-action, which symlinks the action's existing _actions/ checkout next to $GITHUB_WORKSPACE, so plain uses: ./../org/repo/... paths resolve at the consumer's pinned SHA — pure bash, no extra checkout, no tokens. It covers same-repo references (until $/ ships) and cross-repo references (any repository already checked out under _actions).

[nodeselector]

Thanks to everyone who shared feedback and use cases here. The new $/ self-repository syntax is now generally available on github.com as well as ghe.com.

$/ means “this repo, at this SHA.”

- uses: $/.github/actions/automatic-tests

It requires no checkout or hardcoded ref and works in workflow steps, composite actions, nested composition, and reusable workflows. Self-hosted runners require version 2.336.0 or newer.

See the announcement and documentation. Thanks again, this discussion helped us prioritize and shape the solution.

[Banders2]

What is the timeline for ghe.com?

UPDATE
from the docs it also seems to be available in ghe.com

This announcement is just awesome news, really looking forward to replacing a lot of dynamic actions the coming days.

[jsoref]

It more or less works:

[simonjur]

just fyi for big repos this is actually worse, because initial self-hosted runner setup takes minutes instead of second or two.
what before only downloaded few external actions now download whole (probably shallow) repo which takes a lot of time
and you still have to do another checkout later... great idea but, not worth the switch 😢

[nodeselector]

Thanks for the feedback, @simonjur. You're right about the tradeoff here for big repos. Thanks for giving it a try. Will think about how we can improve here!

[varlucian]

@nodeselector Our enterprise has an allowed list of actions, and using the $/ self-repository syntax results in this error:

The action $/my/action is not allowed in my-repo because all actions must be from a repository owned by your enterprise, created by GitHub, or match one of the patterns: aws-actions/**@*, [...]

I tried to add an entry with $/* or $/** and even $/my/action, but the configuration is not saved, probably because it's not a valid syntax.

[nodeselector]

Working on a fix. $/ should not require an entry in the allowed actions policy.

[nodeselector]

@varlucian should be fixed. Let me know if you hit an issue at this point. Sorry for the friction here.

[varlucian]

Indeed it's working now. Thanks for the quick fix @nodeselector

[dvaske]

@nodeselector the $/ is awsome!, however I see in some of our runs an error message:

Error: <org>/actions/a8d07d71631e53e100288a236be9cb188862fec6/setup/action.yaml (Line: 27, Col: 13): Expected format {org}/{repo}[/path]@ref. Actual '$/build/java-version'

However the action works regardless, so just a bit confusing.
The workflow is a workflow_call using composite actions