Update Change Tickets
The Update Change Tickets Step will apply a number of optional updates to Change Tickets associated to the Stage Execution Info, such as adding comments and attachments.
Available in version 9.0.0.2
Adding Attachments
Attachments can be added to each Change Ticket 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 Change Ticket. See Change Ticket Executions below to see how a Workflow Execution is associated to a Change Ticket.
Attachment name pattern =
[workflowExecutionId]-[pluginOperationName]-[pluginExecId]-[endpointId].log
Reports - If the associated Change Ticket 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 Change Ticket may have multiple executions with multiple plugin steps and reports, you can optionally zip all attachments for the Change Ticket and only upload the single zip file.
Adding Comments
Comments can be added to each Change Ticket by using the Comment field. There are 3 options for adding comments:
Literal Text - The default option, each Change Ticket will use the literal text value provided here as the comment to add.
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 Change Ticket.
Groovy Expression (Map) - The most advanced option but also the most dynamic. The Groovy script should return a map of
[cmsTicketId: comment]
. This is most useful if you need to assign different comments based on the Change Ticket. There is an exposed variableChangeTickets
that contains all Change Tickets considered for update. The below script is an example that adds a link back to the FlexDeploy Workflow Execution if the Change Ticket includes Workflow Executions during the Pipeline Stage processing.
def results = [:]
for (def changeTicket : ChangeTickets)
{
if (!changeTicket.getExecutions().isEmpty())
{
def exec = changeTicket.getExecutions().get(0)
def message = "Change Ticket deployed to ${stgexec.getEnvironmentCode()} from Release ${stgexec.getReleaseName()} and Project ${exec.getProject().getProjectName()}. ${exec.getExecutionLink()}".toString()
results.put(changeTicket.getCmsTicketId(), message)
}
else
{
def message = "Change Ticket had no deployment to ${stgexec.getEnvironmentCode()} from Release ${stgexec.getReleaseName()}.".toString()
results.put(changeTicket.getCmsTicketId(), message)
}
}
return results
Change Ticket Executions
A Change Ticket may have 0 or more Workflow Executions associated to it while processing this step. These are available in Groovy scripts via the getExecutions
method on the Change Ticket objects (see the comment script above). Workflow Executions become associated to the Change Ticket based on what is provided in the Stage Execution Info popup as shown below.
There are two main rules to keep in mind here:
If a Change Ticket is provided in the Project Change Tickets field, as is the case with CHG0030016, then any execution for that specific Project will be associated to the Change Ticket. In this case the Workflow Execution of the GitHub Issue Project.
If a Change Ticket is provided in the global Change Tickets field, like CHG0030015, then all Projects that do not have a Project level Change Ticket associated will be associated to the global Change Ticket. In this case the Workflow Executions for the Azure DotNet and GitLab Issue Projects.
Skipped Deployments
Note that its possible that a Project will not deploy if FlexDeploy detects that no changes are found in the source code. In this case, even though a Change Ticket may be associated, there will be no Workflow Execution associated.
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 = "Change Ticket deployed to ${stgexec.getEnvironmentCode()}"
// the following line will produce a GStringImpl cannot be cast error
result.put(changeTicket.getCmsTicketId(), message)
// alter it to the following
result.put(changeTicket.getCmsTicketId(), message.toString())
- style