When a build is aborted on a commit and a subsequent build is triggered on the same commit, the "previous aborted build" preservation logic in BitbucketBuildStatusHelper.notifyBuildStatus rewrites the new build's buildKey, but does so using the default md5 key instead of the actual buildKey the aborted build posted with. If pipelines pass a custom buildKey to bitbucketStatusNotify(...), the result is two status entries on the same commit for what should be a single check:

1. The original entry posted under the custom key (stale, state = FAILED from the aborted build).
2. A brand-new entry posted under md5(jobFullName#prevBuildNumber) from the rerun.

Root cause

In BitbucketBuildStatusHelper.notifyBuildStatus, the preservation block calls buildStatus.setKey(prevBuildStatus.getKey()), where prevBuildStatus is freshly built from createBitbucketBuildStatusFromBuild using defaultBitbucketBuildKeyFromBuild → md5(jobFullName + "#" + buildNumber).

overrideLatestBuild is hardcoded to false in BitbucketBuildStatusNotifierStep, so the rewrite always lands on the default md5 path.

The plugin does not read back the key that was actually sent to Bitbucket for the previous build, it assumes the previous run used the default md5. When the pipeline passed a custom buildKey for the aborted run, that assumption is wrong, and the rewrite points at a key that doesn't exist in Bitbucket, so a new entry is created instead of overwriting the old one.

Steps to reproduce

1. In a Pipeline, post a status with a custom buildKey:
   bitbucketStatusNotify(
   buildState: 'INPROGRESS',
   buildKey: 'my-readable-check',
   buildName: 'My Check',
   repoSlug: 'my-repo',
   commitId: '<sha>'
   )
2. Abort the build mid-run. Jenkins records Result.ABORTED. In post { always }{}, post the final status with the same custom key (state ends up FAILED).
3. Trigger a new build on the same commit. In post { always }{}, again post with the same custom key.
4. Look at the commit's statuses in Bitbucket Cloud:
   GET /2.0/repositories/{workspace}/{repo}/commit/{sha}/statuses
    

Expected

One status entry per check (the rerun overwrites the aborted run's entry).

Actual

Two entries on the same commit:

• key: my-readable-check, state: FAILED, name: "My Check" — stale, from the aborted run.
• key: <32-char md5 hex>, state: SUCCESSFUL (or whatever the rerun ended as), name: "<jobFullName> #<rerunBuildNumber>" — from the rerun.

When the preservation block sets buildStatus.setKey(...), it should use the same key the previous build was instructed to post under (i.e., the buildKey the previous BitbucketBuildStatusNotifierStep call resolved to), not a recomputed default.

Related issues

• JENKINS-32940 — original change that introduced the preservation logic.
• JENKINS-53082 — related: aborted should map to STOPPED, not FAILED.