Support For Github Event 'Closed' on Issues

Drone Support
1

I’d like to propose an update the events listened on, adding the ‘closed’ event for github issues (Github lists PRs as issues).

After talking with Jacob McCann, he thought it would be a good idea for me to raise the question here. I would like to know firstly if the drone maintainers would find it useful. And secondly I’d like to explain why its valuable to me.

Currently I am maintaining a server that does ephemeral builds on Kubernetes for a pull request. This has a multitude of benefits including, but not limited to: being able to test code in an integrated environment prior to merge, per-performance tests, cpu profiling of PRs, automated functional tests being run, etc. I would like to remove the dependency of hosting a server, and create a Drone plugin instead.

Right now Drone can facilitate everything I would need by providing the pull_request and push events. I can conveniently create and update an ‘ephemeral environment’. However, the problem is with cleaning up. If I’m unaware of the pull request closing, I’d be hard pressed to identify when to clean up the then stale environment. In this use case, I don’t believe a CRON-like set up would be sufficient.

Personally, I’m unaware of the effort it would take to implement this in Drone Core, but I would be delighted to hear your feedback, and if this is a viable option.

Thanks for taking the time to read over this!

2

I think it makes sense. It would need a formal proposal and we would need to make sure the implementation was not GitHub specific, meaning that it could be extended to Bitbucket, GitLab and Gogs. I think the appropriate event type here would be the pull_request where the action == closed. It would not be possible to use issue hooks because we need to make sure the hook is tied to a commit sha.

3

Hey Brad, thanks for responding so quickly!

You are correct, we wouldn’t need to do issues. I was associating issues with PRs due to an out of date api I was using, sorry about that.

The reference for PR close event in github is here.

Gitlab covers them all in on merged event.

(Bitbucket and Gogs to follow up in another comment. The post restricted me to “two links for new users”).

To confirm what you are saying, your proposal would be something like:

my-build-step:
  when:
    event:
      - pull_request: 
          action: closed

Are there any docs on formal proposals? I could write them up if you wish, up to you.

4

For bitbucket, it would make sense to clean up if the PR is merged or declined. That reference is here, merged, declined.

5

Gogs webhook documentation is lacking. But it looks like they have all the information needed for the event. I’ve not used this service before, so I’m unaware of the possibilities.

6

Thanks for the research. I’ve extrapolated on your post to provide some more technical details. I think the change is pretty straightforward, but there is one remaining design issue discussed below, which will be required to prevent negative impacts to existing Drone users.

Database Changes

First step will be to decide how we want to represent and store this data in our Go code and in our database. We will need to store the action type, as you pointed out above.

create table builds (
---
+build_action TEXT
---
);

I would suggest that action values for pull requests should be the following:

enum {
  open,
  merged,
  declined,
  synchronized,
}

The GitHub closed type would be converted to either merged or declined. I think in this case it is better to adopt the Bitbucket semantics so that we can store this information in a single field, as opposed to the GitHub approach which uses two fields (action string, merged bool).

Yaml Changes

I like the yaml syntax proposed above. I would probably slightly alter to support the below variations. Note that we have many of the required structures in place that we should be able to re-use, so supporting flexible configurations should not be am implementation issue.

when:
  event: [ pull_request ]

when:
  event:
    pull_request: merged

when:
  event:
    pull_request: [ merged, declined ]

when:
  event:
    pull_request:
      includes: merged
      excludes: declined

when:
  event:
    pull_request:
      includes: [ merged, synchronized ]
      excludes: declined

Avoid Breaking Changes

If we started automatically triggering builds for all pull request actions it would probably cause a problem for existing configurations. They will not be expecting builds for merged or declined events, and will not have their yaml files configured with the appropriate when conditions to prevent this.

So to avoid breaking existing pipelines, this should probably be disabled by default. Similar to how we disable tags and deployment events by default. This will require some addition technical design. I’m not sure the best approach at this time …

This remains an outstanding item

MVP Implementation

I think an initial implementation would need to include the following:

  1. github implementation
  2. database changes
  3. yaml changes
  4. strategy for not breaking existing projects
7

I just realized there was an existing issue for this. Let’s move the conversation to this thread https://github.com/drone/drone/issues/1878

8

is there any solution for this. I am also facing a similar situation where i want to trigger my pipeline on closing a PR!!!

9

Hello Faizan,

Drone does not support pull request closed events. We may add support for additional event types in the future, but cant provide an ETA.

Regards,
Harness Support