Composite actions cannot interoperate with javascript actions and docker actions that use non-declarative outputs. From the documentation of javascript and docker actions:
If you don't declare an output in your action metadata file, you can still set outputs and use them in a workflow. For more information on setting outputs in an action, see "Workflow commands for GitHub Actions."
However, this feature is not available to composite actions. That means if a composite action includes an action that exports non-declared outputs, the composite action cannot export those outputs.
The Composite Actions ADR makes a compelling argument for the choice to not expose all outputs from all steps; namely
The reason why we are [not exporting step outputs] is that we don't want to require the workflow author to know the internal workings of the composite action.
This makes sense and we can stay true to this principle while also maintaining feature parity with javascript/docker actions.
Proposal
A natural way to implement this capability would be to allow a developer to choose a step, declared in a parameter called stepOutputs, that exposes all outputs of a given step. As an example, what previously would be written as this:
This gives us two properties:
1) We don't expose the internals of the composite action (random-id is not exported).
2) We can expose a dynamic set of outputs
Furthermore, it is a literal extension of the guiding principles of composite actions:
A composite action is treated as one individual job step (this is known as encapsulation).
Problem
Composite actions cannot interoperate with javascript actions and docker actions that use non-declarative outputs. From the documentation of javascript and docker actions:
However, this feature is not available to composite actions. That means if a composite action includes an action that exports non-declared outputs, the composite action cannot export those outputs.
The Composite Actions ADR makes a compelling argument for the choice to not expose all outputs from all steps; namely
This makes sense and we can stay true to this principle while also maintaining feature parity with javascript/docker actions.
Proposal
A natural way to implement this capability would be to allow a developer to choose a step, declared in a parameter called
stepOutputs
, that exposes all outputs of a given step. As an example, what previously would be written as this:, could now be written as this:
This gives us two properties: 1) We don't expose the internals of the composite action (random-id is not exported). 2) We can expose a dynamic set of outputs
Furthermore, it is a literal extension of the guiding principles of composite actions: