Adjust for disabled opt builds in bug 1522111
Categories
(Testing :: mozregression, defect)
Tracking
(Not tracked)
People
(Reporter: nthomas, Assigned: Kwan)
References
Details
Attachments
(1 file)
49 bytes,
text/x-github-pull-request
|
Kwan
:
checked-in+
|
Details | Review |
Bug 1522111 disabled some opt builds on inbound and autoland, in favour of pgo. If mozregression supports bisecting into on-push builds on those branches it may need to make some changes.
Comment 1•6 years ago
|
||
From the code, I am fairly certain this should still work as expected. Is this change landed and ready for testing? i.e. if I bisect into inbound/autoland on March 3rd/4th, will I only get pgo builds?
Reporter | ||
Comment 2•6 years ago
|
||
Yes, I believe it's all landed. There's a slight regression in that linux64 opt builds are still running.
Comment 3•6 years ago
|
||
Try to bisect bug 1532110 and switching to pgo will be necessary.
Comment 4•6 years ago
|
||
Aryx, is mozregression not working for you? As far as I can tell from the source it should be able to fetch pgo builds from integration branches in its current form, at least on Windows and Linux. I think we might need to make it search for pgo builds on Mac though.
Comment 5•6 years ago
|
||
It's more about switching from default 'opt' to 'pgo' as default if available. Else it will work fine as long as one bisects on central but fail once it tries to switch to autoland.
Comment 6•6 years ago
|
||
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #5)
It's more about switching from default 'opt' to 'pgo' as default if available. Else it will work fine as long as one bisects on central but fail once it tries to switch to autoland.
My impression was that mozregression would actually search for builds of both types for every revision, at least if specified:
Is that not the case?
Comment 7•6 years ago
|
||
No, it will fail with messages similar to this:
WARNING : Skipping build 1bc807fb4c89: Unable to find build info using the taskcluster route 'gecko.v2.autoland.revision.1bc807fb4c895d326aafc4a5bc5c9239c093b432.firefox.win64-opt'
Comment 8•6 years ago
•
|
||
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #7)
No, it will fail with messages similar to this:
WARNING : Skipping build 1bc807fb4c89: Unable to find build info using the taskcluster route 'gecko.v2.autoland.revision.1bc807fb4c895d326aafc4a5bc5c9239c093b432.firefox.win64-opt'
Hi :coop, could someone on your team with taskcluster python client library experience help debug this? We really need mozregression to work for tracking down the root causes of bugs and not being able to bisect inbound/autoland is quite a deal-breaker.
The problem is probably either in taskcluster itself / the client library we're using (the copy used by mozregression is very out of date -- you can see an effort to update it here-- https://github.com/mozilla/mozregression/pull/513/commits/b962c5e23a07f55761106d3c7dee2e389446b080) or in the file I link to in comment 6. I am very happy to provide mozregression help/guidance/reviews as needed, either here or on irc/slack.
Comment 9•6 years ago
|
||
(In reply to William Lachance (:wlach) (use needinfo!) from comment #8)
The problem is probably either in taskcluster itself / the client library we're using (the copy used by mozregression is very out of date -- you can see an effort to update it here-- https://github.com/mozilla/mozregression/pull/513/commits/b962c5e23a07f55761106d3c7dee2e389446b080) or in the file I link to in comment 6. I am very happy to provide mozregression help/guidance/reviews as needed, either here or on irc/slack.
I've cc-ed Pete here for further guidance. Updating the client library here is a good first step.
Updated•6 years ago
|
Comment 10•6 years ago
•
|
||
https://tools.taskcluster.net/index/gecko.v2.autoland.revision.1bc807fb4c895d326aafc4a5bc5c9239c093b432.firefox.win64-opt doesn't exist. I'm guessing someone has changed which indexes we populate.
https://tools.taskcluster.net/index/gecko.v2.autoland.revision.1bc807fb4c895d326aafc4a5bc5c9239c093b432.firefox/win64-pgo does exist, though :Callek may be changing these when we move to shippable builds in bug 1352113. You can look at https://tools.taskcluster.net/index/gecko.v2.autoland.revision.1bc807fb4c895d326aafc4a5bc5c9239c093b432.firefox to see which platforms are indexed under that revision.
Does mozregression find the -pgo build? (Comment 7 says no)
Comment 11•6 years ago
|
||
(In reply to Aki Sasaki [:aki] from comment #10)
Does mozregression find the -pgo build? (Comment 7 says no)
I don't presently have a win64 environment to test this case, but that is my read of what :Aryx in comment 7, yes.
I never really had any doubt that the builds were being produced, my question is why isn't mozregression able to find them? As mentioned in comment 6, I thought it was configured to do so.
Comment 12•6 years ago
|
||
(In reply to William Lachance (:wlach) (use needinfo!) from comment #11)
(In reply to Aki Sasaki [:aki] from comment #10)
Does mozregression find the -pgo build? (Comment 7 says no)
I don't presently have a win64 environment to test this case, but that is my read of what :Aryx in comment 7, yes.
I never really had any doubt that the builds were being produced, my question is why isn't mozregression able to find them? As mentioned in comment 6, I thought it was configured to do so.
I'm guessing it's a mozregression bug in this block. Most likely we want to try multiple indexes and only fail out if we don't find any of them.
Comment 13•6 years ago
|
||
(In reply to Aki Sasaki [:aki] from comment #12)
I'm guessing it's a mozregression bug in this block. Most likely we want to try multiple indexes and only fail out if we don't find any of them.
Ah yes, that sounds like a plausible theory. Is this something you or someone else on the taskcluster team might be able to do? Not meaning to pass the buck, but I don't really have a lot of time to maintain mozregression these days, and don't understand the taskcluster all that well.
Assignee | ||
Comment 15•6 years ago
•
|
||
Is it just me, or has multiple build types on the command line not actually worked since, well, ever as far as I can tell. Not to mention asan-debug not working at all because it has a hyphen in it.
Edit:
Though you can trick asan-debug into working by replacing the hyphen with a comma. And optionally reversing the words, it isn't fussed.
Assignee | ||
Comment 16•6 years ago
|
||
Anyway, here's a rough WIP that seems to actually work. Even passes the (current) tests. Need to write new ones.
Though frankly I'm tempted to rip out any support for users passing in multiple builds (since clearly no-one uses it...), and only keep the internal support for use for the shippable->opt->pgo fallbacking.
Comment 17•6 years ago
|
||
(In reply to Ian Moody [:Kwan] (UTC+0) from comment #16)
Anyway, here's a rough WIP that seems to actually work. Even passes the (current) tests. Need to write new ones.
This is looking great, thank you!
Though frankly I'm tempted to rip out any support for users passing in multiple builds (since clearly no-one uses it...), and only keep the internal support for use for the shippable->opt->pgo fallbacking.
It could be that things used to work, but broke when we moved over to taskcluster. I wouldn't be too sad if we lost this feature -- if someone really wants it, they can always re-add it.
Assignee | ||
Comment 18•6 years ago
|
||
(In reply to Ian Moody [:Kwan] (UTC+0) from comment #15)
Is it just me, or has multiple build types on the command line not actually worked since, well, ever as far as I can tell. Not to mention asan-debug not working at all because it has a hyphen in it.
Edit:
Though you can trick asan-debug into working by replacing the hyphen with a comma. And optionally reversing the words, it isn't fussed.
(In reply to William Lachance (:wlach) (use needinfo!) from comment #17)
(In reply to Ian Moody [:Kwan] (UTC+0) from comment #16)
Anyway, here's a rough WIP that seems to actually work. Even passes the (current) tests. Need to write new ones.
This is looking great, thank you!
Though frankly I'm tempted to rip out any support for users passing in multiple builds (since clearly no-one uses it...), and only keep the internal support for use for the shippable->opt->pgo fallbacking.
It could be that things used to work, but broke when we moved over to taskcluster. I wouldn't be too sad if we lost this feature -- if someone really wants it, they can always re-add it.
Ah, actually part of the problem is that I misread the code/help text and misunderstood what it is for. It was introduced for FxOS which more often had two-part (or more) build types, like "jb-opt", "kk-opt", "1-opt", or even "kk-spark-eng-opt" ("asan-debug" is the only such one these days), and I guess the comma use was intended to save the user worrying about getting the parts in the right order. Given that FxOS has gone away and asan-debug is the only such left, I don't know if there is any value to keeping it around just so a user can do asan,debug (or swapped) instead of asan-debug.
Assignee | ||
Comment 19•6 years ago
|
||
Well I think I've got this into a usable state, but I think it needs a little more testing before review.
Windows GUI build for the brave (direct exe link) (with bonus bug 1536013 included as well if you happen to be on win64-aarch64)
Comment 20•6 years ago
|
||
Thank you. It works as expected. Tested with bisections for 2018-08, 2019-02 and the last days.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 21•6 years ago
|
||
Thank you for the testing Aryx :)
Comment 22•6 years ago
|
||
This is merged and new versions of mozregression have been released! Thank you :Kwan and :Callek!
Description
•