Create a Sample Pipeline Definition
Pipeline Definitions are used to model the workflow for a particular Pipeline.
In the VersionOne Continuum user interface, select Flow > Manage Pipelines from the menu in the upper right. This is the Pipeline Editor.
Under the filter box, select
Add New. Name the Stage "Example Stage" and click Create. The Stage editor will appear. Now click the
Pluginstab on the upper left. Briefly click through the available Plugins. The list of functions immediately to the right will change as you click through. More on these later.
NOTE: the Pipeline Editor automatically saves on each change. Be extra careful when working on Pipelines that are in use.
When ready, click Utility. Select Insert Log and drag it over to the right where it says Drop Here. You have just added a Step to the Stage. Add some text to the Message box. "Hello World" will work.
Return back to the main Pipeline Editor page (hint: blue button upper right!). Select Add New under the Phase Library. Give it a name such as "Example Phase" and Create. Click the Stage Library tab on the left. Drag the Stage previously created over to the right and drop it. Return to the main Pipeline Editor screen.
Create a new Definition and name it something like "Example Pipeline". Add the previously created Phase to the Pipeline. Remember what you named the Pipeline, we'll need it later.
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 in to 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 setup 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 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 complete 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 Pipeline > Instances. You should see a row in this table that represents the Pipeline Instance run. Click on this row.
Viewing the Pipeline Instance
On the Pipeline > 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