[BUG] Jobs output should return a list for a matrix job

Our project would also have a use for output arrays from matrix jobs.

1 Like

Just to give a possible workaround, we switched to writing our actions in m4, and setting up a Makefile that generates the required workflows, in this way we can handle this better - without rewriting things a ton of times manually. And then we commit the modified m4 and the code generated yaml files for the workflows.

I could solve this by using dynamic names (thanks to @Simran-B for the inspiration)

    runs-on: ubuntu-latest
        app: [a, b, c]

      deploy-url-a: ${{ steps.deploy-url.outputs.a }}
      deploy-url-b: ${{ steps.deploy-url.outputs.b }}
      deploy-url-c: ${{ steps.deploy-url.outputs.c }}

      - id: deploy
        uses: FirebaseExtended/action-hosting-deploy@v0

      - id: deploy-url
        run: echo '::set-output name=${{ matrix.app }}::${{ steps.deploy.outputs.details_url }}'

    runs-on: ubuntu-latest
      - build

        container: [A, B, C, D, E, F]

      - env:
          NEEDS: ${{ toJSON(needs) }}
        run: echo "$NEEDS"

And it outputs json like:

  "build": {
    "result": "success",
    "outputs": {
      "deploy-url-a": "https://a-n7rk66qr.web.app",
      "deploy-url-b": "https://b-h2d6w8we.web.app",
      "deploy-url-c": "https://c-75sezwhs.web.app"

Dynamic output names can be useful for a variety of reasons. For instance, say you dynamically generate a matrix in some setup job, then the matrix runs. While running, perhaps you gather stats on the run, i.e. “did the job fail?”, “if so, what was the cause?”, “how many jobs in the matrix failed?”, etc. Now in a follow-up job, let’s call it report, you may want to aggregate that collected stats and send it to Slack, log it some where, or capture it as metric data in some telemetry service. Given the current way GitHub Actions runs matrix jobs, the hypothetical report job is not capable of being used to generate meaningful data from the matrix stats.

1 Like

Hi !
did someone at github have a look at this issue ? This is really limitative to what we can do with matrix, making it impossible to define build matrices dynamically.

1 Like

Hi @ericoporto this sounds interesting. Do you have an example/documentation of/on this?

+1, This could be used when building docker images with a strategy matrix (for parallelisation) and using the same docker image names across different environments. It has many use cases.

Exactly the scenario I was trying to implement when I discovered this design defect, @markusSimonsen.

I agree, this seems like a bug since it’s expected that each matrix job would have it’s own unique output.