Ref Head in Reusable Workflows

Hi! Is it possible to somehow reference the current ref_head or branch head in Reusing workflows - GitHub Docs?

Thanks

4 Likes

I’ve been trying to do this also. I tried using the github.sha context value to reference the same commit, but getting this error:

handling usage of workflow "Alvearie/hri-mgmt-api/.github/workflows/docker-build.yml@${{ github.sha }}": can't obtain workflow file: reference to workflow should be either a valid branch, tag, or commit

Does anyone know how to do this?

Have you tried using GITHUB_HEAD_REF or GITHUB_REF env vars?

I’m also getting the same issue. Any help with this one would be much appreciated!

@laughedelic This is about referencing a workflow from lets say “main” instead of a specific commit.
eg.

jobs:
  call-workflow-1:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@master

eg. I want to reference the workflow that im also adding in this PR.

@LordBigSky whats next for what? My reply was to laughedelic

I think the key part to this question is how to pass the head sha of a pull request to the uses: option.

The documentation indicates that a sha can be passed:

jobs:
  call-workflow-1:
    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89

But if a user tries to pass ${{ github.sha }} it doesn’t seem to get expanded and as a result ends up with the following error:

handling usage of workflow "octo-org/this-repo/.github/workflows/workflow-1.yml@${{ github.sha }}": can't obtain workflow file: reference to workflow should be either a valid branch, tag, or commit

Hi everyone. I’m the product manager for reusable workflows. Today, you have to provide the full, static path and ref for the reusable workflow. We don’t evaluate any expressions.

We do plan to support this at some point, and I’ll update this thread when we do.

3 Likes

Even if given a job output as a value ?

jobs:
  constructor:
    outputs:
      current_branch_reusable_workflow_1: ${{ steps.constructor_step.outputs.current_branch_reusable_workflow_1 }}
    steps:
      - run: |
           $currentRepo = "${{ github.repository }}"
           $currentBranch = `echo ${GITHUB_REF##*/}`
           $workflow = "$currentRepo/.github/workflows/rw1.yml@$currentBranch"

           echo "::set-output name=current_branch_reusable_workflow_1::$(echo $workflow)"

  reusable_workflow_1:
    needs: constructor
    uses: ${{ needs.constructor.outputs.current_reusable_workflow_1 }}

That’s correct. I wouldn’t expect that to work.

Hey @jenschelkopf it seem you are everywhere :slight_smile: thanks a lot for your help and your update here. My 2 cents on this if it helps cut scope, I think the main use-case I had in mind was that of referencing the current branch, as that way I can include in a PR a workflow that uses reusable workflows created or updated on the PR itself.

Thanks!

1 Like

Is something along those lines in the works ?

I am asking because this new feature is really great and we adopted it immediately, but in case work on the workflows is done on a feature branch, now you’d have to change the refs during the development and change them back at PR, which is very error prone and creates unnecessary overhead.

Yeah, we’re taking a look at it.

The local reference scenario that @pecigonzalo mentioned is what we’re focused on initially. I think that covers 90% of folks who are requesting this. It will likely look a lot like referencing a local action, but without the need to do a checkout first: Workflow syntax for GitHub Actions - GitHub Docs

2 Likes

I totally forgot about local actions! That means we could use Creating a composite action - GitHub Docs to do this right? Like have a local action.yml taking a bunch of inputs, and that should even work with the secrets I asked about in Reusable Workflows, Secrets and Environments - Code to Cloud / GitHub Actions - GitHub Support Community.

Is my assumption here correct? Aside from being more straightforward, is there a limitation to local composite action that im not considering?

I’m not sure I understand your entire scenario, but here’s some notes about reusable vs composite actions:

  • You can reference a composite action with a local path today (not yet supported with reusable)
  • Composite actions must be defined in an action.yml, so if you want multiple in a single repository, you’ll need to organize them into folders. You can name reusable workflows whatever you want
  • Reusable workflows show up in the Actions tab, and composite actions do not
  • You can directly execute a reusable workflow in addition to making it callable. Composite actions are only executed when they are called
  • Both composite actions and reusable workflows execute in the caller’s context, so both have access to environments and secrets (as long as they are provided in the caller’s workflow file)
  • Composite actions are one or more steps, while reusable workflows are one or more jobs. That means reusable workflows can execute things on different runners, have more complicated logic like fan-in and fan-on patterns, and give you a “clean” runner
2 Likes

I think the last one is a key difference, thanks.

The exact scenario here is reusing a job or steps (like a deployment, migration, etc) from multiple action definitions.
eg. An automated deployment on commit and a user manually triggering a deployment.

While we can set multiple triggers for a workflow, sometimes that makes it more complicated as I have to cater to calls with input and with just commit/push/etc context.

1 Like