The daily windows seamonkey commercial build system does not detect when the build fails (tinderbox seems to be able to detect it). It should detect build errors and not deliver to sweetlou areas in such a case. This is causing deliverables of mozilla seamonkey bits instead of the commercial seamonkey bits. This in turn causes people to test the wrong builds and also file bugs against xpinstall/wizard installer when it's really not the case. Here's an example of what happens: 1) build system builds mozilla seamonkey bits 2) build system builds commercial seamonkey bits using mozilla seeamonkey bits, but fails. 3) build system ends up delivering mozilla seamonkey bits and installer bits to sweetlou. Since the mozilla seamonkey bits do not build the .xpi files during the install build process, the mozilla seamonkey installer is half built, meaning that it can't install anything. This state of the mozilla seamonkey installer is then passed over to the commercial seamonkey build system. Then, when the commercial seamonkey build system fails before building the windows wizard installer, it delivers this not-quite-working installer to sweetlou for testing. However, if the commercial seamonkey build system succeeds, the installer works fine. There should be a mechanism to detect that a simple nmake.exe had failed (or however tinderbox does it). A more elaborate error detection system can be later incorporated, if need be.
Right now this stuff is in a batch file. If someone can help me figure out how to check return status in batch files, i can fix the script. Otherwise, i need to rewrite in perl to check.
Summary: Windows Seamonkey commercial build system not detecting and stopping on build errors. → [dogfood]Windows Seamonkey commercial build system not detecting and stopping on build errors.
added "dogfood" to the summary for consideration by PDT team. This is bad.
Leaf, you can check status in a batch file using "errorlevel". For example, "if error level 1" means that the "if" clause is executed if the previous app returned a status code greater than 1.
Please try to fix this one, leaf. Thanks.
Testing `if errorlevel 1 goto dienetscape' in production scripts; if the build succeeds, i'll sabotage it and see if i can get failure detection (tested on depth=1 nmake, want to test that the errorlevel is propogated up to the top nmake process).
Status: ASSIGNED → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
this seems to be working. When we have build bustage on a real day, someone can mark this verified.
On "real days" we don't get bustage ;-) thanks leaf
Putting on M12 radar since fixed during this time.
I'm the person that fixed! Should i really be the one to verify?
Marking Verified per chofmann...he gave me the ok! :-)
You need to log in before you can comment on or make changes to this bug.