Ref Head in Reusable Workflows

Code to Cloud GitHub Actions
#11

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 }}
1 Like
Self reference a shared workflow_call for testing
#12

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

2 Likes
#13

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!

5 Likes
#14

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.

3 Likes
#15

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

10 Likes
#16

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?

1 Like
#17

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
7 Likes
#18

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.

2 Likes
#19

You can reference a composite action with a local path today (not yet supported with reusable)

Is it tracked somewhere ? I would like to subscribe for notifications ? We are dearly missing this feature. Thx.

11 Likes
#20

I think this would be a really useful feature. It would greatly reduce the copy-pasta in my current github workflows.

8 Likes
#21

Without this feature, there doesn’t seem to be a way to have workflows depend on other workflows such that checks passing on pull requests guarantees checks passing on main branch after pull request merge.

It is not safe to develop on reusable workflows as caller workflows (depending on main branch) will not be validated against the dev branch reusable workflow.

Since this seems to be a major limitation it should probably be noted (maybe top of the list) in the reusable workflow documentation: Reusing workflows - GitHub Docs

15 Likes
#22

I’m also waiting for this feature.

1 Like
#23

It works? I was unsuccessful in trying to do this.

1 Like
#24

Also, waiting for this feature, tnx

1 Like
#25

Hey, community!
We also waiting for this functionality.
Please, let me know regarding any updates.

1 Like
#26

Hi, also waiting for this feature!

1 Like
#27

Any more info on the local reference scenario?

2 Likes
#29

waiting for this feature! so useless without it

2 Likes
#30

Hey everyone - I’m the product manager for reusable workflows. We’re currently working on the local reference scenario. It should be available in the next couple of weeks.

Here’s how it will work:

If a reusable workflow is located in the same repository as the caller, you can reference it with a local path: {path}/{filename}. We’ll automatically use the current ref.

Here’s an example that shows the two ways you’ll have to reference a reusable workflow:

jobs:
  call-workflow-1:
    uses: .github/workflows/workflow-1.yml
  call-workflow-2:
    uses: octo-org/another-repo/.github/workflows/workflow-2.yml@v1
38 Likes
Reuse workflow: dynamic branch reference (github.ref_name)
#31

Thank you! That will make this feature actually useable for us.

1 Like