Bash - Tags

JFrog Pipelines Documentation

ft:sourceType
Paligo

This topic lists tags that can be used with Bash as Pipeline steps. For more information about Bash Pipeline steps, see Bash.

name

An alphanumeric string (underscores are permitted) that identifies the step. The name should be chosen to accurately describe what the step does, e.g. prov_test_env to represent a job that provisions a test environment. Names of steps must be unique within a pipeline.

type

Must be Bash for this step type.

configuration

Specifies all optional configuration selections for the step's execution environment.

Tag

Description of usage

Required/Optional

affinityGroup

Label that controls affinity to a Node. All the steps with the same affinityGroup will be executed on the same node. This will allow sharing state between the steps. An example is having the same affinityGroup for DockerBuild and DockerPush steps in a Pipeline so that Image being built in the DockerBuild step can be used to published in the DockerPush step.

Optional

priority

Controls the priority of a step when there are parallel steps in a pipeline or multiple pipelines executing. It determines which step will run first across all steps that could run if there were no constraints on the number of steps running. Steps with a lower number will run before steps with higher numbers. For example, priority 10 will run before priority 100. The default priority is 9999.

Priority does not apply to steps that are still waiting for an input to complete or configured to run in a node pool with no available nodes. Also, if there are two steps ready to run and only one available node, the one with the lower priority number runs first, regardless of which pipeline each step belongs to.

Optional

timeoutSeconds

Time limit, in the number of seconds, for the step to complete. If the step does not complete in the given time limit, the step will be forced to a completion state of failed.

Optional

nodePool

Assigns the node pool the step executes on. If node pool isn't specified, a step will execute on the default node pool. See here to learn more about node pool

Optional

chronological

Specifies the step must execute in chronological order, to ensure receipt of all state updates from preceding steps.

A step with chronological:true will only execute when that step is complete in all previously triggered runs.

Optional

allowFailure

If you do not want a step to contribute to the final status of the run, add allowFailure: true to the configuration section of that step. When this option is used, even when a step fails or is skipped, the final status of the run is not affected.

For more information, see Conditional Workflows.

Optional

condition

Create a condition based on the values of add_run_variables environment variable, so that a step can be skipped based on dynamically set variables before it gets assigned to a node.

For more information, see Run Variable Conditional Workflow.

Optional

environmentVariables

Assigns any environment variables and their values in key:value format. All environment variables assigned within a step definition are active only for the scope of the execution of that step.

If the following variables are set, they will be used:

  • JFROG_CLI_BUILD_NAME: If set, the pipeline uses this value instead of the default pipeline name for the build info collected.

  • JFROG_CLI_BUILD_NUMBER: If set, the pipeline uses this value instead of the default run number for the build info collected.

  • USE_LOCAL_JFROG_CLI: If set as true, the local JFrog CLI on the host or in the image (depending on runtime configuration) is used instead of the version packaged with JFrog Pipelines. This is not recommended and native steps may not be able to run with the local JFrog CLI version.

Optional

integrations

A collection of integrations that will be used by this step. Integrations can be used directly in step without a resource.

Optional

inputSteps

A collection of named steps whose completion will trigger execution of this step.

In addition, you can set status conditional workflow for input steps. When configured for a step, it executes only if an input step’s status, during its current run, is satisfied. You can configure any number of statuses for an input step.

Note

It is important to note that the status of an input step in the current run only is considered for conditional workflows. If a step is not part of the current run, it is always assumed that the condition for that input step is met.

For more information, see Step Status Conditional Workflow.

Optional

inputResources

A collection of named Pipelines Resources that will be used by this step as inputs.

  • trigger: By default, changes to these named resources will trigger execution of this step. This can be changed by declaring trigger as false.

  • newVersionOnly : Setting newVersionOnly as true on one or more inputs will cause the step to be skipped if one or more of those resources is an output resource of another step in the same run and none of the inputResources have been updated in the current run.

  • branch : A branch is only required when using a resource from another branch of a multi-branch source. By default, the resource from a single-branch source or from the same branch of a multi-branch pipeline is used. To use a multi-branch resource in a single-branch pipeline or another branch in a multi-branch pipeline, branch should be used to specify the branch to which the resource belongs.

Optional

outputResources

A collection of named Pipelines Resources that will be generated or changed by this step.

branch: A branch is only required for resources from another branch of a multi-branch source. By default, the resource from a single-branch source or from the same branch of a multi-branch pipeline is assumed. To update a multi-branch resource in a single-branch pipeline or another branch in a multi-branch pipeline, branch should be used to specify the branch to which the resource belongs.

Optional

runtime

Specifies the runtime for the execution node.

Optional

execution

Declare sets of shell command sequences to perform for different execution phases:

Tag

Description of usage

Required/Optional

onStart

Commands to execute in advance of onExecute

Optional

onExecute

Main commands to execute for the step

Optional

onSuccess

Commands to execute on successful completion of onExecute

Optional

onFailure

Commands to execute on failed completion of onExecute

Optional

onComplete

Commands to execute on any completion of onExecute

Optional

Note

onExecuteonStartonSuccessonFailure, and onComplete are reserved keywords. Using these keywords in any other context in your execution scripts can cause unexpected behavior.

Tip

To execute a series of commands or a block of code, follow the approach (using a pipe [- |]) as mentioned here:

        execution:
          onExecute:
            - |
              [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($PYARMOR_LICENSE)) > C:\build\pyarmor_license.zip
        execution:
          onStart:
            - |
              if [[ "$QUICK_MODE" == "true" ]]; then
                echo "sending failure update to git because this run was executed in QUICK_MODE"
                update_commit_status packagesGit --status failure --message "marked as failed due to quick mode" --context $step_name
              else
                update_commit_status packagesGit --status success --message "marked as success due to non quick mode" --context $step_name
              fi