Support secret inheritence `secrets: inherit` for actions

[alonbl]

Hi,

Reusable workflow supports secrets: inherit, this allows the author of the workflow to access secrets set by the configuration without the calling workflow aware of the internals of the reusable workflow it calls. It makes it easy to maintain a changing environment in which callable workflows evolve and use more secrets.

I am aware that the initial design of actions assumed secrets are provided as environment and/or input parameters. However, both methods require the caller to be aware of the implementation of the action. For composite actions which wraps a reusable code into an action it makes it difficult to maintain as the secrets must be provided explicitly via input or via environment.

Please consider to support the secrets collection in actions as well, this will explicitly mark the secret data to be masked/encrypted, and will allow inheritance similar to reusable workflows and achieve consistency.

In short, the secrets handling in actions should be similar to the secrets handling of the workflows (input object, input mask, inherit).

Workaround

workflow

      - uses: ./.github/actions/xxx
        with:
          secrets: ${{ toJSON(secrets) }}

action.yaml

inputs: 
  secrets:
    description: 'Secrets toJSON'
<snip>
runs: 
  using: "composite"
  steps:
    - uses: xxx
      with:
        xxx: ${{ fromJSON(inputs.secrets).SECRET1 }}

Expected (Inheritance)

workflow

      - uses: ./.github/actions/xxx
        secrets: inherit

action.yaml

<snip>
runs: 
  using: "composite"
  steps:
    - uses: xxx
      with:
        xxx: ${{ secrets.SECRET1 }}

Expected (Explicit)

workflow

      - uses: ./.github/actions/xxx
        secrets:
          SECRET1: xxx

action.yaml

<snip>
secrets: 
  SECRET1:
    description: 'Secret1'
<snip>
runs: 
  using: "composite"
  steps:
    - uses: xxx
      with:
        xxx: ${{ secrets.SECRET1 }}

[nexocentric]

I am also dealing with issues related to to this. It complicates the workflow quite a bit.

[undergroundwires]

Looking forward to this. It increases complexity without adding any additional security for local actions.

[cortexcompiler]

I agree that this would be very helpful. For example, we have encapsulated some logic in a Composite Action and now want to enhance it with a non-breaking change that requires access to a secret key that we can add to the org secrets. This is not possible without changing all places that call this Action. This breaks the encapsulation and requires impacting all callers of the custom action.

[andre177]

I agree it would be very helpful! Looking forward this feature.

[ehrnst]

is there any progress on this. I just discovered today that my project wont work because secret inheritance is not available for composite actions.

[Keshapally]

Is there any progress on this ?

[fopina]

one more vote 👍 it would just have to stick to same inheritance restriction of the reusable workflow: only works within same repository or organization

I've been tempted to migrate my composite actions to reusable workflows just because of this but the downside of going through agent re-scheduling is still significant