1056790 - enable_perproduct_builds on Try

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Ed Morley [:emorley]]

Bug 787449 added the ability for repos to opt into only building certain job types, depending on what files changed.

It's only currently enabled for the repos here:
http://mxr.mozilla.org/build-central/search?string=enable_perproduct_builds

We should see if we can enable it on try.

I imagine the hard part will be determining which new csets a try push added, however if the repo on the machine is stale, the worst case is we'll build the same as we do already. And if someone is pushing a followup (and thus only adding a few csets to the repo, when their mq stack is actually much bigger), then their previous push would have already generated results on the other platforms. (And worst case, they could use self-serve "generate dep builds").

Other options:
* Warn at the hghook trychooser stage that their chosen try syntax is too broad for the files changed (with an override)
* Coming up with a way to tell the qbase so the changed files list is accurate.

Comment 1

[Ed Morley [:emorley]]

Meant to add this would apply on top of trychooser - so the actual jobs scheduled would be the overlapping set of trychooser and the perproduct builds logic. However it may be worth adding an override string (eg "BUILDALL"), which trychooser could have a checkbox for adding.

Comment 2

[Ed Morley [:emorley]]

s/BUILDALL/OVERRIDESCHEDULER/

Comment 3

[James Graham [:jgraham]]

Don't phases allow you to work out which csets aren't published yet? That seems like a reasonable way to figure out what's part of the branch. Or just changesets that are ancestors of the push tip but aren't in e.g. inbound. Am I misunderstanding the problem?

Comment 4

[Ed Morley [:emorley]]

(In reply to James Graham [:jgraham] from comment #3)
> Don't phases allow you to work out which csets aren't published yet? That
> seems like a reasonable way to figure out what's part of the branch. Or just
> changesets that are ancestors of the push tip but aren't in e.g. inbound. Am
> I misunderstanding the problem?

Actually yeah that might work, though I don't know if that data is available in buildbot.

Comment 5

[Steve Fink [:sfink] [:s:]]

Having thought about this in the past but having no real knowledge of the implementation :-) , my guess is that phases are only known client-side. The frontiers are updated client-side based on whether you're pushing to a publishing server or not. So to use phases (which seems like the right way to do this), I think you'd have to send it along as metadata during the push.

It may not be the slickest, but the most straightforward way I can think of doing that is in the try syntax string. "try: -b do -p win32,commodore64 --base e3a123d043f" or something. A trychooser extension could fill that in, though obviously this isn't great for simple |hg push -f try| pushes. We could disallow those, or make the server guess the appropriate ancestor. Or fall back to what we do now (which is broken btw -- if I push a patch stack ABC, where A and B touch js/src but C does not, then push ABC', then I won't get js/src-specific jobs. This is particularly a problem when you get the try syntax wrong and re-push, changing only an empty patch that holds the try syntax string.)