Update Work Items Step

The Update Work Items Step will apply a number of optional updates to Work Items in the Release, such as updating the status or adding attachments.

Available in version 9.0.0.1

1 Which Work Items are Updated
2 Adding Attachments
- 2.1 Zipping Attachments
3 Updating the Status
4 Adding Comments
- 4.1 Rich Comment Features
5 FAQ and Common Issues
- 5.1 class org.codehaus.groovy.runtime.GStringImpl cannot be cast to class java.lang.String

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.

Attachments in comments

If the step is both adding attachments and comments to the Work Items, then the attachments will be included in the comment itself. Note that not all Issue Tracking Systems support attachments in comments (see table at the bottom), in which case they will still be attached directly to the Work Item.

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:

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.
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.
Groovy Expression (Map) - The most advanced option but also the most dynamic. The Groovy script should return a map of [workItemNumber: new_status]. This is most useful if you need to assign different statuses based on the Work Item. There 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

The workItem object has a multitude of attributes and fields such as assignee, status, labels etc that can be leveraged to help determine the correct status.

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.

Issue Tracking System	Supports Comments	Supports Markdown Comments	Supports Attachments	Support Attachments in Comments

Issue Tracking System	Supports Comments	Supports Markdown Comments	Supports Attachments	Support Attachments in Comments
Flex ITS
Jira
Azure Boards
GitLab
GitHub

FAQ and Common Issues

class org.codehaus.groovy.runtime.GStringImpl cannot be cast to class java.lang.String

This can occur if you are using Groovy’s GString feature but not calling toString at the end of it. For example:

// using ${variable} inside a quoted "" string is what is known as GString in groovy
def message = "Work Item deployed to ${stgexec.getEnvironmentCode()}"
// the following line will produce a GStringImpl cannot be cast error
result.put(workItem.getKey(), message)

// alter it to the following
result.put(workItem.getKey(), message.toString())