You can use the if conditional to prevent a step from running unless a condition is met.
You can use any supported context and expression to create a conditional.
For more information on which contexts are supported in this key, see Contexts reference.
When you use expressions in an if conditional, you can, optionally, omit the ${{ }}
expression syntax because GitHub Actions automatically evaluates the if conditional as an
expression.
However, this exception does not apply everywhere.
For more information, see Evaluate expressions in workflows and actions.
Sets variables for steps to use in the runner environment.
You can also set variables for the entire workflow or a job.
For more information, see module.env and Job.env.
When more than one environment variable is defined with the same name, GitHub uses the most
specific variable.
For example, an environment variable defined in a step will override job and workflow
environment variables with the same name, while the step executes.
An environment variable defined for a job will override a workflow variable with the same name,
while the job executes.
Public actions may specify expected variables in the README file.
If you are setting a secret or sensitive value, such as a password or token, you must set
secrets using the secrets context.
Using the working-directory keyword, you can specify the working directory of where to run the
command.
Alternatively, you can specify a default working directory for all run steps in a job, or for
all run steps in the entire workflow.
For more information, see defaults.run.working-directory and
jobs.<job_id>.defaults.run.working-directory.
You can also use a run step to run a script.
For more information, see
Adding scripts to your workflow.
You can override the default shell settings in the runner's operating system and the job's
default using the shell keyword.
You can use built-in shell keywords, or you can define a custom set of shell options.
The shell command that is run internally executes a temporary file that contains the commands
specified in the run keyword.
Runs a step asynchronously so the job continues to the next step without waiting for it to finish.
Use background: true for long-running processes, such as databases, servers, or monitoring tasks, that need to
run alongside other steps.
You synchronize with background steps later using wait or wait-all or stop them with cancel.
You can use background on steps that use run or uses.
To reference a background step from wait or cancel, give it an id.
A maximum of 10 background steps can run concurrently in a single job; additional background steps are queued until
a slot is free.
Outputs and environment changes from a background step are only available after you run a wait or wait-all step
that includes it. If a background step fails, the job fails at the next wait or wait-all that includes it
(unless continue-on-error is set on that step).
An implicit wait-all runs before any post-job cleanup.
Use background when you need fine-grained control: starting a long-running process (like a server or database)
that stays up while later steps run, referencing a specific step with wait or cancel, or interleaving
background work with other steps.
If you instead have a self-contained group of steps that should all finish before the job continues,
parallel is a more convenient shorthand.
Returns the relative, descendent directory path between this module and other.
Throws if no such path exists.
For example, if module mod1 has path /dir1/mod1.pkl, and module mod2 has path
/dir1/dir2/dir3/mod2.pkl, then mod1.relativePathTo(mod2) will return
List("dir2", "dir3").
A common use case is to compute the directory path between a template located at the root of a
hierarchy (say rootModule.pkl) and the currently evaluated module (accessible via the
module keyword):
The output of this module.