Reference workflow_call with context var

Hello

I am working on a fork of a private repository in which I have defined a reusable workflow (on: workflow_call).
I used that reusable workflow in other workflow just fine by setting the appropriate

uses: myusername/reponame/.github/workflows/reusable.yml@ref

However those workflows do not run on the organisation repo i forked from. Just nothing.
I imagined this is because the access token is not sufficient to see my fork.

So I changed the uses line to something like:

uses: ${{ github.repository }}/.github/workflows/reusable.yml@ref

I got this error invalid value workflow reference: references to workflows must be prefixed with format 'owner/repository/'

Changed to ${{ github.repository }}/reponame/ and i got

handling usage of workflow "${{ github.repository_owner }}/vog-zephyr-nodes/.github/workflows/sanity_build.yml@9831f7ee20137633a71f2cbdd6c04cfad8d608c3": can't obtain workflow file: resolving repository ID from nwo: creating github client: unexpected response `404` from `https://internal-api.service.iad.github.net/repos/$%***B%***B%***github.repository_owner%***%***D%***D/vog-zephyr-nodes/installation

Do you have any idea how to address this ?
Thanks.

Hi - I’m the product manager for reusable workflows.

I’m not sure if I’m understanding what you tried. Does this look right?

  • You have a private organization repo which you’ve forked
  • In your fork, you have a reusable workflow
  • In your fork, you have a regular workflow which calls the reusable workflow. That works fine
  • In your organization repo, you have a regular workflow and you’d like it to call the reusable workflow in your fork. This is not working

You’ve tried a few ways to reference the reusable workflow, but those aren’t working for you.

Let me know if I got something wrong.

Regardless of where your calling and called workflows are defined, you need to use the full path. We don’t support using context expressions. So it should look like your first attempt: “uses: myusername/reponame/.github/workflows/reusable.yml@ref”

Then next thing to try is to verify the visibility settings of your fork. I’m guessing your forked repository is set to private, and that’s why it’s not working for you. Here’s what the docs say:

A reusable workflow can be used by another workflow if any of the following is true:

  • Both workflows are in the same repository.
  • The called workflow is stored in a public repository.
  • The called workflow is stored in an internal repository and the settings for that repository allow it to be accessed. For more information, see “Managing GitHub Actions settings for a repository.”

Hi,

Thanks for your input.
You understood correctly, I’ll amend some of the things I said:

The organisation repository is “internal” and not private unlike what I said in my original post.
When I tested the reusable workflow in my fork I referenced my own repo (username/repo/path/to/workflow.yml@sha1)
That worked fine for the actions triggered in my repository. (push event for example).
When I merged to the organisation repository that did not work on the org repo. My first guess was because the authorisation token of the org repo could not see the forks, so I changed (in my fork) the reference to use ${{ github.repository }} instead of ‘org/repo’ which made sense to me because I cannot assume that the fork will live forever.
That did not work because of the error in the original post.
Yesterday (before your reply to this thread) I tried to reference the ‘org/repo’/workflow.yml’ instead of my fork’s that did not work either:

handling usage of workflow "SiemaApplications/vog-zephyr-nodes/.github/workflows/sanity_build.yml@9831f7ee20137633a71f2cbdd6c04cfad8d608c3": workflow was not found

(SiemaApplications is the org name). My guess is that the auth token does not have visibility on the parent repository. I tried to set the settings (third bullet point at the end of your message), that did not help. I guess only other repository at the organisation level can “see” workflows in internal repo.

Again, in my opinion, the ability to use the env context var would solve it, but I guess there’s a reason it is not possible :wink:

Thanks.

Hmm, okay. So here’s what I understand you’re at now:

  • You have merged your reusable workflow into the organization repository
  • There’s now a file called SiemaApplications/vog-zephyr-nodes/.github/workflows/sanity_build.yml, and it exists at SHA 9831f7ee20137633a71f2cbdd6c04cfad8d608c3
  • You have a calling workflow in the organization repository. Let’s say it’s called caller.yml - that means you have a file defined at SiemaApplications/vog-zephyr-nodes/.github/workflows/caller.yml
  • caller.yml references SiemaApplications/vog-zephyr-nodes/.github/workflows/sanity_build.yml

Next, you trigger caller.yml (maybe with a push). You get this error:

handling usage of workflow “SiemaApplications/vog-zephyr-nodes/.github/workflows/sanity_build.yml@9831f7ee20137633a71f2cbdd6c04cfad8d608c3”: workflow was not found

This is not expected. Since both the caller workflow and the reusable workflow are checked into the same repository, you should not have any issues with permissions at all.

Here’s some next things we can try:

  • Double-check that the reusable workflow exists at the referenced SHA. Or, simplify things by changing the SHA to a branch where you know the file exists
  • Open a support ticket. A support engineer may request your permission to view your repository to debug further. Or, add me as a read-only member to the repository

In case of errors, the caller workflow and the reusable workflows are in separate repositories: caller workflow is in my fork, reusable workflow is in upstream repository (SiemaApplications/vog-zephyr-nodes).

Does that make more sense ?

Okay, got it. Even in that case I think the next things to try are:

  • Double-check that the reusable workflow exists at the referenced SHA. Or, simplify things by changing the SHA to a branch where you know the file exists
  • Open a support ticket. A support engineer may request your permission to view your repository to debug further. Or, add me as a read-only member to the repository

I checked the sha1 and the workflows do exist.
I Created support ticket at Sign in to GitHub · GitHub

Great, thank you @nvincent-vossloh.

I wanted to circle back to this recommendation from earlier:

Then next thing to try is to verify the visibility settings of your fork. I’m guessing your forked repository is set to private, and that’s why it’s not working for you.

When I look at your support ticket, it shows that your fork nvincent-vossloh/dbg-github-actions has visibility set to private. This is why you’re not able to reference it from your upstream repository.

Hi, thanks for your reply.

The default visibility of an internal repository’s fork seems to be private. I went into the settings of the fork and the visibility cannot be changed:

Change repository visibility
For security reasons, you cannot change the visibility of a fork.

It make sense that I cannot promote to public, but surely I could make it to “internal”, although it does not make really sense to have an internal repository for a user account I guess.