CloudBees Cross Team Collaboration

In this lab we will explore the CloudBees CI Cross Team Collaboration feature. Cross Team Collaboration simplifies the cumbersome and complicated tasks of triggering downstream jobs by eliminating the need to identify and maintain the full path for every downstream job. Simply put, this proprietary CloudBees CI feature connects pipelines, increasing automation and collaboration. Prior to this feature, the details of every downstream job (Jenkins instance ID, full job name, Git branch name) all had to be meticulously specified in the upstream job. If the job name changed, the upstream job had to be refactored, creating a maintenance burden and discouraging the adoption of event-based triggers.

Cross Team Collaboration Events

The Cross Team Collaboration feature is designed to greatly improve team collaboration by connecting team Pipelines across any number of CloudBees CI controllers. It essentially allows a Pipeline to publish a notification event which will be trigger other Pipelines (across controllers) that are listening for that event. It consists of a Publishing Event and a Trigger Condition.

The Cross Team Collaboration feature has a configurable router for routing events and it needs to be configured on your managed controllers before you will be able to receive the event published by another Managed Controller. CloudBees CI CasC was used to pre-configure this for everyone.

1. To use Cross Team Collaboration in a pipeline job we will need to update the Jenkinsfile in the /templates/container-build folder in your copy of the pipeline-template-catalog repository, to listen for a notification event to be published by the upstream, or event publishing, job. We will do that by adding a trigger directive to then template Jenkinsfile Pipeline script.
2. Navigate to your copy of the pipeline-template-catalog repository in your workshop GitHub Organization, click on the Pull requests link and click on the Add Cross Team Collaboration Trigger pull request.
3. Click on the Files changed tab to review the requested configuration changes. Note that we have added a triggers block with an eventTrigger and we have updated the when condition to include triggeredBy 'EventTriggerCause':
4. Once you have finished reviewing the changes, click on the Conversation tab of the Add Cross Team Collaboration Trigger pull request, scroll down and click the green Merge pull request button and then click the Confirm merge button.
5. Navigate to the open main branch job of your insurance-frontend-build project on your managed controller and click the Build Now link in the left menu. Then view the configuration for that job by clicking the View Configuration link.
6. Click on the Build Triggers tab on the job configuration page for the PR-1 job and you will see that the Build whenever the specified event is seen trigger is checked and configured with a Jmespath Query as specified in the template above.

7. Next, your instructor will set up a Pipeline project with the following JSON event:

publishEvent event:jsonEvent("""
          {
            'image':{'name':'nginx','action':'update','tag':'1.22.0'}
          }
        """), verbose: true

The entire Jenkins Pipeline containing the publishing event (also available in GitHub here):

pipeline {
  agent none
  stages {
    stage('Update Docker Image') {
      steps {
        echo 'updated docker image nginx'
        publishEvent event:jsonEvent("""
          {
            'image':{'name':'nginx','action':'update','tag':'1.22.0'}
          }
        """), verbose: true
      }
    }
  }
}

That event will be published across all Managed Controllers in the Workshop cluster via the CloudBees CI Cloud Operations Center event router, triggering everyone’s insurance-frontend-build Pipelines to run.

8. Now, once that change is committed, and the job with the publishEvent runs, everyone will see the open PR branch of their insurance-frontend-build job triggered by the JSON event and if you explore the Console Output of that build you will see that the BASE_IMAGE_TAG value is coming from the published event payload instead of what is specified in the Dockerfile of the insurance-frontend repository.