I’m running the latest drone docker connected to bitbucket server and am trying to set up our first pipeline to investigate a move from jenkins to drone for some projects.
If i have a step conditional to a branch, this step is run when opening a pull request targetting this branch (branch name evaluates to target branch). This is great when opening pull requests from feature branches to the development branch as the conditional step with additional tests is run.
Unfortunately if this additional step fails, and the pull request is updated with new commits, only the normal pipeline on the branch is run, not the ‘pull request’ pipeline. So there is no way to know whether the issues has been fixed or not without deleting the pull request in bitbucket and creating a new one.
Beside that i’m really happy with my first tests on drone.io !
Unfortunately if this additional step fails, and the pull request is updated with new commits, only the normal pipeline on the branch is run, not the ‘pull request’ pipeline
Unfortunately this is a problem with bitbucket server, which only sends a webhook when the pull request is opened. When you push to a branch with an open pull request it sends a branch webhook; it does not send a pull request synchronization webhook which is how other systems like github or gitlab behave.
Atlassian has an existing Jira ticket open for this issue. I recommend voting on the issue, or contacting your customer support representative to let them know you want this feature. See https://jira.atlassian.com/browse/BSERV-10279
Thanks for the quick answer. So yes i’ll vote and comment on jira’s issue.
Little update: BitBucket Server 7.0 (and DataCenter) introduces a new webhook when a PR source has been updated. Unfortunately no webhook if the target gets updated.
Maybe this can be used by drone ?
Yes, the Jira ticket was updated to indicate this new webhook is the fix. The next step would be to update the go-scm code and unit tests to process the new webhook type.
I will add this to our roadmap but I do not have an estimated delivery date for this feature. With that being said we can definitely help expedite any pull requests that are submitted.
I’m also running into that problem. Maybe some fixes are planned in the nearest time?