I’ve been having an issue regarding the triggering of a pipeline on different merge request actions with our self-hosted GitLab instance.
With the following testing pipeline (which I am using to debug this issue), I see builds starting succesfully on opened and synchronized.
name: debugging drone PR triggers
- name: example
- echo $DRONE_PULL_REQUEST
- echo $DRONE_BUILD_ACTION
But for some reason all other actions fail (merged and closed are those which I really need), no builds get started on these actions.
When I look at the webhook statuses in GitLab itself, I see the webhooks being sent, but I get an empty response from Drone (status code 204).
When looking at the logs of drone, I see no errors appearing.
I do see that these actions are implemented in go-scm, so am I missing something here?
Thanks in advance!
Drone only supports opened and synchronized actions for pull request events; all other actions are ignored.
Thanks for the quick reply.
Is there a reason why they are ignored? Or is this something that might come in the future?
When we created Drone back in 2012 we drew inspiration from Travis and Circle (and a few other modern CI systems), none of which triggered pipelines for pull request merged or closed events. There was no prior art to suggest people would want this behavior, and even today, it is rarely requested. The reason we have not added support for additional actions is because it would caused problems for our existing userbase, which is quite large, and would violate our commitment to not introducing breaking changes.
Here is a comment I left on another thread related to this topic
If we started automatically triggering builds for all pull request actions it would cause a problem for existing configurations. They will not be expecting builds for
declined events, and will not have their yaml files configured with the appropriate when conditions to prevent this.
Alright, I can see why you wouldn’t implement it.
Our use-case would be to delete a deployment of some application specifically for that branch.
Adding these actions with a feature flag is maybe a bit overkill for just our use case
I’ll look into another solution, thanks for the clear answer.
FWIW if I were re-designing Drone from scratch today I would support all event types and actions. It is possible we could consider supporting additional event types and actions in the next major, breaking release of Drone, which would be Drone 3. Disclaimer that we are still focused on Drone 2 and have not started thinking about Drone 3 yet, so I don’t have a timeline I can provide.