search

teameh / bitrise-step-bitbucket-server-post-build-status

MIT License
3 stars 8 forks source link

Aborted builds can't send a status to update the pull request #6

Closed RtgrV closed 4 months ago

RtgrV commented 2 years ago

Since the new integration of the multiple build statuses on a Pull Request, a new issue was found on our workflows.

Once a build gets aborted, it is unable to send any notification to the Bitbucket server to update the status. Meaning that on the next run the build gets a new build number and is unable to post and update the previous build status. Stacking up builds with in-progress statuses.

Proposed solution To fix it, I would like to suggest making the key customizable. By default, it would be "Bitrise" and if you have one or more separate workflows you can give them ur own identifier.

teameh commented 2 years ago

Thanks @RtgrV. This is indeed undesired behaviour. I'll look into it.

teameh commented 2 years ago

Hey @RtgrV could you check if this works for you ? https://github.com/teameh/bitrise-step-bitbucket-server-post-build-status/pull/7

You should be able to try this version by editing your bitrise.yml file directly in the web editor on bitrise.io:

Instead of 

    - bitrise-step-bitbucket-server-post-build-status@0.0:
        inputs: ...

You would use:

    - git::https://github.com/teameh/bitrise-step-bitbucket-server-post-build-status.git@key_based_on_workflow:
        inputs:

Does that work?

lawmaestro commented 2 years ago

@teameh We've been experiencing similar issues. We have a merge check in place which enforces at least 1 successful build before a PR can be merged. In the event the build is aborted or fails, a successful re-run against the same commit was not clearing this merge rule.

I've tried with your patched version and that resolves this particular issue for us. It does however appear to flatten the build history in Bitbucket. So the build list will now only ever show 1 build, even if there's been several performed against different commits. Was that the intended behaviour?

If I understand the problem correctly (and there's a pretty helpful article on it [here])(https://confluence.atlassian.com/bitbucketserverkb/commit-build-status-is-always-red-even-if-other-builds-succeed-779171240.html) if the build key were a combination of the workflow id and the commit hash then we'd keep the support for multiple builds results whilst also being able to update existing results with a re-run against the same commit would we not?

esteluk commented 2 years ago

Having a combination of triggered_workflow_id and git_clone_commit_hash sounds good to me. I don't think the key is ever user facing, so we could send whichever value we like?

As far as I can see, Bitrise has no environment variable that will tie together multiple retries of a single commit.

Buju77 commented 2 years ago

@esteluk @lawmaestro We also faced same issue unable to re-run to get rid of failed build status.

Here is the change I did to fix it for us. I've also added more code docu to explain it a bit more:

https://github.com/teameh/bitrise-step-bitbucket-server-post-build-status/pull/8/files

And about the combination of triggered_workflow_id and git_clone_commit_hash: IIRC the build_url already has the commit hash in it. So that plus a consistent key value makes it possible to re-run a failed build.

teameh commented 4 months ago

https://github.com/teameh/bitrise-step-bitbucket-server-post-build-status/pull/8/files got merged. Closing this issue