I have already posted this question on GitHub Actions Community but any involvement seems to have petered out there.
I’m attempting to extract an output from a child workflow in a subsequent parent job and having zero luck getting anything to properly formulate. Latest hard-coded attempt:
parent workflow:
jobs:
jobA:
uses: [...]/.github/workflows/deploy-bicep.yaml@main
jobB:
runs-on: ubuntu-latest
needs: jobA
defaults:
run:
shell: pwsh
steps:
- run: |
Write-Host "ACR Name -> " ${{ needs.jobA.outputs.acrName }}
child workflow (called from jobA):
jobs:
deploy-bicep:
runs-on: ${{ inputs.vmImage }}
defaults:
run:
shell: pwsh
steps:
- name: Hard-Coded Outputs
id: bicep-outputs
run: |
$outputs = "acrName=Blah123"
echo "Hard-coded outputs: $outputs"
echo $outputs | Out-File -Append $env:GITHUB_OUTPUT
outputs:
acrName: ${{ steps.bicep-outputs.outputs.acrName }}
As many times before, the result from the second iteration of jobB is an empty string.
Anyone else have any suggestions? Trying to migrate from Azure YAML Pipelines and despite Actions being a fork of the former there are definitely some functionality gaps.
Thanks!
2
Answers
Answered on the GitHub Actions board and placing here for others (easier) reference:
With the vast limitations of having to hard-code outputs from a child workflow to its parent, and then that parent workflow having to have hard-coded output references I ended up creating individual files in an
outputs/
folder and publishing the outputs folder to the artifact directory, such as the following:In which the second job in the calling workflow can easily download such artifact and read them whenever necessary. Much more decoupled and manageable than the prescribed method of using "outputs" ->
Passing variables between jobs on the same plane appears just fine, but still, creating variables dynamically without specific references for consumption by later steps and jobs, no matter the plane of the workflow, seems to be a feature-miss from the fork of Azure Pipelines.
Or perhaps intentional? Either way thankfully the above works as expected.
In the context of reusable workflows, the official terms are "caller" and "called" workflows, not "parent" and "child".
For your specific problem, the
on.workflow_call.outputs
section is missing to propagate output parameters from the "called" workflow.on.workflow_call.outputs
Also, see using outputs from a reusable workflow for more details.
Here’s a simple example emulating your scenario:
.github/workflows/reusable_workflow_set_output.yml
.github/workflows/reusable_workflow_set_output_caller.yml
Output: