reusable workflows, actions, local references and branching

[splitbrain]

Select Topic Area

Question

Body

I'm trying to set up a a bunch of reusable workflows and custom actions that will be reused by many other repositories. But I'm having some trouble with referencing things.

I try to give a simplified picture below. In my repository (lets call it example/actionflow) I have:

• Two custom actions.
  • .github/actions/action1/ (with action.yml and index.js)
  • .github/actions/action2/ (with action.yml and index.js)
• Multiple workflows with one that calls all others
  • .github/workflows/all.yml
  • .github/workflows/flow1.yml
  • .github/workflows/flow2.yml

So far so good. In a different repository (example/actiontest) I have the following:

jobs:
  all:
    uses: example/actionflow/.github/workflows/all.yml@devel

As you can see, I'm currently using the devel branch of the actionflow repo. I will continue working on it, while others might already use the stable main branch. Because of this, I want to avoid hardcoding any branch names in the workflows above, because that makes merging a pain.

So far this works fine for the workflows, by using relative paths in all.yml

jobs:
  first:
    uses: ./.github/workflows/flow1.yml
  second:
    uses: ./.github/workflows/flow2.yml

Above will run fine within the example/actiontest repo.

However where it breaks apart is when we add an action to one of the flows.

jobs:
  flow1:
    runs-on: ubuntu-latest
    steps:
      - name: run action1
        uses: ./.github/actions/action1

Running this within the example/actiontest repo will result in the following error:

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/actiontest/actiontest/.github/actions/action1'. Did you forget to run actions/checkout before running your local action?

So while the earlier, when using only workflows, the ./.github/ path correctly referenced the directory in the example/actionflow repository, the calls to actions now reference the example/actiontest repository and can no longer find the actions I want to use.

Of course I could always use a line like uses: example/actionflow/.github/actions/action1@devel, but that would hardcode the branch name.

So here's the question: how do I reference actions relative to the workflow file they are called from?

[RemyMachado]

This seem like a common use case and it's not explained in the official documentation.
Did you find the correct way to achieve it?

[splitbrain]

It simply seems to be unsupported. I ended up writing a script to quickly change the branch name in all actions and need to remember running it before merging. Similar to what @joshjohanning suggests below.

[joshjohanning]

When calling a reusable workflow, the repo isn't cloned to disk in the same way that referencing another action repo is. When referencing a reusable workflow, you just retrieve the workflow logic as if it was running from your original repo.

The reason you get this error is that it's expecting a local action (as in, local to the CALLING repo not the REUSABLE WORKFLOW repo)

Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/actiontest/actiontest/.github/actions/action1'. Did you forget to run actions/checkout before running your local action?

As far as I know, you either have to hardcode the branch name in the reusable workflow or somehow dynamically clone the reusable workflow repo and have the actions placed in the appropriate subdirectory it's expecting.

Updating the branch names can be a chore, especially if you have multiple, but some folks have created linting/parsing scripts to make sure the branch names all match before allowing a merge.

[RemyMachado]

Also @joshjohanning , sorry for reaching you again. I'm still so confused about why we need a PAT or Deploy key, when there is a setting that says:

Workflows in other repositories that are part of the 'org-name' organization can access the actions and reusable workflows in this repository. Access is allowed only from private repositories.

Is this only true if we don't try to checkout the other repository code?

[joshjohanning]

1. In your example you are using actions/checkout without telling which repository to pull, which would result in pulling Repo A (caller workflow) if I understood right.

Yes! That's correct

2. I may have explained my use case incorrectly. The actions are inside org/repo-b/.github/actions/ and I need to use them from org/repo-b/.github/workflows/ when called from another repository workflow org/repo-a/.github/workflows.

When I tried with absolute paths without token/ssh-key it didn't succeed to checkout the actions.

I still feel like you should be able to, from repo-a, reference an action in repo-b like this:

- uses: my-org/repo-b/.github/workflows/my-action@main

I usually don't place my custom actions under the .github/workflows folder, so there might be some oddness there, but otherwise that should work.

Glad you got something that will work for you regardless :)

---

I'm not sure I understand what GitHub Apps is for and how it would help in this situation. What I understood is that it's comparable to a Discord bot for automating Discord stuff, except here in the GitHub ecosystem for automating GitHub stuff. The workflow actions are already doing the automation, I don't understand why I would need to create a GitHub App.

Sort of similar yeah! You might use a GitHub App from the marketplace to integrate something like Azure Boards or Pipelines, and sometimes the Azure Boards app will make changes back to an issue or PR or similar.

An app you create is similar but it can be less fancy - you can simply use it for authentication purposes, replacing a PAT or "service account" user. I have a post here that might be helpful in explaining the use case: https://josh-ops.com/posts/github-apps/

[joshjohanning]

Also @joshjohanning , sorry for reaching you again. I'm still so confused about why we need a PAT or Deploy key, when there is a setting that says:

Workflows in other repositories that are part of the 'org-name' organization can access the actions and reusable workflows in this repository. Access is allowed only from private repositories.

Is this only true if we don't try to checkout the other repository code?

@RemyMachado that setting is explicitly for actions references; in the backend the token that is used to download the actions ahead of the job run is different than the ${{ github.token }} that everything running in the job is running under the context of. The ${{ github.token }} only has access to the current repo and that's it.

You can workaround this, kind of, by using embedding a composite action in your repo-b if you need to access repo-b's contents without needing to pass in a PAT or GitHub App token.

I have examples here:

• https://github.com/joshjohanning-org/composite-action-private-registry-docker-actions/blob/main/nested-composite-action-better/1-action/action.yml#L19
• https://github.com/joshjohanning-org/composite-action-private-registry-docker-actions/blob/main/nested-composite-action/action.yml#L23

An archive of the action's repo is downloaded to a folder path, and depending which method you use, you can find that folder path and access the contents of the repo without having to provide a PAT or use a GitHub's app authentication token.

[RemyMachado]

I have examples here:
https://github.com/joshjohanning-org/composite-action-private-registry-docker-actions/blob/main/nested-composite-action-better/1-action/action.yml#L19

You are right, it's working when using absolute paths for the actions even if they are in the same repository (repo-b). I found out that it's working as long as I'm not trying to checkout repo-b's code (it would require different access rights).

Thank you very much!

[joshjohanning]

Woot woot! No problem 🥳

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