Currently, a change event can be triggered anywhere in a pipeline job (even multiple times). It would be nice if the pipeline developer could pass alternate text for the Summary, so that a PagerDuty user can easily see what ChangeEvent occurred, not just a generic summary based on the job.

To further explain, consider the following use case:

Developer maintains a deployment pipeline that deploys to a production environment. The deployment takes about 10 minutes to complete. Developer wants a change event posted before AND after the deployment.

For example:

 stage(‘production-deploy’){
  steps{
    //Current implementation (for comparison)
    pagerdutyChangeEvent(integrationKey: 'REDACTED')
    //Proposed syntax change
    pagerdutyChangeEvent(integrationKey: 'REDACTED', summaryText: 'DEPLOY STARTED for ProjectX v1.2.3')
    sh """
      echo '***simulate deployment***'
      sleep 600
    """
    //Proposed syntax change
    pagerdutyChangeEvent(integrationKey: 'REDACTED' summaryText: 'DEPLOY COMPLETED for ProjectX v1.2.3')
  }
}

The current implementation posts a generic change event with the name of the job and build number.  The new field provides unique text indicating the start and end of the deployment.  I have attached a screenshot below of what the output in pagerduty should look like with this chnage.

Benefits:

• provides context to the “what” that a change event represents (including version info, or other relevant details) without navigating to Jenkins
• If a pageable event occurs during or after the deployment window, the deployment itself could be identified as a problem
• User can still get link to the Jenkins job for further info.