926705 - Set up a VS2012 Windows build in automation

Status: RESOLVED WONTFIX

(Infrastructure & Operations Graveyard :: CIDuty, task)

Description

[Allison Naaktgeboren :ally]

We have had a number of headaches due to changes checked in that break on vs2012 on win8, which is what the entire metrofx/windows development team uses.

cpearce has proposed setting up a have a vs2012 build machine running on tpbl that only builds so these issues can be caught before they halt work for the entire team without adding too much burden to the system.

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

This is particularly important, since most devs don't test on windows, and it such a time sink to build on Windows that issues like these cost days of development time when they crop up. Today is such a day; bug 926083 hit the metrofx and windows devs today.

Comment 2

[Masatoshi Kimura [:emk]]

Does it matter after we have migrated to VS2013 (bug 914596)?

Comment 3

[Ed Morley [:emorley]]

(TBPL is only a dashboard that displays results; buildbot does the scheduling/automation)

Comment 4

[Gregory Szorc [:gps]]

(In reply to Masatoshi Kimura [:emk] from comment #2)
> Does it matter after we have migrated to VS2013 (bug 914596)?

We have no control over what Visual Studio versions people in the wild are using. While I anticipate that the chances of breaking VS2012 but not 2013 are slim, if we can spare the operational capacity to just compile VS2012, I think that will be a win. We could even leave out packaging and |make check| from these builds if we wanted to make them as fast as possible. Also, bug 925605 should result in some pretty nice build speed wins for Windows, increasing capacity for Windows machines.

Comment 5

[Benjamin Smedberg]

This doesn't sound worthwhile to me. If we have people using VC2012, they will file bugs when it breaks, and we'll fix them. The cost of setting up another kind of builder, which for load reasons probably shouldn't run on-checkin anyway, sounds pretty high compared with the benefits.

We have the same situation with all sorts of versions of GCC/clang that people use.

Comment 6

[Chris Cooper [:coop] (he/him)]

As Ben alludes to, releng systems are streamlined to run on a minimal # of build platforms to maximize throughput while still being able to compile across all code branches. This includes much older branches like ESR. Getting alternate build platforms operating at scale can be hard and/or expensive. The key takeaway here is that releng is optimizing its infra for different things than developers.

One thing that might help here would be to facilitate the submission of user results like we used to be able to do with tinderbox. If community members want to submit build results from a different compiler or platform on whatever cadence, we could facilitate that again.

Comment 7

[(no longer active)]

FWIW we already support building with VS2012 on the Date branch, which is currently merged manually from the mozilla-central upstream.

Comment 8

[Allison Naaktgeboren :ally]

(In reply to Chris Cooper [:coop] from comment #6)
> As Ben alludes to, releng systems are streamlined to run on a minimal # of
> build platforms to maximize throughput while still being able to compile
> across all code branches. This includes much older branches like ESR.
> Getting alternate build platforms operating at scale can be hard and/or
> expensive. The key takeaway here is that releng is optimizing its infra for
> different things than developers.
> 
> One thing that might help here would be to facilitate the submission of user
> results like we used to be able to do with tinderbox. If community members
> want to submit build results from a different compiler or platform on
> whatever cadence, we could facilitate that again.

That sounds like a really useful idea, for people who test build changes on all platforms before landing(and currently have a devil of a time doing it). Regardless of this bug, I think we all have an interest in making it easier/more inviting for people to do that in the general case.

Would that catch people who never consider that their patches might break another platform? It's those cases that concern me. The last really bad one took 5-6 working days to find and backout|fix.

Comment 9

[(not currently active) Ted Mielczarek]

It might or it might not. The reality is that only the exact toolchains in use on our production builds are guaranteed not to break, and everything else is given best-effort support. There are just too many combinations to build everything on Mozilla-supported hardware. If you really don't want your build to break your best option is to use the same toolchain as our official builds.