./mach try fuzzy with `rebuild` argument fails the decision task
Categories
(Firefox Build System :: Task Configuration, defect)
Tracking
(firefox-esr68 unaffected, firefox-esr78 unaffected, firefox79 unaffected, firefox80 fixed, firefox81 fixed)
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox79 | --- | unaffected |
firefox80 | --- | fixed |
firefox81 | --- | fixed |
People
(Reporter: jdescottes, Assigned: ahal)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Today, everytime I pushed to try
with a rebuild parameter, the decision task failed. Examples:
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=79cbd882debd20ee5d27a393d2007588cdf1c80a
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=6902bc16a3598905598e39e277efae597648effe
- https://treeherder.mozilla.org/#/jobs?repo=try&revision=544aac04d6e6e1f4384be55bb698ac7b207161c4
The error always looks like requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: http://taskcluster/queue/v1/task/b'VkYX54-KTLa_V2ZNgcTOGw'
Looking at the logs, taskIds seem to be slightly incorrect:
[task 2020-07-27T14:29:02.065Z] Creating task with taskId b'YUvmHlcwTIei2JRlekHRdA' for test-linux64-shippable/opt-talos-damp-e10s
[task 2020-07-27T14:29:02.067Z] Creating task with taskId b'X8rj3PZpRMOlOnxqpH5U-g' for test-linux64-shippable/opt-talos-damp-e10s
[task 2020-07-27T14:29:02.071Z] Creating task with taskId b'VkYX54-KTLa_V2ZNgcTOGw' for test-linux64-shippable/opt-talos-damp-e10s
[task 2020-07-27T14:29:02.072Z] Creating task with taskId b'Tv0A1iqERS-mnY0d6_eFag' for test-linux64-shippable/opt-talos-damp-e10s
[task 2020-07-27T14:29:02.075Z] Creating task with taskId b'WroiXjNTQiec9b1Axd1E5A' for test-linux64-shippable/opt-talos-damp-e10s
See b'
before each task id. The way this prefix is handled seems to change between python 2 and python 3. Could it be linked to https://bugzilla.mozilla.org/show_bug.cgi?id=1638990 ?
Reporter | ||
Comment 1•4 years ago
|
||
Just confirmed the regression, this was caused by https://hg.mozilla.org/integration/autoland/rev/5ce5c63b496c.
Push on 5ce5c63b496c https://treeherder.mozilla.org/#/jobs?repo=try&revision=7a7682fab544e77d5953634614c656a51be7b091
Push on previous changeset : https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d266d867cc3ea0592c8a025b0d28aaab2e907d8
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
Looks like an instance of slugid
was missed for decoding:
https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/create.py#92
Assignee | ||
Comment 3•4 years ago
|
||
Updated•4 years ago
|
Pushed by ahalberstadt@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/81dfb9fe9a70 [taskgraph] Decode slugid to text in create_task, r=tomprince
Comment 5•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Set release status flags based on info from the regressing bug 1638990
Comment 8•4 years ago
|
||
The patch landed in nightly and beta is affected.
:ahal, is this bug important enough to require an uplift?
If not please set status_beta
to wontfix
.
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 9•4 years ago
•
|
||
I don't think it's super important to land on beta, though I know Tom often likes to uplift stuff like this. Unsure of the process if we want to take it, is a=test-only
still a thing?
Comment 10•4 years ago
|
||
bugherder uplift |
Description
•