Support context/matrix variables and Composite Actions inputs in steps of type 'uses'
See original GitHub issueDescribe the enhancement
It is currently not possible to use variables from the matrix (in a regular workflow), or inputs (in a Composite Action) to define the Actions to be used in steps of type uses
. The workflow won’t start because of a parser/syntax issue: the
uses’ attribute must be a path, a Docker image, or owner/repo@ref`.
Code Snippet
See https://github.com/hdl/containers/blob/GHA-MWEs/.github/workflows/MWE-1479.yml and https://github.com/hdl/containers/blob/GHA-MWEs/utils/mwe-input-var-in-uses/action.yml:
matrix-var-in-uses-name:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
action:
- actions/checkout
steps:
- uses: ${{ matrix.action }}@v2
matrix-var-in-uses-version:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
version:
- v1
- v2
steps:
- uses: actions/checkout@${{ matrix.version }}
matrix-var-in-uses-docker:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
img:
- debian:bullseye-slim
- debian:buster-slim
steps:
- uses: docker://${{ matrix.img }}
matrix-var-in-uses-docker-tag:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
img:
- bullseye-slim
- buster-slim
steps:
- uses: docker://debian:${{ matrix.img }}
matrix-var-in-uses-action:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: ./utils/mwe-input-var-in-uses
name: '[HDLC] MWE Input variable in uses'
description: 'Minimal Working Example to reproduce a bug when using an input in a uses step of a Composite Action.'
inputs:
version:
description: 'Version of actions/checkout to use.'
default: 'v2'
required: false
image:
description: 'Name of the container image.'
default: 'asciidoctor/docker-asciidoctor'
required: true
runs:
using: 'composite'
steps:
- uses: actions/checkout@${{ inputs.version }}
- uses: docker://${{ inputs.image }}
with:
args: doc/make.sh
Additional information
The inability to use Composite Action inputs in steps of type uses: docker://
is particularly uncomfortable, because it forces using the docker CLI explicitly. Therefore, environment variables and binds need to be manually and explicitly described. See, for instance, the following workaround to the Composite Action above: https://github.com/VUnit/vunit_action/blob/master/action.yml.
Being able to use the context would be a suitable solution to using a local action without explicitly checking out the repository, as discussed in https://github.com/actions/runner/issues/646#issuecomment-964020664. Precisely, uses: ${{ github.repository }}/.github/myaction@${{ github.ref_name }}
would be equivalent to:
- uses: actions/checkout@v2
- uses: ./.github/myaction
/cc @thboop, per https://github.com/actions/runner/issues/646#issuecomment-901336347 /cc @aramfe
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:6 (2 by maintainers)
Top GitHub Comments
This would be an amazing feature to have (as well as cascading working-directory support).
I understand the reasoning for no variables, but it’d be great if you can allow
github.action_path
, or maybe a parameter calledrelative-to-caller: true
, which causesuses:
to look up relative to the currentgithub.action_path
.For relative actions in an actions monorepo, I’m currently using a hack that exposes the action’s parent directory.
https://github.com/FundingOptions/actions/commit/6f3e0e771cbdac6d64007e4bbeaf58c60a2475cb
This amazingly works, but could very easily break if sparse checkouts are implemented for actions, so treat this as “very undocumented behaviour.”
@ChristopherHX, I love that workaround, and I wish I’d thought of it when I did my pre-processor (clean-actions) ages ago, it would have simplified so much 🤣
You could try my action as a workaround, which writes and calls an interpolated
action.yml
file, as long as you don’t want to call reusable workflows. Beware multline inputs are dangerous andpre
run steps are skipped. https://github.com/ChristopherHX/conditional