Bug Description

Re-triggering PR builds from the Bitbucket UI is not possible anymore.

When clicking it, Jenkins receives a request and logs the following:

Received push hook with empty changes from Bitbucket. Processing indexing on <PROJECT>/<REPO SLUG>. You may skip this scan by adding the system property -Dbitbucket.hooks.processor.scanOnEmptyChanges=false on startup.

This was introduced in this PR and released in version 937.0.0.

Before that version it was possible to re-trigger any build, which could be used to re-try a failed build or to rebuild an artifact, for example.

Similar, more severe issue with new bitbucket-webhooks-plugin (JFI)

We also had a similar, more severe issue with the new bitbucket-webhooks-plugin:

When we updated our plugins last week, we saw the deprecation notice for "the Plugin Webhook implementation" in version 937.2.0 (see https://plugins.jenkins.io/cloudbees-bitbucket-branch-source/releases/#version_937.2.0). We then installed the new replacement plugin already, so we could test it.

Afterwards no builds were triggered for pull requests anymore! In the logs we found the following:

Received push hook with empty changes from Bitbucket for <PROJECT>/<REPO SLUG>. Skipping.

We managed to find JENKINS-76366, but it was closed and released in 937.2.4. We were installing 937.2.5, so we thought this could not be the culprit. We also found JENKINS-76367, which was/is unreleased, but since we were still using the old plugin, this could not affect us, right?

We found out that our log message comes from the new plugin (reference). And after some more digging we found this PR, that titles "Disable embedded plugin webhook processor if bitbucket-webhook plugin is installed and enabled".

Disabling the plugin restored the Bitbucket functionality again (well, besides the other issue with re-triggering mentioned above).

This behavior is mentioned in the changelog of 937.2.4, but as a "Bug Fix"? I think this is something very much worth of a "Breaking Change" headline, so nobody fails to notice this.

Also, I find this change itself very confusing: If the new plugin is installed, it is used, no matter what is configured. But the configuration page does not show any hint of this. It still happily displays all four options for webhooks (plugin, native, Bitbucket API REST 1.0, Bitbucket API REST 2.0 (Experimental)). This was probably the most confusing part of this bug-hunt for us.

We would really appreciate, if this could be made more clear in the Changelog as well as the Jenkins UI.