<p>This is a known bug.  See <a href="https://issues.jenkins-ci.org/browse/JENKINS-42878" rel="nofollow noreferrer">JENKINS-42878</a> and <a href="https://issues.jenkins-ci.org/browse/JENKINS-41996" rel="nofollow noreferrer">JENKINS-41996</a>.  This bug has been resolved upstream, which means you should be able to fix the bug by upgrading the plugin to the latest version.</p>

CC BY-SA 3.0
2017-10-28T01:39:27.927Z
Thanks for responding.  I am using the latest version of this plugin - both of these bugs appear to reference the issue I am having, but only as an incidental side effect, and I suspect that this fix may not have been verified. 
 This is good background on the issue though- thank you!  I am unclear how a plugin with thousands of monthly downloads could have such a glaring issue with no open bugs!
esoterydactyl
CC BY-SA 3.0
2017-10-26T20:39:33.597Z
2017-10-26T20:39:33.597Z
jayhendren
<p><a href="https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin/pull/37" rel="nofollow noreferrer">Based on this PR</a>, the <code>repoSlug</code> was added and now the status is sent to the right repository.</p>

<p>When it was not working:</p>

<pre><code>post {
    success {
        bitbucketStatusNotify(
                buildState: 'SUCCESSFUL',
                commitId: env.GIT_COMMIT
        )
    }
    failure {
        bitbucketStatusNotify(
                buildState: 'FAILED',
                commitId: env.GIT_COMMIT
        )
    }
}
</code></pre>

<p>Now it works:</p>

<pre><code>post {
    success {
        bitbucketStatusNotify(
                buildState: 'SUCCESSFUL',
                repoSlug: 'repoSlug aka repositoryName, e.g. some-app',
                commitId: env.GIT_COMMIT
        )
    }
    failure {
        bitbucketStatusNotify(
                buildState: 'FAILED',
                repoSlug: 'repoSlug aka repositoryName, e.g. some-app',
                commitId: env.GIT_COMMIT
        )
    }
}
</code></pre>

<p><a href="https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin" rel="nofollow noreferrer">The README in the Github repo emphasized that</a>:</p>

<blockquote>
  <p>Note that the repoSlug and commitId parameters work only when they are
  both specified.</p>
</blockquote>

CC BY-SA 4.0
2019-09-03T08:47:48.887Z
repoSlug is simply the name of the repository, I wasted a couple of hours until I figured this out. So if you have this repo: https://bitbucket.org/company/saas-frontend.

