Use pipeline run name as Bitbucket build status key

[michaelsauter]

• Multiple runs for the same commit now create multiple build status records
• Re-runs of pipeline runs update the build status corrresponding to the original pipeline run

Closes #736.

Tasks:

• Updated design documents in docs/design directory or not applicable
• Updated user-facing documentation in docs directory or not applicable
• Ran tests (e.g. make test) or not applicable
• Updated changelog or not applicable

[henrjk]

I find https://developer.atlassian.com/server/bitbucket/how-tos/updating-build-status-for-commits/ helpful. My understanding is:

1. The build status is associated with a commit even across repositories (and it appears projects even).
2. One can distinguish multiple build results by associating them with different keys. For example branch builds could have key 'branch' and integration builds 'integration'. The key could also be used to separate build results for different repositories.
3. Multiple builds with the same commit/key are not distinguished.

Number 1 appears troubling to me at first glance. On the other hand in practice this could be useful to connect a build status when a commit is deployed for example by a helm umbrella repo when it deploys a commit. Key could be 'DeployTest'. Perhaps I could be convinced that this is desirable.

When shown in summary spots in the UI the build results for a commit with different keys are combined:

• Case A: 3 builds ✓ If all builds are green, and 3 is the number of unique keys.
• Case B: 1 build failed if one build is red. Here the other builds are not mentioned. Only when one looks at the build status one would see all builds.
• Case C Not sure what happens if multiple builds are red.

Having a single red build taint the overall (summarized) status feels strange to me (so perhaps I am misunderstanding the bitbucket behavior). Assuming the above is correct and deletes a pipeline run for a failed build, because perhaps it is stuck, a new build would have a new PipelineRuns derived key and this could never turn the build summary green.

Perhaps it would make sense to allow the key to be specified in ods.yaml. So that branch builds use an empty key (or git commit-sha) and integration build can use a different key.

[henrjk]

We had a side conversation.

• Creating a new pipeline after deleting a pipeline run is most frequently done by adding a new empty commit to trigger the new pipeline. Because of the new commit the problem of an ever-red status can be considered unproblematic.
• The ever-red status for a commit could still happen when creating a new pipeline by creating a new branch with the same commit. However simply adding an empty commit can fix the issue here.

This PR will be helpful for distinguishing pipeline runs in umbrella repositories where the same commit triggers different builds depending on the (target) branch.

[henrjk]

LGTM: comment can help if users get confused by presentation of multiple build stati and also if they run into a case of ever-red status.