Closed Bug 1642004 Opened 4 months ago Closed 3 months ago

`-p all` try syntax selects shippable builds instead of opt

Categories

(Firefox Build System :: Task Configuration, task)

task

Tracking

(firefox79 fixed)

RESOLVED FIXED
mozilla79
Tracking Status
firefox79 --- fixed

People

(Reporter: bhearsum, Assigned: bhearsum)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ci-costs-2020:done])

Attachments

(2 files)

Whiteboard: [ci-costs-2020:todo]
Assignee: nobody → bhearsum

Not sure if I should file a new bug, but relatedly, pushing -p macosx64 -b o creates both an opt and a shippable.

(In reply to Mike Hommey [:glandium] from comment #2)

Not sure if I should file a new bug, but relatedly, pushing -p macosx64 -b o creates both an opt and a shippable.

I'll take that as a follow-up here.

(In reply to Mike Hommey [:glandium] from comment #2)

Not sure if I should file a new bug, but relatedly, pushing -p macosx64 -b o creates both an opt and a shippable.

So, shippable gets created because -t defaults to all, which includes a bunch of perf tests - so that's expected (or at least explainable).

I'm actually not certain why the opt build is there, as there's nothing downstream of it. It's possible this is because of https://bugzilla.mozilla.org/show_bug.cgi?id=1641058, but I don't think so. Going to keep digging on this.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #4)

I'm actually not certain why the opt build is there, as there's nothing downstream of it. It's possible this is because of https://bugzilla.mozilla.org/show_bug.cgi?id=1641058, but I don't think so. Going to keep digging on this.

Alright, so this boils down to the fact that opt now refers to two different build types, and try syntax doesn't distinguish between them (https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/try_option_syntax.py#19). We end up returning at https://searchfox.org/mozilla-central/rev/0e09b9191c02097034e46b193930f91c45b7885d/taskcluster/taskgraph/try_option_syntax.py#651 for this case.

One possible fix would be to add a new build type alias (s for shippable). This would let us distinguish between them, and also has the advantage of the current developer behaviour using the faster opt builds (shippable builds would still be used when perf tests are selected, of course).

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #4)

(In reply to Mike Hommey [:glandium] from comment #2)

Not sure if I should file a new bug, but relatedly, pushing -p macosx64 -b o creates both an opt and a shippable.

So, shippable gets created because -t defaults to all, which includes a bunch of perf tests - so that's expected (or at least explainable).

I always use "-t none".

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #5)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #4)

I'm actually not certain why the opt build is there, as there's nothing downstream of it. It's possible this is because of https://bugzilla.mozilla.org/show_bug.cgi?id=1641058, but I don't think so. Going to keep digging on this.

Alright, so this boils down to the fact that opt now refers to two different build types, and try syntax doesn't distinguish between them (https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/try_option_syntax.py#19). We end up returning at https://searchfox.org/mozilla-central/rev/0e09b9191c02097034e46b193930f91c45b7885d/taskcluster/taskgraph/try_option_syntax.py#651 for this case.

One possible fix would be to add a new build type alias (s for shippable). This would let us distinguish between them, and also has the advantage of the current developer behaviour using the faster opt builds (shippable builds would still be used when perf tests are selected, of course).

After some further debugging I'm moving this out to https://bugzilla.mozilla.org/show_bug.cgi?id=1645265

(In reply to Mike Hommey [:glandium] from comment #6)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #4)

(In reply to Mike Hommey [:glandium] from comment #2)

Not sure if I should file a new bug, but relatedly, pushing -p macosx64 -b o creates both an opt and a shippable.

So, shippable gets created because -t defaults to all, which includes a bunch of perf tests - so that's expected (or at least explainable).

I always use "-t none".

Ah, I missed that. I think my analysis above was incomplete in any case -- my fix in the new bug should address it regardless of test/talos/raptor flags passed.

Pushed by bhearsum@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3363774ab1aa
`-p all` try syntax selects shippable builds instead of opt r=ahal
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla79

So... macosx shippable is still happening... and worse, the opt builds aren't. See e.g. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9a625799f5b9ca55d1dd77378a965b869f0ac58e (this is an old link because I forgot to submit this comment, but this is still happening, but I need to trigger the missing builds, so by the time you look, they will appear as if they had happened)

Flags: needinfo?(bhearsum)

(In reply to Mike Hommey [:glandium] from comment #10)

So... macosx shippable is still happening... and worse, the opt builds aren't. See e.g. https://treeherder.mozilla.org/#/jobs?repo=try&revision=9a625799f5b9ca55d1dd77378a965b869f0ac58e (this is an old link because I forgot to submit this comment, but this is still happening, but I need to trigger the missing builds, so by the time you look, they will appear as if they had happened)

https://phabricator.services.mozilla.com/D81182 is kindof a fix for this, but I'm not sure I want to land it. More details in phabricator.

Flags: needinfo?(bhearsum)
Whiteboard: [ci-costs-2020:todo] → [ci-costs-2020:done]

I realize there's still an issue with try syntax here, but fixing it is something I probably can't prioritize for awhile, especially given the relatively low syntax usage vs. chooser/auto/fuzzy (https://gist.github.com/ahal/ebfc230994799517166fc32a04da8884).

You need to log in before you can comment on or make changes to this bug.