763759 - Use a less infra-intensive way to ensure the non-profiling repo Nightly is built from the same changeset as mozilla-central's

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Ed Morley [:emorley]]

Currently:
* Every 30 mins a cron job pushes any new mozilla-central changesets to the profiling branch.
* The profiling branch doesn't have anything landed on it directly, aiui it just uses a different mozconfig to set MOZ_PROFILING/--enable-profiling etc. [1]
* Even when the changesets landed on mozilla-central are DONTBUILD, they still get built on the profiling branch due to bug 758965. [2]

After speaking to Ehsan, it turns out the reason for the 30 min cron job is just to ensure that the profiling Nightly is generated from a changeset as close as possible to that used for mozilla-central's Nightly. Ehsan said that the dep builds the rest of the day didn't really serve any purpose.

As such we could save load (and also as a bonus improve the chances of picking the same changeset) by doing one of the following:

a) Building profiling Nightlies from mozilla-central directly, ie have a 'Np' build in a similar fashion to how the 'Nr'/RPM builds are currently implemented. The profiling Nightly would need to still have the Nightly update channel 'nightly-profiling' & whatever custom mozconfig is used at present. We would then not need to have dep builds at all for the profiling builds & would be guaranteed to have the same base changeset for all the nightlies.

b) If that is too much hassle/not possible: We could still use the profiling repo, but work out the average 'last time of pushing for all green in time for the nightly' and Ehsan just replace his every 30 min cron job with a few 'specific-time, once a day jobs' at 10-15 min intervals either side of our estimate. The end result would be closer to the desired changeset than a 30 min cron job, but we'd still reduce load significantly the other 22-23 hours of the day.

Ben/Armen (wasn't quite sure who best to CC, let me know if someone else would have been more appropriate): how viable is #A?

Thanks! :-)


[1] I've looked through buildbot-configs & various 'set up profiling repo' type bugs, but couldn't find where this is done :-(

[2] This would take more than the obvious 2-3 line patch to correct, since we'd have to cater for multiple changeset pushes that only had DONTBUILD in the topmost changeset, so need to fetch/parse the pushlog etc. If we stopped doing unnecessary dep builds every 30 mins, this could just be WONTFIXed, since you'd rarely have a 24 hour span with only DONTBUILDs.

Comment 1

[Ed Morley [:emorley]]

Also, Ehsan has proposed switching on --enable-profiling on mozilla-central by default[1]. It's not yet clear if that will go ahead, but if so, this bug would become irrelevant, since the profiling repo could just be switched off entirely.

[1] https://groups.google.com/d/topic/mozilla.dev.platform/UENmwUOFCkU/discussion

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

found in triage.

Comment 3

[Chris AtLee [:catlee]]

Another option would be to have a script monitor buildapi or pulse and wait for the m-c nightlies to get triggered, and then do a merge/push to the profiling branch and trigger nightlies there as well.

Comment 4

[(no longer active)]

As Ed mentioned in comment 1, I'm proposing to turn on --enable-profiling on Nightly, so let's not get ahead of ourselves here.

So far there doesn't seem to be any strong objections to doing this, but Kyle pointed out that we should probably continue running unit tests on builds without --enable-profiling, so that if we happen to trigger a compiler bug, we would know before the Aurora uplift.  This is a valid concern, and for this reason I would like to keep the profiling branch around, so that we would get unit tests on it.  In that case we should also start running Talos on it again, in order to catch regressions (and possible crashes) on that branch as well, because that is ultimately what would be uplifted to Aurora.

Comment 5

[(no longer active)]

I've repurposed the profiling branch to build without --enable-profiling.  So I guess this is WONTFIX now.

Comment 6

[Ed Morley [:emorley]]

Yeah, but aren't we going to want to do the same thing to whatever you rename it to?

Comment 7

[(no longer active)]

Same thing being what?

Comment 8

[Ed Morley [:emorley]]

To stop using a 30 min cron job to bruteforce Nightly builds to be build from the same changeset & instead ideally have the new "non-profiling" (or whatever they end up being called) builds as additionally builds on mozilla-central, similar to the RPM builds etc are now.

ie s/profiling/non-profiling/ in comment 0.

I realise that the new repo plans are still in flux and --enable-profiling might not even stick after all; but it seems worth having this open to reduce load later once things have settled.

Comment 9

[(no longer active)]

We will turn nightly builds off on the new branch.  But we still need to be able to run the unit tests in order to make sure that none of the existing tests are going to be broken when we uplift to Aurora, therefore we need regular builds on this branch.  I'm not sure how you're planning to avoid this.

Comment 10

[Ed Morley [:emorley]]

Ah ok, turning Nightlies off but leaving unit tests on wasn't mentioned in any of the other bugs or on the newsgroups; all the comments read as though it would be a straight swap. If that's the chosen direction, WONTFIX sounds fine :-)