[Feature Request] Allow (restricted) variable expansion in 'uses:' parameter

[chrfranke]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

If a larger set of similar actions is available, see for example vmactions, it would be useful to pass the action to use via a variable, for example:

      - uses: ${{ matrix.action }} # or ${{ inputs.action }}

The above fails with "Unrecognized named-value: 'matrix'". This restriction is possibly intentional for security reasons.

---

The following enhancement would keep the ability to do security checks: allow variables but check the expanded value against a newly added list of permitted actions. This list must not allow variable expansion. For example:

      - uses: vmactions/${{ matrix.os }}-vm@v1
        permitted-actions:
          - vmactions/freebsd-vm@v1
          - vmactions/netbsd-vm@v1
          - vmactions/openbsd-vm@v1
          - vmactions/omnios-vm@v1

If permitted-actions is missing, fall back to current behavior.

[SuprimOjha]

I think this would be a useful enhancement, particularly for reusable workflows and matrix-based CI configurations.

Currently, requiring a static value in the uses field makes it difficult to select between multiple similar actions dynamically.

The proposed permitted-actions approach seems reasonable because it could preserve security restrictions while allowing controlled dynamic selection.

A few considerations:

• Validate the fully expanded action reference against the allowlist before execution.
• Reject references that are not explicitly permitted.
• Keep the existing behavior when permitted-actions is not specified, as suggested.
• Ensure that variable expansion cannot occur inside the allowlist itself.

This would improve workflow flexibility without unnecessarily weakening the existing security model.

I'd support exploring this enhancement.