Usage
Before going over the specifics of how a composite action is constructed, let's first take a look at how a composite action is used inside a workflow.
Inside action_on_pull_request.yml
:
jobs:
build-run-lorenz_96:
[...]
steps:
- name: Checkout repo into runner instance
uses: actions/checkout@v3
Invocation of a composite action is done by the uses:
key. In the above example, the publically available checkout
composite action is being invoked. When using a hosted composite action, the syntax is <username>/<composite_name>[@v<release-version>]
. For the above case, we are using version 3 of the checkout
composite action.
If the composite action being used has input parameters available, then invoking that action would look like this:
jobs:
build-run-lorenz_96:
[...]
steps:
- name: Checkout repo into runner instance
uses: actions/checkout@v3 # invoking remotely hosted composite action
with: # for specifiying arguments passed to composite action
path: ... # specify the path for checkout action to be performed in
token: ...
where values assigned to the keys path
& token
would be passed to the composite action to be used.
If the composite action exists locally within your repository (inside .github/actions/[composite_action_dir]
), invoking the composite would look like the following:
jobs:
build-run-lorenz_96:
[...]
steps:
[...]
- name: Build and run lorenz_96
uses: ./.github/actions/build_run_model
with:
model: lorenz_96
run-program: ./filter
use-mpi: true
mpi-n-tasks: 2
For local composite actions, the uses
key requires a full path from repository directory to the directory of your composite action containing the action.yml
file.
As the example indicates, the composite action build_run_model
is being invoked with four arguments: model
, run-program
, use-mpi
, and mpi-n-tasks
. A composite action may contain arguments that are not required to be specified upon invocation.