If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

support "release" events from Github

RESOLVED WORKSFORME

Status

Taskcluster
Github
RESOLVED WORKSFORME
2 years ago
9 months ago

People

(Reporter: bhearsum, Assigned: owlish)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
In the new Balrog CloudOps environment we'd like to be able to deploy based on tags, which means we want to build Docker images that are built and tagged whenever we create tags in the Balrog repository.

At the moment we're building and pushing images from "push" events and basing the tag names on the git branch names. This works OK, but lacks the same granularity (eg: what happens if we ask for the "master" image to be pushed, and then it changes before the push happens).
QA Contact: jwatkins → bstack
(Reporter)

Comment 1

9 months ago
We talked about this a bit today, and I discovered that only "create", "push", and "pull_request" events are enabled in the Mozilla-wide tc-gh webhook.

I've asked Hal to enabled "release" events there, and he'd like someone to confirm that tc-gh actually supports them. (My understanding is that tc-gh was reworked to stop hardcoding event names, but I could be wrong.)

Brian, can you weigh in?
Flags: needinfo?(bstack)

Comment 2

9 months ago
They should work, yes. owlish tried it out with her testing org and it appears to work!
Flags: needinfo?(bstack)
:hwine notes for own sanity that this automation is only building images, not deploying them.

release event has been added to the taskcluster webhook.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Component: Github → Github: Administration
Product: Taskcluster → mozilla.org
Resolution: --- → FIXED
Version: unspecified → other
(Assignee)

Comment 4

9 months ago
I think we aren't done with this quite yet. When the tags are created, three events are fired: release, push, create (in this sequence). Currently we don't handle release or create events; however, the push event that fires on tags and releases does trigger the tasks in TaskCluster. Status link to those tasks can be found on commits list (the link to tasks triggered by release's push replaces the link to tasks triggered by that (last) commit's push). I don't think there is a way in GitHub's UI to add status links to tags list; we probably need to handle that in TaskCluster's UI.

So, I think it's possible to add release/create event handlers. Maybe add some functionality to TaskCluster UI... Ben, we need some more detail from you, which functionality exactly would you like to see for the releases.
Status: RESOLVED → REOPENED
Flags: needinfo?(bhearsum)
Resolution: FIXED → ---
(Reporter)

Comment 5

9 months ago
(In reply to Irene S [:owlish] from comment #4)
> I think we aren't done with this quite yet. When the tags are created, three
> events are fired: release, push, create (in this sequence). Currently we
> don't handle release or create events; however, the push event that fires on
> tags and releases does trigger the tasks in TaskCluster. Status link to
> those tasks can be found on commits list (the link to tasks triggered by
> release's push replaces the link to tasks triggered by that (last) commit's
> push). I don't think there is a way in GitHub's UI to add status links to
> tags list; we probably need to handle that in TaskCluster's UI.
> 
> So, I think it's possible to add release/create event handlers. Maybe add
> some functionality to TaskCluster UI... Ben, we need some more detail from
> you, which functionality exactly would you like to see for the releases.

Thanks for digging into this more, Irene.

For my use case, it's important to be able to restrict certain Tasks to only happen on create or release events. So, simply supporting one or both of those would be enough. I'm not sure what to do about the UI. It doesn't seem great to put the links onto the commits, because they can be confused with "push" events for the same commit, but it's probably better than nothing. For my use case, I can live without any UI integration for these events, and rely on routes, indexes, and maybe e-mail to make the Tasks discoverable.
Flags: needinfo?(bhearsum)
(Assignee)

Comment 6

9 months ago
Thank you Ben!

> For my use case, it's important to be able to restrict certain Tasks 
> to only happen on create or release events.

Which tasks are those?

We'll think about UI. Email notifications are an option too.
(Reporter)

Comment 7

9 months ago
(In reply to Irene S [:owlish] from comment #6)
> Thank you Ben!
> 
> > For my use case, it's important to be able to restrict certain Tasks 
> > to only happen on create or release events.
> 
> Which tasks are those?

Balrog has two Tasks that build and publish Docker images. We'd prefer this only happens on Releases, not on every commit to master.
My bad - I moved the bug to github admin thinking it was only that. Moving back to TaskCluster
Component: Github: Administration → Github
Product: mozilla.org → Taskcluster
Version: other → unspecified
Assignee: nobody → bugzeeeeee
(Assignee)

Updated

9 months ago
Status: REOPENED → RESOLVED
Last Resolved: 9 months ago9 months ago
Resolution: --- → WORKSFORME
Created attachment 8823220 [details] [review]
Github PR #88 for taskcluster-github
You need to log in before you can comment on or make changes to this bug.