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.

[iimrx]

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?

[iimrx]

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}}

[iimrx]

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

[jenseng]

@ericsciple I think it's pretty rare, but here are some examples I've done/seen:

• Auto-generating a local composite action that induces actions/runner to pre-load a list of action refs, without actually running them. We (Netflix) use this in a (currently closed source) GHA linter to validate all uses within the current repo (i.e. are the refs valid? are the inputs/outputs used correctly?). While vscode-github-actions can do this in local dev, not everyone uses it, and we wanted a backstop in CI. And getting actions/runner to do it for us 1. is easier than dealing with tokens for private repos and 2. guarantees that cross-repo access is configured correctly (because if actions/runner's token can't load the action, then it won't work when a job tries to use it).
• Auto-generating a local composite action to specify a dynamic shell (since shell doesn't support expressions): https://github.com/ktakashi/dynamic-shell. That said, there are other ways of solving this.
• GitHub's own codeql-action appears to have complex PR workflows that use this extensively (putting files in a directory above, referencing those actions locally, etc.). It's possible it could be solved with $/, but I haven't dug deeply enough to know for sure. They're also building lots of things in that workflow, so who knows 🤷‍♂️
• @jsoref uses this approach to dynamically replace check-spelling's internal actions at runtime (I think for testing purposes?)

Perhaps others have some additional use cases? E.g. I could imagine having a matrix job where you want to test compatibility against multiple versions of an action defined in another repo.

[jsoref]

Yes, it lets me test things without having to publish the repository with the test content, and since the repository in question was going to be private, I needed a way to check it out. It made more sense to provide the inputs to the action than to have to write the glue into each workflow as I was testing.

[jsoref]

I use ./ in a lot of places. I use it to demand load actions so that I don't need to pay (⏲️) to download actions unless I need them: https://github.com/check-spelling/check-spelling/tree/prerelease/actions + https://github.com/check-spelling/check-spelling/blob/9853690d90b509a25d7541474d1e0c6176c2f5a6/action.yml#L586-L616

It mattered a lot more when the github/codeql-action cost 6s to download and when private repositories weren't going to be using codeql (but would be billed for each additional minute, so those 6s = 💸), but conceptually, I find it cleaner to not download actions unless I know I need them.

---

The idea of a $/ sounds intriguing. Certainly I run into lots of places that have a really hard time publishing coherently. But I don't think it'll fix most of the problems I encounter.

A common problem is that people tend to have a README.md file, and that file will be shown in the marketplace.

Consider:
https://github.com/marketplace/actions/check-spelling?version=v0.0.20-alpha3
https://github.com/marketplace/actions/check-spelling?version=v0.0.25

You want the readme for your release to match your release, but you can't because it's a tagged object.

That means people bend over backwards with all sorts of funny hacks.

I have code that I burn into my releases that points to tags because I want people to know if things are current / out of date: https://github.com/check-spelling/check-spelling/blob/c635c2f3f714eec2fcf27b643a1919b9a811ef2e/apply.pl#L161 which is referenced like this: https://github.com/check-spelling/check-spelling/blob/c635c2f3f714eec2fcf27b643a1919b9a811ef2e/unknown-words.sh#L3688
This means that my release process involves updating a few files presuming that a release will happen: check-spelling/check-spelling@c635c2f (and if I cared more about the readme, I'd have to change it at the same time).

Generally, people forget to update their version references, so people are constantly filing bugs like:

• docs (marketplace) still references checkout@v4 actions/setup-python#1194
• docs (marketplace) still references checkout@v5 actions/setup-python#1263

To pick on that marketplace example, here's what it looks like:
https://github.com/marketplace/actions/setup-python?version=v6.1.0

There are real examples where the actual examples don't match the published version, but I don't want to spend the time looking for them right now.

---

Offhand, I don't know that I'd use $/ particularly eagerly. It's certainly theoretically cleaner than what I'm doing. But if it eagerly resolved cascaded dependencies, then I'd almost certainly not want to use it. -- The fact that this question isn't answered is definitely a problem for me. And sure, I could test it, but since this is a proposal, I can't. Anyway, I'm still trying to get close to a v0.0.26 release so that I can suffer from the version bumping problems I've described here.

[ericsciple]

@jsoref Thanks for describing your scenario! $/ would resolve during job setup. Actions are downloaded during job setup to discover pre steps.

A different mechanism would be needed to solve the deferred download problem. ./ will continue to work for that use case since it resolves at step execution time against the filesystem.

[nyarly]

thanks for digging into the history here.

Not so much "digging in" as "having lived through!"

A concern I have with Actions in general that this is raising for the particular is that the platform design (not uniquely in the CI space) feels piecemeal, and the result is that platform authors are forced into "skew" choices - do I want a reusable workflow or to publish an action? Step or Job? PAT or CI App? Javascript or Composite? Those are choices that have complex trade-offs, some of which aren't immediately obvious at the outset, or remain clear during maintenance. Writing action configurations myself, I often find that my use case straddles a trade-off, as well.

On the one hand, I sympathize that CI is a deceptively intricate problem domain, and that the "best of both worlds" may not always be practical, or even possible.

In that frame of mind,

We felt a dedicated syntax ($/) better communicates the intent
rings dissonant. A new dedicated syntax becomes part of the list of alternations enumerated above, and as has been teased out in this thread, doesn't replace ./ or cover all the cases of static analysis you're hoping for.

Partly, I think what comes up is that the proposal reads as "$/ would be like ./ but for sibling component actions," except that to actually expand the "like... but" there needs 1000+ words about SHA pinning and temporal logic to explain the problem and how it's solved. It's a lot of intent for a single character to express.

Can I suggest: maybe a new map key is called for instead? Rather than uses: $/my_sibling_action, something like use_included: ./my_sibling_action. The motivation here is that the new step configuration key introduces a new contextual understanding of its meaning, without introducing a syntax change. From a documentation perspective, the needs for pre checkout and SHA pinning have a home that developers are more likely to find and appreciate than if they're a subsection of jobs.<job_id>.steps[*].uses

[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]

Part of the problem I have is that I sometimes imagine that nektos/act would work, and it isn't directory for directory compatible (especially for these quirks), but yes, I probably should just do that (I know it works, but I haven't spent that much time memorizing the quirks of the actions runtime on disk layout). It'd be better if GitHub gave a proper contract for this stuff. And a context (via steps or something else) for paths to actions would be much cleaner than guessing (and safer for an entity like act).

[jenseng]

same, i'm still waiting on this PR 💀

[ChristopherHX]

same, i'm still waiting on this PR 💀

The decay of nektos/act, this has made it's way into actions-oss/act-cli/issues/12.

@jsoref
I would have done this, if you really want to get the path to the action

    - name: Configure Kubernetes Pull secrets
      uses: GarnerCorp/build-actions/get-script-path@main
      id: script-path
    - name: Validate Inputs
      env:
        INPUTS: ${{ toJSON(inputs) }}
        BUILD_ACTIONS: ${{ steps.script-path.outputs.path }}
      shell: bash
      run: |
        "$BUILD_ACTIONS/report-missing-inputs.pl"

But actually moving "Validate Inputs" into build actions with it's own action.yml sounds more natural actions design.

# might need a syntax fixup, but this is possible
outputs:
  path:
    value: ${{ steps.meta.outputs.path }}
runs:
  using: composite
  steps:
    - name: Read metadata
      run: |
        echo "path=$GITHUB_ACTION_PATH/scripts" > $GITHUB_OUTPUT
      id: meta
      shell: bash
      env:
        GITHUB_ACTION_PATH: ${{ github.action_path }}

[jsoref]

I think validate-inputs only really works well as an action once $/ exists, otherwise I suffer from the silly things that caused the original discussion here to be opened. I think that's part of why it's just a script and a step written in a lot of places instead of a wrapped thing. I'm also not entirely certain how much overhead uses: entails. That said, when $/ ships, I'll probably create that action (actually, I might create it now and see about slowly migrating things / seeing how well it works).

As to creating an action just to expose an action's path is pretty expensive/silly when github's platform should just expose it for me. But, yes, if I really trip on it a lot, I could do something like that (probably would).

[ChristopherHX]

INMO Your initially example of this particular thread shows another weakness of missing expressions in uses.

long message

• $/ sounds like not applicable unless buildactions is backed into private-test-action, which you could do if you derivate from your example (so as asked for feedback, a workaround)

•     - name: Configure Kubernetes Pull secrets
        uses: GarnerCorp/build-actions/get-script-path@main
      - name: Configure Kubernetes Pull secrets
        uses: GarnerCorp/build-actions/another-action@main # we cannot reuse @main, since anchors do not allow yaml alias compositing a string

• (imagination)

      - name: Configure Kubernetes Pull secrets
        uses: GarnerCorp/build-actions/get-script-path@${{ vars.SHA }} # forbidden as discussed here as well
      - name: Configure Kubernetes Pull secrets
        uses: GarnerCorp/build-actions/another-action@${{ vars.SHA }}

• This could avoid the problem using the proposal, but you have to embed the other repo as (imagination) e.g. build-actions

      - name: Configure Kubernetes Pull secrets
        uses: ~/build-actions/get-script-path
      - name: Configure Kubernetes Pull secrets
        uses: ~/build-actions/another-action

• Splitting the fields of uses would allow yaml anchors reuse again (imagination)

      - name: Configure Kubernetes Pull secrets
        uses:
          repo: GarnerCorp/build-actions
          action: get-script-path
          ref: &ba main
          
      - name: Configure Kubernetes Pull secrets
        uses:
          repo: GarnerCorp/build-actions
          action: action2
          ref: *ba

As to creating an action just to expose an action's path is pretty expensive/silly

I believe the run step is more expensive than a extra composite call that is just an in memory operation + a single file read (except if we talk about act, that does not dedup action downloads)