Bash

Overview

The Bash is a generic step type that enables executing any shell command. This general-purpose step can be used to execute any action that can be scripted, even with tools and services that haven't been integrated with JFrog Pipelines. This is the most versatile of the steps while taking full advantage of what the lifecycle offers.

All native steps derive from the Bash step. This means that all steps share the same base set of tags from Bash, while native steps have their own additional tags as well that support the step's particular function. So it's important to be familiar with the Bash step definition, since it's the core of the definition of all other steps.

Usage

Bash

pipelines:
  - name: 			<string>
    steps:
      - name: 		<string>
        type: 		Bash
        configuration:
          affinityGroup: 	bldGroup 
          priority: 		<[0-10000]>
          timeoutSeconds: 	<job timeout limit>
          nodePool: 		<name of the nodePool>
          chronological: 	<true/false>
          environmentVariables:
            env1: 			<string>
            env2: 			<string>
          integrations:
            - name: 		<integration name>
          inputSteps:
            - name: 		<step name>
          inputResources:
            - name: 		<resource name>
              trigger: 		<true/false>    # default true
              newVersionOnly: <true/false>  # default false
              branch:       <string>        # see description of defaults below
          outputResources:
            - name: 		<resource name>
              branch:       <string>        # see description of defaults below
          runtime:            
            type: 			<image/host>
            image:
              auto:
                language:
                versions:
              custom:
                name:
                tag:
                options:
                registry:          <integration>   # optional integration for private registry
                sourceRepository:  <path>          # required if registry is Artifactory. e.g. docker-local
                region:                            # required if registry is AWS. e.g. us-east-1
                autoPull: 	<true/false> 	       # default true; pulls image before run

        execution:
          onStart:
            - echo "Preparing for work..."
          onExecute:
            - echo "executing task command 1"
            - echo "executing task command 2"
          onSuccess:
            - echo "Job well done!"
          onFailure:
            - echo "uh oh, something went wrong"
          onComplete: #always
            - echo "Cleaning up some stuff"

Page Contents

Tags

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. Steps will a lower number will run before steps with higher numbers. For example, priority 10 will run before priority 100. The default priority is 9999.	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
`environmentVariables`	Assigns any environment variables and their strings in key:value format. All environment variables assigned within a step definition are active only for the scope of the execution of that step.	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.	Optional
`inputResources`	A collection of named resources that will be used by this step as inputs. By default, changes to these named resources will trigger execution of this step. This can be changed by declaring `trigger` to `false`. Setting `newVersionOnly` to `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. 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 resources that will be generated or changed by this step. 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

Example

This is an example of how to use the Bash step to perform a build activity.

Bash step to build

- name: build
  type: Bash
  configuration:
    nodePool: my_node_pool
    runtime:
      type: image
      image:
        auto:
          language: nodejs
          versions:
            - "10.16.3"
    inputResources:
      - name: src
  execution:
    onExecute:
      - cd $res_src_resourcePath
      - npm install
      - mkdir -p testresults && mkdir -p codecoverage
      - $res_src_resourcePath/node_modules/.bin/mocha --recursive "tests/**/*.spec.js" -R mocha-junit-reporter --reporter-options mochaFile=testresults/testresults.xml
      - $res_src_resourcePath/node_modules/.bin/istanbul --include-all-sources cover -root "routes" node_modules/mocha/bin/_mocha -- -R spec-xunit-file --recursive "tests/**/*.spec.js"
      - $res_src_resourcePath/node_modules/.bin/istanbul report cobertura --dir codecoverage
      - save_tests $res_src_resourcePath/testresults/testresults.xml
    onSuccess:
      - send_notification mySlack "build completed"

Content

Space Tools