Skip to main content
System StatusContact Support
VersionOne Community

Configuring the VersionOne Lifecycle Plugin

This feature is available in Ultimate edition only.

editions-u.png

Overview 

Instructions on how to configure the Lifecycle plugin for Continuum.

All plugins support variable replacement in their properties. See Plugin Variables for details.

Submission Directives

In addition to functions available in Pipelines, the Lifecycle plugin also supports looking up Work Items in the Submission API.

To lookup Lifecycle 'Assets' (Stories, Backlog Items, Defects, etc) from the commit messages of incoming changes, simply add a Plugin Function Directive to any Projects configured to accept changes from a repository.

If you've never connected a Project to a repository, see Tutorial: First Pipeline for details. For general Project information, see Projects.

For example:

  • As a system administrator in Lifecycle Continuum, navigate to Flow - Manage Projects and select a Project.

  • On the Source tab, add a new Directive and set the Action to Plugin Function.

  • For the Plugin property, enter v1plugin.main.

  • For the Method property, enter identify_workitems.

The Lifecycle identify_workitems function recognizes the following arguments:

  • fields - (required)

    • a list of fields in the change submission to search for the expression

  • expression - (optional)

    • a regular expression applied to a change comment that will identify Lifecycle items

  • push_link - (optional)

    • (true/false) - if true, will push a link to Continuum back onto the Work Item in Lifecycle. ('false' if omitted)

  • ignore_secondary - (optional)

    • (true/false) - if true, will not pull the 'Secondary Workitem' into Continuum. ('true' if omitted)

Regarding the 'expression'

Lifecycle has a standard naming convention for various types of work items. If expression is omitted, the function will assume the Lifecycle default patterns for Stories, Backlog Items, Defects, Tasks and Acceptance Tests using the following regular expression.

[bB]-[0-9]{1,5}|[sS]-[0-9]{1,5}|[dD]-[0-9]{1,5}|[aA][tT]-[0-9]{1,5}|[tT][kK]-[0-9]{1,5}

Providing an expression will completely override the default expression, so be sure to enter all desired patterns!

Here's an example of the minimum required Plugin Function args. (In this example, the 'expression' would search the commit['message'] field in a GitHub commit, and match Issues, Stories, Backlog items, Defects and Acceptance Tests.)

{
    "fields": ["message"]
}

In this example, both the 'message' as well as the repository 'branch' are considered for work item lookup:

{
    "fields": ["message", "branch"]
}

Continuum normalizes the data from different SCM technologies into a common format. 'branch' is one of those common fields we derive. Evaluation happens on the internal Continuum 'change' object record, so any property on that record is valid for work item lookup.

In this next example, the 'expression' has been adjusted to include Issues as well as the other types, only matches capital letters, and will push a link back to Continuum into Lifecycle.)

{
    "expression": "I-[0-9]{1,5}|B-[0-9]{1,5}|S-[0-9]{1,5}|D-[0-9]{1,5}|AT-[0-9]{1,5|TK-[0-9]{1,5}",
    "fields": ["message"],
    "push_link": true
}

Pipeline Functions

The Lifecycle plugin implements several useful functions for connecting Lifecycle Continuum data back to objects in Lifecycle to create a more seamless integration between the two systems.

Create Pipeline Run

Lifecycle contains an object called a BuildRun, which is intended to serve as a grouping of all Work Items and ChangeSet (commit) records that were part of a "build" in an external system. The concept of a BuildRun is most closely tied to the notion of a traditional build in a CI system such as Jenkins. Since a Continuum Pipeline is a complex orchestration of many different "builds" as well as other automation, you can be more creative in your use of BuildRuns in Lifecycle and design very useful reporting in Lifecycle using Build Run Contents Reports.

Using the Create BuildRun plugin requires the initial manual configuration of a BuildProject in Lifecycle.

Properties

  • Pipeline Reference - (required) - Used to identify a Lifecycle Pipeline by it's Reference field.

  • Pipeline Run Name - The Name property of the new Pipeline Run. Defaults to 'Pipeline: <pipeline name> (instance name)' if omitted.

  • Pipeline Run Reference - The Reference property of the new Pipeline Run. Defaults to 'Project: <project name> (group)' if omitted.

  • Initial Status - Set an initial Status using either the OID or Name of a valid BuildStatus.

  • Save ID in Key - Place the OID of the newly created Pipeline Run into the Instance Workspace. (For future reference, usually to update the BuildStatus.)

Set Pipeline Run Status

Typically, Pipeline Run are created early in a Pipeline, and later in the Pipeline the status is changed. The Set Pipeline Run Status function accomplishes this.

Properties

  • Pipeline Run OID -(required) - OID of the Pipeline Run to update. (Usually set in a Workspace Variable by the Create Pipeline Run function.)

  • New Status - Set the Status using either the OID or Name of a valid BuildStatus.

  • Set Workitems as Complete - Will set all Workitems in this Instance as Completed in Build Run.

Set Work Item Status

The Set Workitem Status will set the status of exactly one specified Workitem.

Properties

  • Workitem Number -(required) - 'Number' of the Workitem. (ex: S-12345)

  • New Status - Set the Status using either the OID or Name of a valid StoryStatus.

  • Current Status - Limiting condition - will only set the New Status if the Workitem is in the specified Current Status. (Accepts a comma-separated list of StoryStatus Names.)

Set All Work Item Status

The Set All Workitem Status will set the status of every Workitem on the Pipeline Manifest.

Properties

  • New Status - Set the Status using either the OID or Name of a valid StoryStatus.

  • Current Status - Limiting condition - will only set the New Status if the Workitem is in the specified Current Status. (Accepts a comma-separated list of StoryStatus Names.)

Set Work Item Attributes

The Set Workitem Attribute will set multiple attributes on exactly one specified Workitem.

Properties

  • Workitem Number -(required) - 'Number' of the Workitem. (ex: S-12345)

  • Attributes - A YAML formatted list of attribute: value declarations. (YAML format allows multi-line entries, etc.)

Here is an example of an Attributes field:

Custom_IsHappy: False
Reference: awesome!!!
Description: |
   There once was a short man from ealing
   Who got on a bus to Darjeeling
       It said on the door
       "Please don't spit on the floor"
   So he carefully spat on the ceiling

In Lifecycle, certain 'custom attributes' are actually list assets. This function will attempt to determine if each specified key is either a list attribute or a regular attribute. If a specified key is not found to be a list asset, it is presumed to be a work item attribute. If it is a list asset, and the provided value isn't already defined in that list, a warning will appear in the log and the value will not be set.

Certain fields in Lifecycle are strongly typed, and will cause the Pipeline to fail if a value isn't valid. For example, trying to set a DateTime field to 'abc' will cause the Pipeline to Fail.

Set Attributes on All Work Items

The Set Attributes on All Workitems will set multiple attributes on every Workitem on the Pipeline Manifest.

Properties

  • Attributes - A YAML formatted list of attribute: value declarations. (YAML format allows multi-line entries, etc.)

See Set Workitem Attributes for an example of the Attribute field format.

  • Was this article helpful?