Create a Sample Pipeline Definition
Pipeline Definitions are used to model the workflow for a particular Pipeline.
- Click the Administration icon ( ) at the top right and select Flow > Pipelines from the menu. The Pipeline Builder page appears.
Click Add Pipeline. The New Pipeline dialog box appears.
Type a name (name it "Example Pipeline") and description for the Pipeline and click Create.
You can also click the Advanced link and add (copy/paste or type) a Pipeline definition JSON, if you have one already.
A Pipeline is made up of Phases, Stages, and Steps. A Pipeline can have any number of Phases, a Phase can have any number of Stages and a Stage can have any number of Steps.
- On the Phases tab, type a name for the first Phase and Stage (name it "Example Phase" and "Example Stage").
Sift through the available Plugins on the left pane and click a plugin to expand it. For example, click Utility and select Log and drag it over to the right where it says Drop Here. You have just added a Phase with a Stage and a Step.
Add some text to the Message box. "Hello World" will work.
Click Add Phase to add a new Phase.
Click the "+" icon on a Phase to add a new Stage.
Click a Plugin to expand it, select a step, drag and drop it on a Stage.
Repeat steps 8 through 10 to build your Pipeline definition.
When done, click Save.
Now, you have created a Pipeline. Remember the Pipeline name as you need it when you link it to a Project.
Link the Project to the Pipeline Definition
Return back to Manage Projects (upper right menu, Flow...) and select the Project created in previous steps. On the
Sourcetab add a new Directive. Choose Initiate Pipeline.
Leave the When selection set to Always. This means that when Changes come into the project we always want this Pipeline to be assigned the Changes and to be triggered.
Set Definition to "Example Pipeline" and Group to "[$ branch $]" (without the quotes).
Notice the "[$ ... $]" syntax. This denotes variable substitution. More on this later.
What we have done is set up a Directive that states when any change comes in associated with this Project, start (initiate) a Pipeline using the Pipeline Definition "Example Pipeline" and group the Pipeline Instances by branch name. The Pipeline Instances will also get associated with the current Project though there is a way to trigger a Pipeline on another Project which is out of the scope of this tutorial.
NOTE: when making changes to data in VersionOne Continuum, you must exit the field either by tabbing out or clicking somewhere else on the screen. This will trigger the auto-save. If the cursor stays in the field, the change may not save.
Triggering a Pipeline
We should be ready to go if all the steps in this tutorial have been successfully completed up to this point. Return to your local repository, make another change and commit/push it. Make sure to include the Work Item id in the comment.
In VersionOne Continuum, top menu, select Pipelines > Instances. You should see a row in this table that represents the Pipeline Instance run. Click this row.
Viewing the Pipeline Instance
On the Pipelines > Instance page, you will find a graphical representation of the Pipeline Definition from Phases to Stages to individual Steps. Click on the "Example Phase" box to expand it to show the status of each Stage and Step. In this case, we only have one each so it's not much to look at. However, if this was a more complex Pipeline Definition there would be several Phases and Stages each with their own status.
Next check out the Log tab on the left. Here is where you should see your "hello world" log message.
Take a look at the Manifest (left side). This is where you see all the Changes, Work Items and Artifacts (in and out) that are associated with this Pipeline Instance run. We don't yet have Artifacts so you will only see a single Change.
The Workspace tab displays all the raw data that is associated with the Pipeline Instance. This is an under-the-covers view of any data that is reportable for this instance. The more plugins and interfaces with third-party systems, the more interesting this data is. The data document can also be used as a reference for populating variables to pass into other systems (e.g. passing the branch and commit ID to a continuous integration server).
After you have completed the instructions for the specific issue management system, continue with the next step Build.