com.github.actions.AbstractTypedStep1.9.0
- Module URI:
- package://pkg.pkl-lang.org/pkl-pantry/com.github.actions@1.9.0#/AbstractTypedStep.pklcontent_copy
- Source code:
- AbstractTypedStep.pkl
- Known subtypes in package:
- Known usages in package:
- All versions:
To define a type-safe action step, define a new class/module that extends this module.
Example:
module Echo
extends "@com.github.actions/AbstractTypedStep"
fixed action: "actions/checkout"
fixed version: "v4"
with: CheckoutInputs
class CheckoutInputs {
sha: String
}
Properties(show inherited)
-
expand_morelinkhidden
The output of this module.
Defaults to all module properties rendered as either Pcf or the format specified on the command line.
-
-
expand_morelink
A unique identifier for the step.
You can use the
idto reference the step in contexts. For more information, see Contexts reference. -
expand_morelink
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.
-
link
Prevents a job from failing when a step fails. Set to true to allow a job to pass when this step fails.
-
expand_morelink
The maximum number of minutes to run the step before killing the process.
Fractional values are not supported. timeout-minutes must be a positive integer.
-
expand_morelink
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.envandJob.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.
For more information, see Contexts reference.
-
expand_morelink
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-directoryandjobs.<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. -
expand_morelink
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.
-
expand_morelink
Runs a step asynchronously so the job continues to the next step without waiting for it to finish.
Use
background: truefor long-running processes, such as databases, servers, or monitoring tasks, that need to run alongside other steps. You synchronize with background steps later usingwaitorwait-allor 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
waitorwait-allstep that includes it. If a background step fails, the job fails at the nextwaitorwait-allthat includes it (unlesscontinue-on-erroris set on that step). An implicitwait-allruns before any post-job cleanup.Use
backgroundwhen 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 withwaitorcancel, 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,parallelis a more convenient shorthand. -
-
-
expand_morelinkabstract hidden
The version of the action to run.
For typed steps, the type of
withis associated with the major version of the action, so subclasses should specify a fixed version It is strongly recommend to include the version of the action you are using by specifying a Git ref, SHA, or Docker tag.Use
shato specify a specific SHA to use in place of the version. If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.- Using the commit SHA of a released action version is the safest for stability and security.
- If the action publishes major version tags, you should expect to receive critical fixes and security patches while still retaining compatibility. Note that this behavior is at the discretion of the action's author.
- Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.
-
-
Methods(show inherited)
-
-
-
-
-
-
-
-
-
expand_morelinkfunction
Returns the relative, descendent directory path between this module and
other.Throws if no such path exists.
For example, if module
mod1has path/dir1/mod1.pkl, and modulemod2has path/dir1/dir2/dir3/mod2.pkl, thenmod1.relativePathTo(mod2)will returnList("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 themodulekeyword):import "rootModule.pkl" // self-import path = rootModule.relativePathTo(module)
Abstract class of steps that call actions with typesafe inputs.