At the moment the Bitbucket build status key is simple the Git commit SHA. This isn't very helpful, as multiple pipeline runs (e.g. for different branches) all update the same build status key. It would likely be better to have multiple build status keys. For example, the same commit may be deployed into DEV, QA and PROD. In this case, it would be nice to have build status + a link for each pipeline run in Bitbucket.
The question is what the build status key should be composed of. Using the pipeline run name itself would be one option, but it would prevent updating the build status when there is a sporadic failure. We could explore fine-tuning this so that re-runs of the same pipeline update the original build status. It seems that re-runs are annotated with pipeline.openshift.io/preferredName which has the value set to the original pipeline run.
Another option would be to assemble the key based on e.g. branch, tag, PR, PR comment? A benefit of this may be that it may be easier to navigate. But likely a bit harder to know what exactly to include.
At the moment the Bitbucket build status key is simple the Git commit SHA. This isn't very helpful, as multiple pipeline runs (e.g. for different branches) all update the same build status key. It would likely be better to have multiple build status keys. For example, the same commit may be deployed into DEV, QA and PROD. In this case, it would be nice to have build status + a link for each pipeline run in Bitbucket.
The question is what the build status key should be composed of. Using the pipeline run name itself would be one option, but it would prevent updating the build status when there is a sporadic failure. We could explore fine-tuning this so that re-runs of the same pipeline update the original build status. It seems that re-runs are annotated with
pipeline.openshift.io/preferredNamewhich has the value set to the original pipeline run.Another option would be to assemble the key based on e.g. branch, tag, PR, PR comment? A benefit of this may be that it may be easier to navigate. But likely a bit harder to know what exactly to include.
I am leaning towards using the pipeline run name.
Thoughts @henrjk?