Page Comparison

...

...

Which Work Items are Updated

Identical to the Validate Work Items Gate, the Update Work Items Step offers 3 options or selectors for choosing which Work Items should be updated. Please refer to the Gate documentation for an in-depth look at how each Selector works and when to use one vs another.

Adding Attachments

Attachments can be added to each Work Item by selecting the type of attachments that should be added via the Attachments field. The field supports two attachment types:

• Plugin Logs - This will attach all plugin logs from the Workflow Execution that was associated to the Work Item. Note that a Work Item may have no executions or more than 1.

  • Attachment name pattern = [workflowExecutionId]-[pluginOperationName]-[pluginExecId]-[endpointId].log

• Reports - If the associated Work Item executions generated any reports, those can be attached with this option.

  • Attachment name pattern = [workflowExecutionId]-[reportNameWithExt]. Note that if multiple reports have the same name then the full report filepath will be used.

Zipping Attachments

Since each Work Item may have multiple executions with multiple plugin steps and reports, you can optionally zip all attachments for the Work Item and only upload the single zip file

Updating the Status

The status of each Work Item can be changed by specifying a status in the Status field. There are 3 options for specifying a status:

1. Literal Text - The default, each Work Item will attempt to have its status changed to the text value provided here. This is the easiest and simplest approach if all of your Work Items allow the same statuses.

2. Groovy Expression (String/Text) - A Groovy expression can be used for more dynamic behavior. When using a Groovy Expression you can return a simple string or text that will be used for each Work Item.

3. Groovy Expression (Map) - The most advanced option but also the most dynamic. The Groovy script can return a map of [workItemNumber: new_status]if you need to assign different statuses based on the Work Item. When using a Groovy script their is an exposed variable WorkItems that contains all Work Items considered for update. The below script is an example that assigns different statuses depending upon the prefix of the Work Item Number.

def result = [:]
for (def workItem: WorkItems)
{
  if (workItem.getKey().startsWith("GLORY"))
  {
    result.put(workItem.getKey(), "In Progress")
  }
  else if (workItem.getKey().startsWith("Natours"))
  {
    result.put(workItem.getKey(), "Doing")
  }
  else
  {
    result.put(workItem.getKey(), "DESIGN")
  }
}
return result

Adding Comments

Finally, comments can also be added to each Work Item. The options and approaches for adding comments align directly with the Updating the Status section above. Below is an example of the 3rd option of using a Groovy script and returning a map to assign a different comment to each Work Item.

def result = [:]
for (def workItem: WorkItems)
{
  def execs = workItem.getExecutions()
  if (execs != null && !execs.isEmpty())
  {
    def exec = execs.get(0)
    def message = "Work Item deployed to ${stgexec.getEnvironmentCode()} from Release ${stgexec.getReleaseName()} and Project ${exec.getProject().getProjectName()}. [View execution](${exec.getExecutionLink()})".toString()
    result.put(workItem.getKey(), message)
  }
  else
  {
    def message = "Work Item deployed to ${stgexec.getEnvironmentCode()} from Release ${stgexec.getReleaseName()}.".toString()
    result.put(workItem.getKey(), message)
  }
}
return result

Rich Comment Features

In the above script we are creating the comment text using markdown. This allows more rich text to be used such as bold, headings, links etc. Whether or not markdown, or other formatting can be used is ultimately at the discretion of the Issue Tracking System where the comment is being added. The following table highlights the feature disparity between the Issue Tracking Systems supported in FlexDeploy.