@ParametersAreNonnullByDefault @ReturnValuesAreNonnullByDefault

Package com.atlassian.bitbucket.jenkins.internal.status

There are primarily 3 types of job we should focus on:
  1. Freestyle Job
  2. Workflow, this is further characterized below as,
    1. Pipeline job
    2. Multi branch pipeline job

Pipeline and multibranch pipeline can have build steps mentioned in:

  1. Inline groovy script
  2. Fetched from Git repository (Jenkinsfile). This can be specified as either through Bitbucket SCM or through Git SCM.

There can be multiple SCM associated with a single job. We try our best to handle those. We skip posting build status in case we can't.

In addition, a pipeline script can also specify Git url as well. Example, 
  node {
   git url: 'https://github.com/joe_user/simple-maven-project-with-tests.git'
   ...
 }

We assume that for a build status to be posted, there needs to be some association with BitbucketSCM or BitbucketSCMSource This can be done in following ways. We will send the build status in all of these cases:

  1. Freestyle job has Bitbucket SCM. For simply GitSCM, we will not post any build status since we don't have credentials and server id.
  2. Pipeline job has Bitbucket SCM to fetch jenkins file.
  3. Pipeline job has Bitbucket SCM to fetch jenkins file. Jenkins file has bb_checkout step mentioned.
  4. Pipeline job has Git SCM to fetch jenkins file. Jenkins file has bb_checkout step mentioned.
  5. Multi branch pipeline has Bitbucket SCM for branch scanning.
  6. Multi branch pipeline has Bitbucket SCM for branch scanning and bb_checkout step mentioned in Jenkinsfile.
  7. Multi branch pipeline has Git SCM and has bb_checkout step mentioned in Jenkinsfile.
Some of the things that should also be kept in mind are:
  1. Workflow job has an option of lightweight checkout. This is to fetch Jenkinsfile. This is not a representation of build being run.
Overall workflow of sending build status is as follows:
  1. We add SCM Listener LocalSCMListener which listens for checkouts
  2. On a checkout completion, we check association with BitbucketSCM or BitbucketSCMSource
  3. We attach a BitbucketRevisionAction for storing the checkout context.
  4. We send an In progress build status
  5. We add a Run listener BuildStatusPoster which listens for builds
  6. On Build completion, we retrieve the BitbucketRevisionAction and send build status to Bitbucket.
Add package level annotations to indicate everything is non-null by default.