-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make reference accessible in reusable workflow #1264
Comments
I have the same issue, and would love some help! |
To solve this, we're now using this composite action (that implements @maxbergs's solution) https://github.com/canonical/get-workflow-version-action Example usage: # Reusable workflow (e.g. build_charm.yaml)
on:
workflow_call:
jobs:
foo:
runs-on: ubuntu-latest
steps:
- name: Get workflow version
id: workflow-version
uses: canonical/get-workflow-version-action@v1
with:
repository-name: canonical/data-platform-workflows
file-name: build_charm.yaml
# Use the version. For example:
- name: Install Python CLI
run: pipx install git+https://github.com/canonical/data-platform-workflows@'${{ steps.workflow-version.outputs.sha }}'#subdirectory=python/cli |
I am also interested in a solution for this. My use case is I have a repository within my org where I put shared workflows as well as composite actions. I often want to use composite actions within my reusable workflow in the same repository. I see that you can do this with reusable workflows, but not yet composite actions: https://github.blog/changelog/2022-01-25-github-actions-reusable-workflows-can-be-referenced-locally/
name: My Reusable Workflow
on:
workflow_call:
jobs:
my-reusable-workflow:
runs-on: ubuntu-latest:
steps:
- uses: mjhipp/shared-actions/actions/my-composite-action@{???} I would like to use whatever version I am using for the shared workflow for the called composite action, from the same repo as the called workflow. |
I'd love this new reference to be created as well. I'm facing the same problem. |
Presumably the github.job_workflow_sha which is "For jobs using a reusable workflow, the commit SHA for the reusable workflow file" should solve this but it appears that this variable isn't ever populated: actions/runner#2417 |
I have the same use case and having this implemented would be great for pinning version between the reusable and the composite action |
Add a reusable workflow to run Nextstrain builds so that we can centralize and standardize how our pathogen repos set up these builds. Motivated by the latest hiccup with the Snakemake upgrade that required fixes across multiple pathogen repos.¹ There are some "hacky" steps to get around the limitations of reusable workflows: 1. The 'ref' input is required to ensure that we checkout the matching ref within the reusable workflow since it is currently not possible to detect the called workflow's ref.² 2. Since reusable workflows cannot access environment variables set in the calling workflow, this uses the yaml-to-envvars workaround with an `env` input already used in the patheogen-repo-ci workflow.³ 3. We use a json-to-envvars workaround to allow for setting secrets as environment variables for the build runtime dynamically. ¹ https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1681328249848399 ² actions/toolkit#1264 ³ https://github.com/nextstrain/.github/blob/cc6f4385a45bd6ed114ab4840416fd90cc46cd1b/.github/workflows/pathogen-repo-ci.yaml#L25-L45
Add a reusable workflow to run Nextstrain builds so that we can centralize and standardize how our pathogen repos set up these builds. Motivated by the latest hiccup with the Snakemake upgrade that required fixes across multiple pathogen repos.¹ There are some "hacky" steps to get around the limitations of reusable workflows: 1. The 'ref' input is required to ensure that we checkout the matching ref within the reusable workflow since it is currently not possible to detect the called workflow's ref.² 2. Since reusable workflows cannot access environment variables set in the calling workflow, this uses the yaml-to-envvars workaround with an `env` input already used in the patheogen-repo-ci workflow.³ 3. We use a json-to-envvars workaround to allow for setting secrets as environment variables for the build runtime dynamically. ¹ https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1681328249848399 ² actions/toolkit#1264 ³ https://github.com/nextstrain/.github/blob/cc6f4385a45bd6ed114ab4840416fd90cc46cd1b/.github/workflows/pathogen-repo-ci.yaml#L25-L45
Add a reusable workflow to run Nextstrain builds so that we can centralize and standardize how our pathogen repos set up these builds. Motivated by the latest hiccup with the Snakemake upgrade that required fixes across multiple pathogen repos.¹ There are some "hacky" steps to get around the limitations of reusable workflows: 1. The 'ref' input is required to ensure that we checkout the matching ref within the reusable workflow since it is currently not possible to detect the called workflow's ref.² 2. Since reusable workflows cannot access environment variables set in the calling workflow, this uses the yaml-to-envvars workaround with an `env` input already used in the patheogen-repo-ci workflow.³ 3. We use a json-to-envvars workaround to allow for setting secrets as environment variables for the build runtime dynamically. ¹ https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1681328249848399 ² actions/toolkit#1264 ³ https://github.com/nextstrain/.github/blob/cc6f4385a45bd6ed114ab4840416fd90cc46cd1b/.github/workflows/pathogen-repo-ci.yaml#L25-L45
Add a reusable workflow to run Nextstrain builds so that we can centralize and standardize how our pathogen repos set up these builds. Motivated by the latest hiccup with the Snakemake upgrade that required fixes across multiple pathogen repos.¹ There are some "hacky" steps to get around the limitations of reusable workflows: 1. The 'ref' input is required to ensure that we checkout the matching ref within the reusable workflow since it is currently not possible to detect the called workflow's ref.² 2. Since reusable workflows cannot access environment variables set in the calling workflow, this uses the yaml-to-envvars workaround with an `env` input already used in the patheogen-repo-ci workflow.³ 3. We use a json-to-envvars workaround to allow for setting secrets as environment variables for the build runtime dynamically. ¹ https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1681328249848399 ² actions/toolkit#1264 ³ https://github.com/nextstrain/.github/blob/cc6f4385a45bd6ed114ab4840416fd90cc46cd1b/.github/workflows/pathogen-repo-ci.yaml#L25-L45
Add a reusable workflow to run Nextstrain builds so that we can centralize and standardize how our pathogen repos set up these builds. Motivated by the latest hiccup with the Snakemake upgrade that required fixes across multiple pathogen repos.¹ There are some "hacky" steps to get around the limitations of reusable workflows: 1. The 'ref' input is required to ensure that we checkout the matching ref within the reusable workflow since it is currently not possible to detect the called workflow's ref.² 2. Since reusable workflows cannot access environment variables set in the calling workflow, this uses the yaml-to-envvars workaround with an `env` input already used in the patheogen-repo-ci workflow.³ 3. We use a json-to-envvars workaround to allow for setting secrets as environment variables for the build runtime dynamically. ¹ https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1681328249848399 ² actions/toolkit#1264 ³ https://github.com/nextstrain/.github/blob/cc6f4385a45bd6ed114ab4840416fd90cc46cd1b/.github/workflows/pathogen-repo-ci.yaml#L25-L45
Add a reusable workflow to run Nextstrain builds so that we can centralize and standardize how our pathogen repos set up these builds. Motivated by the latest hiccup with the Snakemake upgrade that required fixes across multiple pathogen repos.¹ There are some "hacky" steps to get around the limitations of reusable workflows: 1. The 'ref' input is required to ensure that we checkout the matching ref within the reusable workflow since it is currently not possible to detect the called workflow's ref.² 2. Since reusable workflows cannot access environment variables set in the calling workflow, this uses the yaml-to-envvars workaround with an `env` input already used in the patheogen-repo-ci workflow.³ 3. We use a json-to-envvars workaround to allow for setting secrets as environment variables for the build runtime dynamically. ¹ https://bedfordlab.slack.com/archives/C01LCTT7JNN/p1681328249848399 ² actions/toolkit#1264 ³ https://github.com/nextstrain/.github/blob/cc6f4385a45bd6ed114ab4840416fd90cc46cd1b/.github/workflows/pathogen-repo-ci.yaml#L25-L45
Also having this need in my enterprise |
This is a basic feature need for using reusable workflows. We need a way to keep reusable workflows and the rest of the associated scripting in the same repository so we can version or do branch development. Please, provide a solution to access some context of the reused workflow, ideally access to local files and current branch/tag. |
Piling on. My org really needs this. |
I'm also interested in a solution for this. My org has a central repo with our Reusable Workflows and Shared Action, and it would be essential for us to call the Shared Action using the same revision of the Reusable Workflow. |
+1 for this So I have repository
Repository Here is how it is done in
|
The workaround to this problem that we found was the most clean and easy was to simply do a curl request to get the SHA from the workflow run and use that in ref (https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#get-a-workflow-run). Example (I don't think I missed anything):
And then in
|
I'm facing this problem too. Our reusable workflow needs to checkout its own repository in order to execute a Python script. Allowing access to the called workflow repo's reference would enable versioning its behaviour. Any developments on this? Thanks! |
This was a life-saver for me today. Thank you! |
I don't understand how such obvious requirement is missing... this is one of the first things I immediately needed when extracting workflows and composite actions to the same repo. It seems like there is not enough dogfeeding happening at Github. :/ |
This is definitely a thing that still matters. We're in the process of building out shared workflows that are composed of, well, composite actions in the same repository, and having to manually specify a branch as we modify those composite actions in the workflow file is tedious and error prone. Would be much better to be able to say:
|
In case it helps anyone, we created a composite action that implements @maxbergs's solution https://github.com/canonical/get-workflow-version-action Example usage: # Reusable workflow (e.g. build_charm.yaml)
on:
workflow_call:
jobs:
foo:
runs-on: ubuntu-latest
steps:
- name: Get workflow version
id: workflow-version
uses: canonical/get-workflow-version-action@v1
with:
repository-name: canonical/data-platform-workflows
file-name: build_charm.yaml
# Use the version. For example:
- name: Install Python CLI
run: pipx install git+https://github.com/canonical/data-platform-workflows@'${{ steps.workflow-version.outputs.sha }}'#subdirectory=python/cli |
We have reusable workflows to build docker images and deploy microservices. The docker image workflow is triggered when a version is created and we use ${GITHUB_REF#refs/*/} to extract it. We currently copy & paste the workflows because there is not much benefit to using the reusable workflows. |
@ckmoga I don't understand exactly what you're trying to accomplish, but it doesn't sound like you're affected by this issue
This issue is about accessing the ref that a reusable workflow was called with—i.e. the version of the reusable workflow—not about accessing the ref of the caller repository that triggered the workflow run |
@carlcsaposs-canonical it is possible that I am missing something but I cannot get my release number using |
@ckmoga In that case, I think you're encountering a different issue fwiw, I was able to access GITHUB_REF in a reusable workflow: https://github.com/carlcsaposs-canonical/test-reusable-workflow-githubref/actions/runs/9835427768/job/27149037144 |
OK @carlcsaposs-canonical I got it working with |
It's not obvious to me what the advantage of this solution is over directly passing the called workflow repo and ref as workflow inputs. Especially since for the action you need the repo and file name to get the ref. The repo and file name of the called workflow might change, hence should not be hard-coded in the called workflow file. You already know the repo, ref, and file name in the caller. So you could pass the repo and file name to the called workflow to execute the action, or just pass repo and ref and skip the action step. |
For us, it's helpful because the repository name and workflow name are determined by the reusable workflow, but the ref is determined by the caller. (So it's easy to hard code repository name & workflow name in the reusable workflow) We prefer having one source of truth instead of duplicating it as an input (which could lead to mistakes), and because we use tools like Renovate to update our refs (which are not easily capable of also updating that input) But that's just what works for us—if passing the ref as an input works for you, there's no need to use an action that calls the GitHub API |
Hi guys, following this discussion and looking for a solution I created the following basic action to facilitate what @maxbergs provided us: I hope it will be useful. The only difficult part, IMHO, might be creating the token with the correct set of permissions |
@dariocurr Thank you so much for creating this action! Worked perfectly. Leaving this comment so others know to use it. |
@dariocurr , @carlcsaposs-canonical both your solutions are very nice, however, it may not work on self-hosted runner where either |
hi @nvincent-vossloh! here's what we use on self-hosted runners to install pipx: |
Would be great to see an update from the repository owners here as to whether they will take this up as a new feature... |
I recently encountered this issue and I found a workaround that's relatively simple. I don't know if this will work for everyone but it works in my use case. It gets an oidc JWT to get the My use case: I have a reusable workflow and in this workflow I create a PR comment that links to the workflow docs that is simply a markdown file in the same repo as the reusable workflow. I need the tag to link to the correct workflow doc version. Here's an example reusable workflow that gets the workflow ref with which it was called and only relies on basic utilities (like curl, cut, base64, tr, etc.) so might be more self-hosted runner friendly in most cases (I use a lot of self-hosted runners). Full example in duboisf/get-reusable-workflow-reference#3: name: Example workflow that can get it's own reference
on:
push:
pull_request:
workflow_call:
jobs:
Example:
runs-on: ubuntu-latest
permissions:
contents: read
# Needed to get the called workflow reference
id-token: write
steps:
- name: Get called workflow reference
run: |
JWT=$(curl -s -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL")
PAYLOAD=$(echo "$JWT" | cut -d '.' -f 2 | base64 -d 2>/dev/null || true)
WORKFLOW_FULL_REF=$(
echo "$PAYLOAD" \
| grep -o '"job_workflow_ref":"[^"]*"' \
| cut -d':' -f2 \
| cut -d'@' -f2 \
| tr -d '"'
)
echo "WORKFLOW_FULL_REF=$WORKFLOW_FULL_REF"
case $WORKFLOW_FULL_REF in
refs/heads/*)
WORKFLOW_REF=${WORKFLOW_FULL_REF#refs/heads/}
;;
refs/tags/*)
WORKFLOW_REF=${WORKFLOW_FULL_REF#refs/tags/}
;;
refs/pull/*/merge)
# exception: we got triggered by a pull request, the ref is the base branch
WORKFLOW_REF=$GITHUB_HEAD_REF
;;
esac
echo "::notice ::WORKFLOW_FULL_REF=$WORKFLOW_FULL_REF"
echo "::notice ::WORKFLOW_REF=$WORKFLOW_REF"
echo "WORKFLOW_REF=$WORKFLOW_REF" | tee -a $GITHUB_ENV
- uses: actions/checkout@v4
with:
repository: duboisf/get-reusable-workflow-reference
ref: ${{ env.WORKFLOW_REF }}
- name: Run script from called workflow
run: |
./scripts/example.sh And here's how I call it: name: Call workflow example
on:
pull_request:
jobs:
CallWorkflow:
permissions:
contents: read
id-token: write
uses: duboisf/get-reusable-workflow-reference/.github/workflows/example.yml@v1 Output: |
Thank you for the wonderful cue. Implemented in the dev branch. Currently testing it. |
Describe the enhancement
A reusable workflow should be able to access the reference that it was called for.
Context
A reusable workflow in public repos may be called by appending a reference which can be a SHA, a release tag, or a branch name, as for example:
{owner}/{repo}/.github/workflows/{filename}@{ref}
Githubs documentation states:
The problem
Since the github context is always associated with the caller workflow, the reusable workflow cannot access the reference, for example the tag
v1.0.0
. However, knowing the reference is important when the reusable workflow needs to checkout the repository in order to make use of composite actions.Code snippet
Assume that the caller workflow is being executed from within the
main
branch and calls the refv1.0.0.
of a reusable workflow:Here is the reusable workflow that uses a composite action:
In the above code snippet,
${{ github.ref_name }}
ismain
instead ofv1.0.0
because github context is always associated with the caller workflow. Therefore, the composite actions code is based onmain
and not onv1.0.0
.Proposal
Introduce a new github context variable
caller_ref
which reflects the reference indicated by the caller.The reusable workflow could then use it as follows:
Or even shorter without the need to checkout:
Now, the composite action would be using
v1.0.0.
as indicated by the caller.Related to this FR:
The text was updated successfully, but these errors were encountered: