stephenconnolly probably would have a better idea than anyone else.

So what the plugin should probably do is add some custom inference to the step. It should be able to look for the SCMRevisionAction on the build just like the built-in notification does and only fall back to using the checkout if the job is not a Bitbucket branch

Won't help for multibranch where people are using a source other than the bitbucket branch source, but they will just have to pull out the hash directly.

I wonder if people using the notifier before checkout have actually been notifying the previous commit status?

I got around this issue by creating this function in our Global Pipeline Library and calling it at the beginning of each pipeline I have.

def call(buildId, jobName) {
    if ("${buildId}" == "1") {
        build job: "${jobName}", wait: false
        currentBuild.result = 'ABORTED'
        error("Skipping build ${buildId} as it doesn't play nice with bitbucket notifications")
    }
}

And it's called with this line in the Pipeline

script {
    rerunBuildOne(env.BUILD_ID, env.JOB_NAME)
}

It's pretty crude, but all is does is abort the build and start a new build for the same job if it's the first build. Which fixes the issue while I wait for this bug to be fixed.

Also if it helps I've noticed that the commit ID that the notifier is supplying to BitBucket is the same commit ID as my Global Pipeline Library repository instead of the commit for the code being built. This explains why BitBucket says that it can't find the commit for the given repo, and will hopefully give you an easier way to recreate the bug.

We too suffer from this annoying problem. Just like Antonio mentioned in August, the problem is the call to WorkflowJob.getSCMs() of workflow-job-2.15.jar. This method gets the SCMs from the last successful build or the last completed build. Obviously, for the first build on a branch there isn't either. So it does not return any SCM information, hence Bitbucket status notifier does not notify any SCM. So this might be a problem of the workflow-job plugin after all.

    @Override public Collection<? extends SCM> getSCMs() {
        WorkflowRun b = getLastSuccessfulBuild();
        if (b == null) {
            b = getLastCompletedBuild();
        }
        if (b == null) {
            return Collections.emptySet();
        }
        Map<String,SCM> scms = new LinkedHashMap<>();
        for (WorkflowRun.SCMCheckout co : b.checkouts(null)) {
            scms.put(co.scm.getKey(), co.scm);
        }
        return scms.values();
    }

As for the proposal to use the SCMRevisionAction.getRevision() method : it does not seem to yield enough information. The plugin needs userName and repoName of the repository in addition to the commit hash.

cschwarz if it helps at all, we moved over to the Bitbucket source branch plugin, and it does the start / finish / failure notifications without even having to think about it (including solving this issue).

https://wiki.jenkins.io/display/JENKINS/Bitbucket+Branch+Source+Plugin

Any update on this issue? Is there anything I can do in order to help?

I created another plugin, see https://github.com/030/golang-bitbucket-cloud-build-status-notifier

Why do we need to fetch previous build scm values here https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin/blob/df373d0ae3ac32a5337c1c002505dee0c85ff5b0/src/main/java/org/jenkinsci/plugins/bitbucket/BitbucketBuildStatusHelper.java#L142?

Couldn't we replace this line with 

Map<String,SCM> scm_map = new LinkedHashMap<>();
for (WorkflowRun.SCMCheckout co : build.checkouts(null)) {
    scm_map.put(co.scm.getKey(), co.scm);
}
Collection<? extends SCM> scms = scm_map.values()

I copied the workaround to fail on first build to get around this bug, but changed the status to NOT_BUILT and added a re-trigger of the build by adding the following stage

stage('conditional abort first build') {
    when {
        expression { "${env.BUILD_NUMBER}" == "1" }
    }
    steps {
        echo "Aborting first build to workaround bitbucketStatusNotify issue"
        /* re-trigger this build job */
        build job: "${env.JOB_NAME}", wait: false
        script {
            currentBuild.result = 'NOT_BUILT'
            return
        }
    }
}
    

In the first commit on a jenkins multibranch pipeline with Bitbucket Build Status Notifier Plugin Version 1.4.2 is not send to bitbucket:

07:35:28  bitbucketStatusNotify:bitBucketBuildState=SUCCESSFUL bitBucketBuildRepoSlug=mule-cloudhub-* bitBucketBuildCommitId=c8690ed048aaa86493097ee844d8d44de9846fa3
[Pipeline] bitbucketStatusNotify
[Pipeline] echo
07:35:28  cleanupStep:start 

second (manual) build show it twice

11:39:30  bitbucketStatusNotify:bitBucketBuildState=SUCCESSFUL bitBucketBuildRepoSlug=mule-cloudhub-* bitBucketBuildCommitId=c8690ed048aaa86493097ee844d8d44de9846fa3
[Pipeline] bitbucketStatusNotify
11:39:31  Sending build status SUCCESSFUL for commit c8690ed048aaa86493097ee844d8d44de9846fa3 to BitBucket is done!
11:39:31  Sending build status SUCCESSFUL for commit c8690ed048aaa86493097ee844d8d44de9846fa3 to BitBucket is done!
[Pipeline] echo
11:39:31  cleanupStep:start