This documentation is for the Technical Preview of JFrog Pipelines, available exclusively to JFrog Enterprise+ customers
.

Skip to end of metadata
Go to start of metadata

step is an unit of execution in a pipeline. It is triggered by some event and uses resources to performs a build action as part of the pipeline workflow.


Steps take Inputs in the form of Integrations or Resources, execute tasks that perform the operations necessary and then produce a result i.e. Output(s). Now these Outputs can become Inputs to other steps and so on forming a dependency-based, event-driven DevOps Assembly Line.


Page Contents

A trigger for a step is some external event,, or combination of events such as:

  • A commit to a source code repository
  • Completion of another step
  • A change to a resource, such as the generation of a new Docker image


Generic and Native Steps

A generic step is for general-purpose execution. The Bash step, which executes any series of shell commands you specify, is the single generic step of JFrog Pipelines.

A native step performs a specific set of actions as an encapsulated unit. Native steps inherently know what shell commands to execute to perform their action. With native steps, you can create complex workflows that push, publish, and promote your builds in Artifactory using simple step definitions.

All native steps derive from the base Bash step definition, so all steps have the same base tag:entity structure in a pipeline config. Each native step defines additional tags that are specific to its function.


Step YAML Definition

Steps are defined in a pipeline config under the steps tag, as shown below. 

apiVersion: v1.1
pipelines:
  - name: pipe1
    configuration:
      <optional configuration settings>
    steps:
      <collection of step types>

All  step types are composed of these top-level tags:


TagRequiredDescription of usage
name

REQUIRED

An alphanumeric string (underscores are permitted) that identifies the step. This is the name that will be used when the step is assigned as an input to other steps. 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

REQUIRED

A predefined step type. A list of all available steps is below.
configuration

NOT REQUIRED

Specifies all optional configuration selections for the step's execution environment. These settings include:

  • Node pool assignment.
  • Environment variable definitions.
  • Input and output integrations, resources, and steps.
  • Runtime the step will execute in.

While none of the tags are required, in practice you will at least need to define the integrations, steps, and/or resources that trigger the execution of the step.

execution

NOT REQUIRED

Specifies the actions to perform for each execution phase of the step. These phases may include:

  • the base set of commands
  • successful execution of the base set
  • failed execution of the base set
  • commands to execute on any completion (e.g., for cleanup)

Step types


  • Bash

    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.


  • CreateReleaseBundle

    The CreateReleaseBundle is a native step that produces a Release Bundle for distribution to an Artifactory Edge Node. The step can be used to create a signed or unsigned release bundle.


  • DistributeReleaseBundle

    The DistributeReleaseBundle native step triggers the distribution of a Release Bundle to an Artifactory Edge Node. This step requires a signed release bundle and one or more distribution rules to successfully execute. 


  • DockerBuild

    The DockerBuild native step performs a build to produce a Docker image.

  • DockerPush

    The DockerPush native step pushes a Docker Image to a Docker registry like Artifactory.


  • GoBuild

    The GoBuild native step performs a build from Go (GoLang) source.


  • GoPublishBinary

    The GoPublishBinary native step publishes the GO (GoLang) binaries to Artifactory. 


  • GoPublishModule

    The GoPublishModule native step publishes the GO (GoLang) modules to an Artifactory. This step should be used in conjunction with the GoBuild step.


  • GradleBuild

    The GradleBuild native step performs a Gradle build.


  • MvnBuild

    The MvnBuild native step performs a Maven project build. Using this step automatically selects Java as language and bootstraps the runtime environment in the node appropriately.


  • NpmBuild

    The NpmBuild native step builds an npm source. This step automatically performs npm install and npm build on the source folder. If you want to run tests, add a Bash step to trigger them. 


  • NpmPublish 

    The NpmPublish step publishes an npm package to the registry in Artifactory following an NpmBuild step.


  • PromoteBuild

    The PromoteBuild native step promotes a BuildInfo and moves or copies the related artifacts from one Artifactory repository to another. 


  • PublishBuildInfo

    The PublishBuildInfo step publishes BuildInfo to Artifactory. BuildInfo can also be published by any of the language specific publish steps. BuildInfo provides a manifest for the build and includes metadata about the modules, dependencies and other environment variables. Read here to learn more about BuildInfo. 


  • SignReleaseBundle

    The SignReleaseBundle native step signs a Release Bundle in preparation for distributing it to Edge nodes. 


  • XrayScan

    The XrayScan native step triggers a scan by JFrog Xray for security vulnerabilities and license compliance. If there was a watch created that covers the selected build, Xray will scan the indexed build artifacts.  


  • No labels