Successful runs of the pipeline in this quickstart look like this:
Before you Begin
Before trying this quickstart, ensure that you have:
- A GitHub account. This is required for forking the example repository.
- A JFrog Platform Cloud account, or self-hosted JFrog Pipelines.
- At least one node pool. This is the set of nodes that all pipeline steps will execute in. For more information, see Managing Pipelines Node Pools.
- A user account in Artifactory with deploy permissions to at least one binary repository.
Running this pipeline
Perform the following steps to run this pipeline:
Fork repositoryThe Pipelines DSL for this example is available in the JFrog GitHub repository repository in the JFrog GitHub account.
The DSL file is a yaml file that contains the pipeline definitions. This example uses two YAML files:
jfrog-pipelines-hello-world.yml, which contains the declarations for the pipelines in this example
values.yml, which contains the values required for the
For a full breakup of all the resources, pipelines and steps used in the yml file, see the jfrog-pipelines-hello-world.yml section below.
Fork this repository to your account or organization. This is important since you need admin access to repositories that are used as Pipeline Sources or GitRepo resources, in order to add webhooks to these repositories and listen for change events.
Sign in to JFrog Platform with your Artifactory credentials.
Go to Administration | Pipelines | Integrations to add one integration:
GitHub Integration: This integration is used to add the Pipeline source, as well as the GitRepo resource defined in values.yml, to connect Github to Pipelines. Write down the GitHub integration name.
The pipelines configuration is available in the values.yml file. Edit this file in your fork of this repo and replace the following:
Provide the name of the Github integration you added in the previous step.
Provide the path to your fork of this repository.
All pipeline and resource names are global across your JFrog Pipelines project. The names of your steps and resources need to be unique within the JFrog Pipelines project.
Add pipeline sourceThe Pipeline Source represents the git repository where our pipelines definition files are stored. A pipeline source connects to the repository through an integration , which we added in step 3.
In your left navigation bar, go to Administration | Pipeline | Pipeline Sources. Click on Add a Pipeline Source and then choose From YAML. Follow instructions to add a Pipeline Source . This automatically adds your configuration to the platform and pipelines are created based on your YAML.
An example of adding a pipeline source is shown below. Please ensure that the Repository Full Name points to your forked repository and the Pipeline Config File Filter is entered correctly as (jfrog-pipelines-hello-world|values).yml so that both your config files are included.
After your pipeline source syncs successfully, navigate to Pipelines | My Pipelines in the left navbar to view the newly added pipeline. In this example,
my_second_pipelineare the names of our pipeline.
Click the name of the pipeline. This renders a real-time, interactive, diagram of the pipeline and the results of its most current run.
Execute the pipeline
You can now commit to the repo to trigger your pipeline, or trigger it manually through the UI. The steps in the pipeline execute in sequence.
Once the pipeline has completed, a new run is listed.
Successful run of the first pipeline triggers the execution of the second pipeline:
.yml file is made up of resources, pipelines and steps, as shown below:
This example uses the following types of resources:
A GitRepo resource is used to connect JFrog Pipelines to a source control repository. Adding it creates a webhook to the repo so that future commits will automatically create a new version with the webhook payload.
This name is used to refer to the resource in steps, and must be unique across all repositories in your JFrog Pipelines environment.
|The name of the GitHub integration. Its value is retrieved from the values.yml file.||Required|
|The path of the repository from the integration root. Its value is retrieved from the values.yml file.||Required|
Defining a GitRepo resource acts as the trigger for the pipeline.
A PropertyBag resource is used to pass information from one pipeline to another, and to provide environment variables to a step in the format of a resource.
A PropertyBag resource can have any strings as properties, which will then be available as environment variables when the key is an input to a step. When it is an output, steps can change the values of properties or add new ones.
A property for the PropertyBag resource. The tag should be a valid variable name (Bash or PowerShell) for the steps where it is to be an input or output and the value a string. At least one is required, multiple properties are allowed.
This example uses two pipelines:
my_first_pipelineis the name of the first pipeline, consisting of 3 linear steps. The last step outputs a resource of type PropertyBag.
my_second_pipelineis the name of the second pipelines, which contains a single step triggered by the PropertyBag resource updated by the first pipeline
my_second_pipeline pipelines contain the following step type:
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.
In our example:
p1_s3are the names of the Bash steps in the
p2_s1is the name of the Bash step in the
The steps are defined so that they execute in an interdependent sequence. This means that each step's execution is triggered by the successful completion of a prior, prerequisite step (or steps). In our example, step 1's (p1_s1) completion triggers the execution of step 2 (p1_s2), completion of step 2 triggers execution of step 3 (p1_s3), and so on until all steps in the pipeline are executed.
Specifies all optional configuration selections for the step's execution environment.
Description of usage
A collection of named resources that will be used by a step as inputs.
In this example:
A collection of named steps whose completion will trigger execution of this step.
In this example:
A collection of named resources that will be generated or changed by a step.
Declare sets of shell command sequences to perform for different execution phases:
Description of usage
|Main commands to execute for the step||Optional|