include revisions + commit messages in taskcluster try emails
Categories
(Firefox Build System :: Task Configuration, enhancement)
Tracking
(Not tracked)
People
(Reporter: froydnj, Unassigned)
References
Details
This was a great feature in the previous, buildbot-based try infrastructure and I was very sad to see it go. It does not look particularly complicated to add; we're already hitting $REPO/json-pushes to get pushlog info, but we're only asking for the data at tip, rather than all the commits involved in the push. So we'd just need to flip the tipsonly flag...but I don't know how expensive it would be to gather that extra data.
Comment 1•7 years ago
|
||
I'm not sure if this would happen in the hg-hook task, or in the decision task?
| Reporter | ||
Comment 2•7 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #1)
I'm not sure if this would happen in the hg-hook task, or in the decision task?
My limited understanding of this is that we'd do this in the decision task, since that appears to be where we fetch hg revision info:
https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/cron/decision.py#46
?
Comment 3•7 years ago
|
||
Got it -- in that case, we'd need to use the tc-notify API directly to send the notice, rather than using the notify.* routes in the decision task's task.routes (since the task.routes is already determined when the decision task starts).
| Reporter | ||
Comment 4•7 years ago
|
||
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #3)
Got it -- in that case, we'd need to use the tc-notify API directly to send the notice, rather than using the
notify.*routes in the decision task'stask.routes(since thetask.routesis already determined when the decision task starts).
My (again) limited understanding of this is that this already happens:
https://searchfox.org/mozilla-central/source/.taskcluster.yml#292
so we'd just need to provide (appropriately-formatted?) commit information for the jsone renderer?
Comment 5•7 years ago
|
||
The problem is, the order things happen is:
.taskcluster.ymlis loaded by the hg-push task and rendered with JSON-e- the result is passed to queue.createTask
- the resulting task is the decision task
So the decision task runs too late to influence its own creation :)
So I think there are two potential fixes here:
- modify the hg-push task to fetch the description and include it in the context to render
.taskcluster.yml; or - modify the decision task to use the
notify.email(..)API method directly, instead of relying on task.routes
I'd prefer the latter, as it keeps the hg-push task simple (it's fairly hard to modify and can't be tested in try, so the simpler the better). The latter fix can be tested in try :)
| Reporter | ||
Comment 6•7 years ago
|
||
Where are the routes coming into play here? I'm confused why sending the email currently appears to be done via .taskcluster.yml, but adding this extra information--which AFAICT is obtainable at the time we are setting up the context for rendering .taskcluster.yml--suddenly requires sending the email from a different place?
Comment 7•7 years ago
|
||
(In reply to Nathan Froyd [:froydnj] from comment #6)
which AFAICT is obtainable at the time we are setting up the context for rendering
.taskcluster.yml-
The code that sets up the context for rendering .taskcluster.yml is deliberately simple and does not currently have access
to the commit messages. The code that creates the context is here, and the information that gets passed to it is:
{
"_meta": {
"exchange": "exchange/hgpushes/v2",
"routing_key": "try-comm-central",
"sent": "2019-05-07T03:29:11.331159",
"serializer": "json"
},
"payload": {
"data": {
"heads": [
"9da1d2ea0d9562e34131c6df97e41cc59728a168"
],
"pushlog_pushes": [
{
"push_full_json_url": "https://hg.mozilla.org/try-comm-central/json-pushes?version=2&full=1&startID=8402&endID=8403",
"push_json_url": "https://hg.mozilla.org/try-comm-central/json-pushes?version=2&startID=8402&endID=8403",
"pushid": 8403,
"time": 1557199739,
"user": "<....>"
}
],
"repo_url": "https://hg.mozilla.org/try-comm-central",
"source": "serve"
},
"type": "changegroup.1"
}
}
I agree with dustin that we should keep this code as simple as possible and am reluctant to make it start fetching the commit messages.
(In reply to Dustin J. Mitchell [:dustin] pronoun: he from comment #5)
So I think there are two potential fixes here:
A third option is to add a new task to the graph that does this (similar to this one).
| Reporter | ||
Comment 8•7 years ago
|
||
Thanks for the explanation and bearing with me; I see now that I was quite confused about what context was in use.
Updated•3 years ago
|
Description
•