Enhance ruleset event support

[NaromKuoch]

Description

• Proposing adding a support for additional event in ruleset.
• For example, there are no support when editing an existing PR.

Scenario:
By default when opening a PR it'll target our default branch (main) and if somebody is aiming to cherry-pick their PR into the release branch they'll edit the PR to retarget the new base branch. In this case, there is no build that gets triggered because Vela only supports few events including pull_request, commnent, tags, push, etc.

What I would be imagining is that anything that is "action": "edited" triggers a rebuild.

Value

This is important because in the worst scenarios, the stale-ness of the checks means that bad commits make it into the repo based on some merge commit from a branch other than what it would move into.

Definition of Done

• The expected results is when editing existing PR, the user has an ability to configure Vela so that build can get triggered.
• Documentations needs to be edited for additional events to support.

Effort (Optional)

Impacted Personas (Optional)

[wass3r]

I have a use-case for this as well. For pull request alone there are a number of (sub) events we could support.

refs:

• https://docs.github.com/en/free-pro-team@latest/developers/webhooks-and-events/github-event-types#pullrequestevent
• https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#pull_request

[NaromKuoch]

Adding an additional request for PR approval event.
There is a use-case where we would like to trigger a build when PR is approved.

refs:

• https://docs.github.com/en/developers/webhooks-and-events/github-event-types#pullrequestreviewevent

[susangreve]

• Support label events

[ecrupper]

Given some of the feedback on the initial types PR, I think it would be a good idea to discuss overall implementation of this feature in greater depth.

YAML Ideas

With the inclusion of more events, many of them sub-events, we have to consider how this will affect the pipeline writing for our end users. I have a few markups for how this might work, which hopefully will generate some discussion as to which direction we want to take.

Mark Up 1 (putting sub-events on same level as normal events)

steps:
    - name: original behavior
      ruleset:
          event: [push, pull_request]
    
    - name: original behavior using sub-events
      ruleset:
          event: [push, pr_open, pr_commit]

    - name: example customized event set
      ruleset:
          event: [push, pr_edit, pr_label]
          label: bug

Mark Up 2 (scoping sub-events of PRs)

steps:
    - name: original behavior using scoping
      ruleset:
          event: [push, pull_request:open, pull_request:commit]

    - name: example customized event set
      ruleset:
          event: [push, pull_request:edit, pull_request:label]
          label: bug

Mark Up 3 (unrolling events array into a YAML structure like steps)

steps:
    - name: original behavior using yaml structuring
      ruleset:
          events: 
              - type: push
              - type: pull_request
                actions: [open, commit]

    - name: example customized event set
      ruleset:
          events:
              - type: push
              - type: pull_request
                actions: [edit, label]
                label: bug

[GregoryDosh]

My personal preference is towards option 2 as it seems to look and act more like OAuth Scopes within GitHub. It (at a glance) seems like it might make the migration path easiest for users as their existing pull_request event will be the highest level category but for finer grained control users can only look for specific sub-events.

[kneal]

I think I personally lean towards option two as well. Largely because I think it would be the easiest for us to implement with causing to much headache on the user front.

I do really like the verbosity of three but I'm not just not sure the way all that YAML parsing would work it would be super easy to implement.

Yeah, the oauth scopes in GitHub do draw a nice similarity. Sadly, I don't think all users can benefit seeing as a Vela installation might not run against GitHub.

Is the plan with this to tackle more than just Pull Request additions? I see label, comment and some others listed in the issue.

[jbrockopp]

I think option 2 is the one I'd like to see us use for Vela in the future.. but I'm not sure it's the right approach currently.

In order to maintain the precedent and standards already set forth for a ruleset, I think we should use option 3.

Again, I think option 2 is likely the best candidate and we should strongly consider it for a version: "2" implementation.

But, option 3 fits with the current patterns we've established and I'll provide some examples:

ruleset:
  event: [ comment ]
  comment: [ <myComment> ]

ruleset:
  event: [ deployment ]
  target: [ <myDeployTarget> ]

ruleset:
  event: [ tag ]
  tag: [ <myTag> ]

The pattern here is the ruleset defines what event you want Vela to execute the step for.

And if further customization beyond the event is needed, additional fields are used for the use-case.

i.e. what comment I want Vela to run the step for, what deployment target I want Vela to run the step for etc.

I think most, if not all, would agree the pattern we have today does leave room for opportunity.

However, it is a pattern already established so we should be mindful about deviating from it.

How I see this working with the current pattern we have today would look like:

ruleset:
  event: [ pull_request ]
  action: [ <myPRAction> ]

ruleset:
  event: [ pull_request ]
  label: [ <myPRLabel> ]

Depending on the level of support we want for label, the last one may need to turn into:

ruleset:
  event: [ label ]
  label: [ <myPRLabel> ]

I say this because IIRC, we had to introduce the comment event since it can come from other sources beyond a PR.

I believe that's why we have a separate story written for adding support for labels:

#24

[ecrupper]

With the release of v0.23.0, we have included pull_request:edited, delete:branch, and delete:tag as new events. These additions were brought on with the changes to allow events.

While not all events mentioned here are covered with this release, I am closing this issue in favor of multiple specific requests for webhook events: PR Label and PR Review Submission to get us started.