Optionally unwrap an output

[jenseng]

By default, dynamic-uses returns a single JSON output named outputs containing all the target action's outputs. Individual outputs can then be accessed via something like fromJSON(steps.cool-action.outputs.outputs).theThingIWant. This provides the most flexibility.

But sometimes you just want a single output, and if you have to do this in multiple expressions this can get a bit tedious/verbose. It would be nice if you could optionally specify a particular output to target, then the outputs output would contain its actual value.

e.g. instead of this

- id: cool-action
  uses: jenseng/dynamic-uses@v1
  with:
    uses: my/cool/action@${{ inputs.version }}
- env:
    theThing: ${{ fromJSON(steps.cool-action.outputs.outputs).theThingIWant }}
  run: echo "$theThing"

you could do something like this:

- id: cool-action
  uses: jenseng/dynamic-uses@v1
  with:
    uses: my/cool/action@${{ inputs.version }}
    output: theThingIWant
- env:
    theThing: ${{ steps.cool-action.outputs.outputs }}
  run: echo "$theThing"

[ReenigneArcher]

How about grabbing the target's action.yml and parsing it with a yaml parser. Then injecting the original action's outputs into the temp action?

You should be able to download the action.yml file using https://docs.github.com/en/rest/repos/contents?apiVersion=2022-11-28#get-repository-content

[jenseng]

@ReenigneArcher that's an interesting idea, although it would make dynamic-uses a lot more complex 😅

I do see a few potential gotchas, but perhaps we could figure out some workarounds...

• If the target action is a JavaScript or Docker action, the outputs don't necessarily have to be specified in the action.yml (though ideally they should be). I.e. sometimes they only set the output via the $GITHUB_OUTPUT file, so it could be hard to determine what they are.
• The API approach is fine for public actions or ones from the same repo. But if the actions are from a private repo, a different API token would be needed. Alternatively we could rely on the runner to "pre-load" the referenced action via another dynamically generated action, and then find the action file via directory traversal (e.g. ../../_actions/myorg/myrepo/main/action.yml), though that might be a little janky
• Ultimately even if we do know the outputs, we can't change the top-level output(s) for dynamic-uses itself, since it's a composite action and everything needs to be statically defined. So I think we're probably stuck with a single output named outputs 😞

[jsoref]

I'd probably just offer an action that generates an action that can parse things out.

- uses: jenseng/dynamic-uses@v2
  with:
    unbox-output-action-path: parse-output
    uses: my/cool/action@${{ inputs.version }}
- uses: ./parse-output
  id: outputs
- env:
    color: ${{ steps.outputs.color }}
    fruit: ${{ steps.outputs.fruit }}
    tree: ${{ steps.outputs.tree }}
  run: |
    echo "color=$color; fruit=$fruit; tree=$tree"

It's certainly possible for you to create a second action that has all of the outputs instead of just putting them in the github outputs output.
Obviously, you'd need to be careful.

As an initial implementation, you could require people to give the output from the dynamic-uses step to the parse-output step.

I haven't done such a thing yet, but, I'm certainly not above doing something like that.

I do have wrappers for things: https://github.com/check-spelling/check-spelling/tree/prerelease/actions and have toyed with automatically generating the wrappers...

[jenseng]

It's certainly possible for you to create a second action that has all of the outputs instead of just putting them in the github outputs output.

This is possible, though it cannot be done generically, i.e. you'd have to create such an action for each underlying action you want to call dynamically. It can't be made generic, since whatever top-level composite action that a user calls in their workflow (dynamic-uses or whatever) must define its outputs statically.

edit: Ok I see what you're saying, let me noodle on that 👍

[jenseng]

Building on that idea, perhaps a more self-contained approach would be to (optionally) have the action set env vars for each output. e.g.

- uses: jenseng/dynamic-uses@v2
  with:
    uses: my/cool/action@${{ inputs.version }}
    output-to-env: true
- run: |
    echo "color=$color; fruit=$fruit; tree=$tree"

[ReenigneArcher]

Building on that idea, perhaps a more self-contained approach would be to (optionally) have the action set env vars for each output. e.g.

• uses: jenseng/dynamic-uses@v2
  with:
  uses: my/cool/action@${{ inputs.version }}
  output-to-env: true
• run: |
  echo "color=$color; fruit=$fruit; tree=$tree"

That sounds reasonable, but the variable name should be more unique, maybe sort of mimic how you access the step outputs? This would make it less likely to clash with existing variables.

Something like STEPS_<STEP_ID>_OUTPUTS_COLOR instead of color? Perhaps "STEP_ID" needs to be another input as I don't see a way to access the actual step id until after the step has completed.

[jsoref]

  with:
    output-to-env-prefix: SOMETHING

Note that you're going to have to handle the case where someone uses - in an output (the standard approach for this is to map - to _) or where they have two outputs that differ only by case. I'd suggest warning and not setting any colliding outputs.

[jenseng]

I like the prefix idea, that gives people the control they need

Also +1 on warning for colliding names (but hopefully that would be rare)... technically an output can have just about any character, so we should probably convert any non-ASCII to a _. Fortunately we don't need to worry about case, since GHA downcases all output names, so an action with outputs that differ only by case will already be problematic. See this test job: https://github.com/jenseng/dynamic-uses/actions/runs/20342635190/job/58446028310

[jsoref]

I'm so very amused that it preserves emoji but downcases ascii.

I mention the - and case stuff since check-spelling has a mix of kebab-case_inputs and environment_case_inputs and I'm looking towards migrating people from one to the other, and it's a bit of a mess.