RFC 0196 - Trigger hooks from Github Service

[ahal]

Rendered

[lotas]

Thank you @ahal, that's a solid proposal.

As I understand we don't limit the number of hooks we could trigger here, same way as we didn't limit number of tasks created.
And as I understand a possible use case would be to create hooks dedicated to various events that would check the payload and decide which set of tasks needs to be created? (checking github event and action)
If that's the case, I wonder if we could also include filtering on the .taskcluster.yml side to fire some hooks only for specific github events?

But I guess this might not be the desired flow

[ahal]

So we need to filter on more than just the Github event type and action. Off the top of my head, we also filter on branch name and repo URL, but there are probably others.

Currently we use the JSON-e in the tasks key to do this filtering. We setup the logic such that an empty list is returned, and then TC Github just does nothing (no errors, no tasks). I think we'd want to do the same here, e.g do the filtering in the hook's JSON-e template.

From the docs:

If the task template renders to null, no task is created.

This gives us more control over where tasks can run.

I'm not opposed to TC Github also providing a way to do some basic filtering, I just don't think it would benefit our specific use case much. Unless it's trivial to do, I'd suggest leaving it out of this RFC to keep things simple. We can always implement later if needed.

[ahal]

Added a blurb to the "Edge Cases" section about what to do if the triggerHook call doesn't create any tasks.

[ahal]

I'm not opposed to TC Github also providing a way to do some basic filtering, I just don't think it would benefit our specific use case much. Unless it's trivial to do, I'd suggest leaving it out of this RFC to keep things simple. We can always implement later if needed.

Though thinking about it.. without any GH service side filtering, we would have a lot of triggerHook calls that render null tasks. One per Github check suite event. This isn't necessarily a problem, but it might be nice to reduce load on the hook service and make it easier to browse the hooks page in the UI.

I dunno, I could be persuaded either way.

[lotas]

Though thinking about it.. without any GH service side filtering, we would have a lot of triggerHook calls that render null tasks. One per Github check suite event. This isn't necessarily a problem, but it might be nice to reduce load on the hook service and make it easier to browse the hooks page in the UI.

Right, this might a good reason to not trigger a hook knowing it would be competing with valid tasks in the dedicated worker pools.

I quickly checked logs

jsonPayload.serviceContext.service="github"
jsonPayload.Fields.message=~"compiled with zero tasks"

Gives me ~9k for the last 2 weeks (most of which are web-platform-tests ~5k of those) So maybe in the grand scheme that is not too many tasks

[petemoore]

Looks great, just some nits, thanks Andrew!

[petemoore]

Thanks Andrew!

[ahal]

As far as filtering goes, I propose we leave it out of the initial RFC. I don't think it's necessary for fxci's use case and we can always add it as a feature later on if it turns out I'm wrong or someone else requests it.

[matt-boris]

👍🏻