When running the hazard analysis locally in developer mode, the build will bomb out saying that you need to run mercurial-setup, even if you already have.
Created attachment 8650134 [details] [diff] [review] Suppress mercurial-setup check for hazard analysis builds gps - giving you review to give you a chance to object to my usage of I_PREFER_A_SUBOPTIMAL_MERCURIAL_EXPERIENCE. Specifically, this patch is *NOT* just a way to avoid running mercurial-setup. The problem is that the hazard builds use |mach build| to do the compilation (which maybe is a bad idea but I kind of like using it to test mach in automation), but they set the state directory to a subdirectory of the 'work' directory. That is mostly because I had plans to dump out the performance statistics that mach tracks automatically, and because I didn't want these builds to interfere with a developer's manually request build state. Unfortunately, mach stores the token that indicates whether mercurial-setup has been run in the state dir. One fix would be to store that token in a user's .hgrc, but I guess that would require updating that file even if the user rejected all automated changes, so that's probably not a good idea. Also, it would defeat the state isolation I was trying to achieve in the first place. Anyway, if usage of this variable bothers you, I could switch to redirecting stdin from /dev/null when invoking mach or something. That's about equally hacky to me.
Attachment #8650134 - Flags: review?(gps)
Comment on attachment 8650134 [details] [diff] [review] Suppress mercurial-setup check for hazard analysis builds Review of attachment 8650134 [details] [diff] [review]: ----------------------------------------------------------------- Setting stdin to os.devnull is probably the proper approach. But that is likely an invasive patch. This one is easy.
Attachment #8650134 - Flags: review?(gps) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox43: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
You need to log in before you can comment on or make changes to this bug.