Trigger test tasks selected by bugbug and publish test results on Phabricator

[marco-c]

No description provided.

[marco-c]

Pre-requisites:

• Send the revision too along with the Treeherder URL when a try push is done libmozevent#18
• https://bugzilla.mozilla.org/show_bug.cgi?id=1599236
• Support listening on multiple queues and routes on the same pulse connection libmozevent#19
• https://bugzilla.mozilla.org/show_bug.cgi?id=1599423
• Support connecting to an AMQP virtual host  libmozevent#22
• build(deps): bump libmozevent from 1.0.5 to 1.0.6 in /events #275
• Split public facing tasks from worker tasks on heroku #269

[La0]

I'm not happy with the current situation where we put more & more stuff in code-review events, at the risk of breaking the relative stability we have acquired.

One solution i would like to try, is to put the code in there, but not execute everything on the same instance.
We now have multiple dynos running in production: 1 web dyno + N worker dyno. That works because the web dyno is the only one queueing in the build queue. But adding pulse listeners on every workers would be bad.

So we should add feature flags to activate web+pulse queuing on the web dyno and heavy lifting on worker dynos. On dev you could have everything running at once.

[La0]

Let's not forget to remove those

[marco-c]

Why? This was the one change that reduced the risk of new bugs to 0!

[La0]

🥁

[La0]

Why don't we have a separate instance of events for this stuff already ?

[marco-c]

As discussed on IRC, a good middle ground is having it as a separate async task communicating with the main workflow using queues.

[La0]

Let's 🚢 the damn thing !

[marco-c]

Let's ship the damn thing !

\o/