The reposlug would be: saas-frontend
Shahar Hamuzim Rajuan
CC BY-SA 4.0
2019-09-03T10:31:25.033Z
@ShacharHamuzimRajuan Yes that is [true](https://confluence.atlassian.com/bitbucket/what-is-a-slug-224395839.html). I will update the answer.
030
CC BY-SA 4.0
2019-03-12T00:05:40.607Z
2019-09-03T10:34:26.680Z
2019-09-03T10:34:26.680Z
030
<p>One could also use <a href="https://bcbsn.releasesoftwaremoreoften.com/" rel="nofollow noreferrer">bcbsn</a> as a replacement. This tool associates the build status with the right commit and sends the build status to the right repository.</p>

CC BY-SA 4.0
2019-03-13T11:30:57.850Z
2019-12-24T12:25:12.617Z
2019-12-24T12:25:12.617Z
030
<p>I am attempting to implement the Jenkins bitbucket-build-status-notifier-plugin, found here: 
 <a href="https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin" rel="nofollow noreferrer">https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin</a>  </p>

<p>We used the shared-pipeline code functionality of Jenkinsfile, along with multibranch pipelines- all our Jenkinsfile code lives in one repo and each application makes only a parameterized call to a function in this repo.<br>
The problem comes when the plugin posts status- it posts to the repo of the shared pipeline code, not the application being built!  It is otherwise working correctly, authenticating and posting status quickly.</p>

<p>The plugin is not parameterized to allow me to pass in a commit ID- meaning that this is being derived from an environment variable, presumably in a novel way that other plugins are not using.  The plugin specifically cites changes to facilitate Jenkinsfile and multi-branch pipelines.  I suspect I may have a race condition with the scm checkout command, perhaps the bitbucket plugin is being initialized before any call to scm checkout is made?</p>

<p>Does anyone have any advice on debugging this?  jenkins.err does not contain any errors, since nothing is throwing.  Is there an environment variable I can change in order to force a context switch from the shared pipeline code repo to the application code repo?</p>

CC BY-SA 4.0
2019-12-20T16:17:55.687Z
Did one of the answers solve the issue?
030
<jenkins><jenkins-pipeline><jenkins-plugins><jenkinsfile>
Why does the Jenkins bitbucket-build-status-notifier-plugin post the status to the shared pipeline library repository?
esoterydactyl
# Why does the Jenkins bitbucket-build-status-notifier-plugin post the status to the shared pipeline library repository?

(Asked by: username_0 on 2017-10-25)

I am attempting to implement the Jenkins bitbucket-build-status-notifier-plugin, found here:
<https://github.com/jenkinsci/bitbucket-build-status-notifier-plugin>

We used the shared-pipeline code functionality of Jenkinsfile, along with multibranch pipelines- all our Jenkinsfile code lives in one repo and each application makes only a parameterized call to a function in this repo.  
The problem comes when the plugin posts status- it posts to the repo of the shared pipeline code, not the application being built! It is otherwise working correctly, authenticating and posting status quickly.

The plugin is not parameterized to allow me to pass in a commit ID- meaning that this is being derived from an environment variable, presumably in a novel way that other plugins are not using. The plugin specifically cites changes to facilitate Jenkinsfile and multi-branch pipelines. I suspect I may have a race condition with the scm checkout command, perhaps the bitbucket plugin is being initialized before any call to scm checkout is made?

Does anyone have any advice on debugging this? jenkins.err does not contain any errors, since nothing is throwing. Is there an environment variable I can change in order to force a context switch from the shared pipeline code repo to the application code repo?

**Tags:** jenkins, jenkins-pipeline, jenkins-plugins, jenkinsfile

> **Comments:**
> **username_1**: Did one of the answers solve the issue?  

---

## 3 answers

### Answer by username_2 on 2017-10-26. Score: 4

This is a known bug. See [JENKINS-42878](https://issues.jenkins-ci.org/browse/JENKINS-42878) and [JENKINS-41996](https://issues.jenkins-ci.org/browse/JENKINS-41996). This bug has been resolved upstream, which means you should be able to fix the bug by upgrading the plugin to the latest version.

> **Comments:**
> **username_0**: Thanks for responding.  I am using the latest version of this plugin - both of these bugs appear to reference the issue I am having, but only as an incidental side effect, and I suspect that this fix may not have been verified.   This is good background on the issue though- thank you!  I am unclear how a plugin with thousands of monthly downloads could have such a glaring issue with no open bugs!  

---

### Answer by username_1 on 2019-03-12. Score: 3

Based on this PR, the repoSlug was added and now the status is sent to the right repository.
When it was not working:
post {
    success {
        bitbucketStatusNotify(
                buildState: 'SUCCESSFUL',
                commitId: env.GIT_COMMIT
        )
    }
    failure {
        bitbucketStatusNotify(
                buildState: 'FAILED',
                commitId: env.GIT_COMMIT
        )
    }
}

Now it works:
post {
    success {
        bitbucketStatusNotify(
                buildState: 'SUCCESSFUL',
                repoSlug: 'repoSlug aka repositoryName, e.g. some-app',
                commitId: env.GIT_COMMIT
        )
    }
    failure {
        bitbucketStatusNotify(
                buildState: 'FAILED',
                repoSlug: 'repoSlug aka repositoryName, e.g. some-app',
                commitId: env.GIT_COMMIT
        )
    }
}

The README in the Github repo emphasized that:

Note that the repoSlug and commitId parameters work only when they are
  both specified.

> **Comments:**
> **username_3**: repoSlug is simply the name of the repository, I wasted a couple of hours until I figured this out. So if you have this repo: https://bitbucket.org/company/saas-frontend.  The reposlug would be: saas-frontend  
> **username_1**: @ShacharHamuzimRajuan Yes that is [true](https://confluence.atlassian.com/bitbucket/what-is-a-slug-224395839.html). I will update the answer.  

---

### Answer by username_1 on 2019-03-13. Score: 0

One could also use [bcbsn](https://bcbsn.releasesoftwaremoreoften.com/) as a replacement. This tool associates the build status with the right commit and sends the build status to the right repository.


---

