Packages > pkg.pkl-lang.org/pkl-pantry/com.github.actions

com.github.actions.Step1.9.0

Properties
Methods
Type Aliases

module com.github.actions.Step extends com.github.actions.AbstractStep

Module URI:: package://pkg.pkl-lang.org/pkl-pantry/com.github.actions@1.9.0#/Step.pkl
Source code:: Step.pkl
Known subtypes in package:
Known usages in package:
All versions:

Properties(show inherited)

link

hidden

output: ModuleOutput (pkl.base)Source

The output of this module.

Defaults to all module properties rendered as either Pcf or the format specified on the command line.
link

name: String? (com.github.actions.AbstractStep)

A name for your step to display on GitHub.
link

id: String? (com.github.actions.AbstractStep)

A unique identifier for the step.

You can use the id to reference the step in contexts. For more information, see Contexts reference.
link

`if`: String? (com.github.actions.AbstractStep)

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

`continue-on-error`: Boolean? (com.github.actions.AbstractStep)

Prevents a job from failing when a step fails. Set to true to allow a job to pass when this step fails.
link

`timeout-minutes`: Int(isPositive)? (com.github.actions.AbstractStep)

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.
link

env: EnvironmentVariables? (com.github.actions.AbstractStep)

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.

For more information, see Contexts reference.
link

`working-directory`: String? (com.github.actions.AbstractStep)

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.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsworking-directory
link

shell: Shell? (com.github.actions.AbstractStep)

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.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell
link

background: Boolean? (com.github.actions.AbstractStep)

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.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsbackground
link
uses: String?Source

Selects an action to run as part of a step in your job.
An action is a reusable unit of code. You can use an action defined in the same repository as the workflow, a public repository, or in a published Docker container image. We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag. 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. Some actions require inputs that you must set using the with keyword. Review the action's README file to determine the inputs required. Actions are either JavaScript files or Docker containers. If the action you're using is a Docker container you must run the job in a Linux environment. For more details, see runs-on.
link

run: String(length < 21_000)?Source

Runs command-line programs that do not exceed 21,000 characters using the operating system's shell.

If you do not provide a name, the step name will default to the text specified in the run command. Commands run using non-login shells by default. You can choose a different shell and customize the shell used to run commands. For more information, see shell. Each run keyword represents a new process and shell in the runner environment.
link

wait: (String|Listing<String>)?Source

Pauses the job until one or more background steps complete. A wait step performs no work itself, it only blocks until the referenced background steps finish. Provide a single step id as a string, or multiple step ids as an array.

After a wait step completes, the outputs of the referenced background steps become available to subsequent steps. If a referenced background step failed, the wait step fails too.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepswait
link

`wait-all`: Boolean?Source

Pauses the job until all active background steps complete.

This is useful when several background steps are running and you want them all to finish before continuing. Like wait, the wait-all step fails if any of the background steps it waits on failed, unless you set continue-on-error to true.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepswait-all
link

cancel: String?Source

Gracefully terminates a running background step.

The runner sends the step's process a termination signal (SIGTERM) so it can clean up, and forcibly stops it (SIGKILL) if it does not exit within a short grace period.

The cancel keyword targets a single background step by its id.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscancel
link

parallel: Listing<(Step|AbstractTypedStep)>?Source

Runs a group of steps concurrently, then waits for all of them to finish before continuing. The parallel keyword is shorthand: every step in the group runs as a background step, with an implicit wait at the end of the group. Use it when you have an independent group of steps that can run at the same time and you don't need to reference them individually.

Use parallel when you have a self-contained group of steps that should all finish before the job moves on, such as building several components at once. Use background when you need finer 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. In short, parallel is more limited but more convenient for the "run this group at once" case, while background is the general-purpose primitive.

Each step in the group is subject to the same 10-step concurrency limit as other background steps.

Docs: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscancel
link

with: Mapping<String, (String|Number|Boolean)>?(hasExclusivelySetProperties)Source

Inputs to the action.

Methods(show inherited)

link

function

getClass(): Class (pkl.base)Source

Returns the class of this.
link

function

toString(): String (pkl.base)Source

Returns a string representation of this.

This method is used to convert the values of string interpolation expressions to strings.
link

function

ifNonNull<Result>(transform: (NonNull) -> Result): Result? (pkl.base)Source

Returns this |> transform if this is non-null, and null otherwise.

This method is the complement of the ?? operator and the equivalent of an Option type's map and flatMap methods.
link

function

hasProperty(name: String): Boolean (pkl.base)Source

Tells if this object has a property with the given name.
link

function

getProperty(name: String): unknown (pkl.base)Source

Returns the value of the property with the given name.

Throws if a property with this name does not exist.
link

function

getPropertyOrNull(name: String): unknown? (pkl.base)Source

Returns the value of the property with the given name.

Returns null if a property with this name does not exist.
link

function

toDynamic(): Dynamic (pkl.base)Source

Converts this object to a Dynamic object.
link

function

toMap(): Map<String, unknown> (pkl.base)Source

Converts this object to a Map.
link

function
relativePathTo(other: Module): List<String> (pkl.base)Source

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):
```
import "rootModule.pkl" // self-import
path = rootModule.relativePathTo(module)
```

Type Aliases(show inherited)

link

typealias

Shell = "pwsh"|"bash"|"sh"|"cmd"|"powershell"|"python"|String (com.github.actions.AbstractStep)