[Feature Request] Get source repo of reusable workflow easily

[joemarshall]

In OIDC, there is a property: job_workflow_repo_ref which links back to the current reusable workflow.

There are all sorts of reasons why you might want to know what version of the current workflow is running, e.g. to get hold of supplementary files, call other workflows etc.

Please please, pretty please, could you expose this into the main github context by default, so we don't have to hack things with OIDC tokens to get it.

There's a discussion of this on here, but I can't find any explicit feature request
#31054

[ossanna16]

Hi there @joemarshall and welcome to our community! Thank you for this feature request!

[ChristopherHX]

GitHub finally added github.workflow_ref/github.workflow_sha

See https://github.com/orgs/community/discussions/31054#discussioncomment-4373060 for an example.

We need github.job_workflow_ref / github.job_workflow_sha.

[asraa]

+1 this! It's been really inconvenient to require OIDC token perms just to figure out the reusable workflow's name and ref

[neilime]

And now with the new restriction introduced by https://github.blog/changelog/2023-06-15-github-actions-securing-openid-connect-oidc-token-permissions-in-reusable-workflows/

It is breaking changing every workflows that use nested workflows with this workaround....

It's a nightmare to work with Github actions and trying to be stable, mixing workaround for basic needs and dealing with breaking changes every month

[neilime]

Any news on this topic ?

[neilime]

@ossanna16 how can we help to make progress on this feature request?

[ossanna16]

Hi there @neilime! Thank you for reaching out. Unfortunately, there is no advice I can give you with regard to making progress on this feature request. Be assured that our product team evaluates feature requests on a regular basis.

[neilime]

Hi @ossanna16,

Thanks for your response. This issue has been affecting organizations for over two years now. Many teams relying on reusable workflows are still forced to use workarounds due to the lack of support for github.job_workflow_ref and github.job_workflow_sha, which complicates processes significantly.

The impact is growing, and it’s becoming increasingly challenging to manage. Addressing this would greatly benefit the community and improve workflow stability.

Thanks for your attention to this issue.

[neilime]

Hi @ossanna16,

Do you have any news for this issue?

[neilime]

Any chance to have this feature done in 2025?

[DanTheMan827]

+1 for this feature!

I have a workflow in a repo that is intended to be used by other repos and having to specify the repo and ref as inputs is clunky to say the least.

Perhaps add an action type that behaves similarly to composite, but makes it run in a completely isolated runner with its own context?

[Angivare]

It's been a real PITA working with reusable workflows because of this - basically any script that the workflow will run has to be either:

• Baked into the workflow file itself (not clean)
• Be relocated into another repository that contains 1 action for each script used in the original workflow (not clean either - and forces you to sync tags in different repos even though one is just a strict dependency of the other)
• Cloned from the reusable workflow's repo, by using a workaround to get the right ref (like using gh api /repos/${{github.repository}}/actions/runs/${{github.run_id}} -q .referenced_workflows[] & filtering out the right workflow - not clean either & error-prone especially if you reuse the same workflow multiple times)

The use-case is as simple as wanting to have a script written in any foreign language that we want to keep in its own file - so people can test it with the language-specific tooling outside of the GitHub Action runtime, but also to get linting etc.
Another common use I have for accessing files in a workflow is for fetching schemas to validate configuration files in the original repo (it makes sense for the schemas themselves to live in the callee workflow's repo, and passed as an input to the validator action).

Basically the equivalent of something as simple as run: bash ${{github.action_path}}/my-script.sh for a composite action requires a lot of set-up or dirty/complicated and error-prone workarounds to work within a reusable workflow, creating a lot of pain and friction when writing reusable workflows.

I would love to have feedback from the team on this issue - is it simply considered low-priority ? Or is it a problem you are planning to solve by making a bigger redesign (like cloning the whole callee workflow repo & exposing the cloned path, as is the case with composite actions) ?

[neilime]

Hi,

As OIDC is not available to workflows triggered by pull_request from forks for security reasons.

This is totally impossible to use reusable workflow in fork context. It is a shame that GitHub does not propose a viable solution to use Reusable workflow.

For the moment we can just use reusable workflows in the same repository or without using forks so basically in rarely useless cases.

@ossanna16, can you help on finding people who can help us on this blocking point.

[jenseng]

I was poking around at worker logs, and it looks like this is information is available on the runner, it's just not exposed in any of the contexts yet. For example, you should see something like this in Job Message that appears in the worker logs, along with other interesting information:

{
  // ...
  "variables": {
    // ...
    "system.workflowFileFullPath": {
      "value": "my/shared-actions-repo/.github/workflows/ci.yml"
    },
    // ...
    "system.workflowFileRef": {
      "value": "refs/heads/test-workflow-sha"
    },
    "system.workflowFileSha": {
      "value": "39600ce582c1eea949d4819f2a0f86c5b508bd0b"
    },
    // ...
  },
  // ...
  "contextData": {
    "github": {
      "t": 2,
      "d": [
        // ...
        {
          "k": "workflow_ref",
          "v": "my/app-repo/.github/workflows/ci.yml@refs/pull/2/merge"
        },
        {
          "k": "workflow_sha",
          "v": "8f7839e19bb30f05310af99fb57cd54043e85adb"
        }
      ],
      // ...
    },
    // ...
  }
}

The system.workflowFileFullPath, system.workflowFileRef, and system.workflowFileSha variables reflect the workflow that defines the currently running job, which may be different than that of the top-level workflow.

So the good news is this could probably be implemented within actions/runner without any backend changes. But the bad news is that even "simple" runner changes can be really hard to land 😭

Perhaps in the meantime we could make an action that extracts this information from the log, similar to get-job-uuid? 🤞

[jenseng]

Perhaps in the meantime we could make an action that extracts this information from the log

I needed this, so I went ahead and made get-job-workfow. Here's an example of how it can be used, see the docs for more information:

- uses: jenseng/get-job-workflow@v1
  id: job-workflow
- env:
    job_workflow_ref: ${{ steps.job-workflow.outputs.ref }}
    job_workflow_sha: ${{ steps.job-workflow.outputs.sha }}
  run: |
    echo "this reusable workflow was called via $job_workflow_ref ($job_workflow_sha)"

Give it a spin and let me know if you find any bugs. Also feel free to fork/adapt it for you needs 🤗