1490515 - Send "Thank you for your try submission. It's the best!" from somewhere other than buildbot.

Status: RESOLVED FIXED

(Release Engineering :: General, enhancement)

Description

[Tom Prince [:tomprince]]

These used to be sent by buildbot. Now that it is decommissioned, these emails are not getting sent anymore.

Comment 1

[Bogdan Crisan [:bcrisan] (EEST - GMT + 3)]

Where does this message appear and from what buildbot-master was send?

Comment 2

[Chris AtLee [:catlee]]

I think this should probably live in hg.m.o somewhere.

Comment 3

[Chris AtLee [:catlee]]

The current logic is here:
https://hg.mozilla.org/build/buildbotcustom/file/tip/status/generators.py#l4

Comment 4

[Justin Wood (:Callek)]

I can imagine logic could live in a file like:

https://dxr.mozilla.org/hgcustom_version-control-tools/source/hghooks/mozhghooks/try_warning.py

If done there (for hg.m.o) sheehan or gps would be great resources to talk to.

There is another option I've thought about overnight, which is using TC's notification system instead which would entail modifying the .taskcluster.yml (a bit delicate)

e.g. there is https://dxr.mozilla.org/mozilla-central/source/.taskcluster.yml#81

But we'd want it to be more useful for developers so we'd likely do something with the task.extra and such like we do for release notifications to populate the subject and message like:

https://dxr.mozilla.org/mozilla-central/source/taskcluster/taskgraph/transforms/release_notifications.py#26

That said, I do think hooking into hgcustom may be the better choice here...

Comment 7

[Connor Sheehan [:sheehan]]

hg.mozilla.org currently sends out Pulse and SNS notifications for most repo events, including try pushes. These notifications are tied into the replication system so that any consumer of these events only sees data that has already been replicated to the web heads. If the solution involves hg.mozilla.org, we will probably either want to a) create a new notification consumer and run a daemon to send emails when a relevant notification event comes through the queue or b) stand up a daemon somewhere outside of hg.mo that consumes the existing messages. The downside to this is that a push may come in and a developer receives a notification, but something causes the decision task to not be scheduled (long backlog in the queue, etc).

On the other hand, try pushes exist to schedule jobs in Taskcluster and, as Callek mentioned, Taskcluster already has tc-notify built in. We could use the Gecko decision task "completion" status as a hook to trigger tc-notify and tell developers their try push is being scheduled. At the moment we already have the "on-failed" and "on-exception" notification routes set, we could just switch to "on-any" and add a relevant subject/body to the task definition. A disadvantage to this is that whatever message we use will be sent for all possible task outcomes (completed, exception and failed). So the message will need to be more generic and less pleasant than "Thank you for your try submission. It's the best!".

Comment 8

[Gregory Szorc [:gps]]

I think the notification emails should come from the CI system (Taskcluster) not version control.

The reason is that the thing people care about - what the emails inform them about - is whether CI was triggered - not whether the VCS push was performed. In most cases, people already know a VCS push was performed because they likely triggered it! What they don't know is whether that push resulted in CI getting triggered.

Expanding a bit, I think the notification email should come from the *result* of the decision/scheduling task. As an end-user, an email saying the decision task was scheduled doesn't tell me much: that task could fail or succeed. I do care whether the work I thought I scheduled was actually scheduled. I especially care if there was an error. (But I'm pretty sure we already send emails on decision task failure.)

Comment 9

[Masatoshi Kimura [:emk]]

Because of bug 1490967 (not pushed to production yet) and this bug, I'm almost impossible to find my try jobs if I forget to copy the revision id from the terminal. Really frustrating.

Comment 10

[Connor Sheehan [:sheehan]]

Attachment: Bug 1490515: add "on-completed" notify route to try push decision tasks r?tomprince,gps

Buildbot had a feature where a notification email would be sent to
the user who triggered the build jobs once Buildbot had begun
processing the request. Since we have migrated off Buildbot, we
have lost this much-appreciated functionality. Taskcluster
allows us to send emails when a task fails, raises an exception
or completes successfully. We already send notification emails
out for the first two cases, sending an email on completion of
the Gecko decision task would essentially replicate the Buildbot
functionality. This commit removes the `on-fail` and `on-exception`
notify routes and adds the `on-any` route, which will give us the
same behaviour as before plus send a notification email when the
decision task completes.

Comment 11

[Tom Prince [:tomprince]]

Comment on attachment 9010237 [details]
Bug 1490515: add "on-completed" notify route to try push decision tasks r?tomprince,gps

Tom Prince [:tomprince] has approved the revision.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/863ee0115b82
add "on-completed" notify route to try push decision tasks r=tomprince

Comment 13

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/863ee0115b82

Comment 14

[Tom Prince [:tomprince]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/38ed9883772e