SeaMonkey:Release Process:2.0b1 - Revision history

KaiRo: /* Notes */

2009-07-21T20:28:41Z

Notes

← Older revision		Revision as of 20:28, 21 July 2009
Line 84:		Line 84:
	rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/		rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/

	====Final ~~verification=~~===		=== Final Verification ===

	* Use 'Force Build' to start the final_verification builder, all tested URLs are HTTP 200 and 302, everything good to go!		* Use 'Force Build' to start the final_verification builder, all tested URLs are HTTP 200 and 302, everything good to go!

			=== Publish Updates to the beta Channel ===

			~/bin/backupsnip 20090717-SeaMonkey-2.0b1
			~/bin/pushsnip 20090717-SeaMonkey-2.0b1

KaiRo: /* Final verification */

2009-07-21T16:37:07Z

Final verification

← Older revision		Revision as of 16:37, 21 July 2009
Line 86:		Line 86:
	====Final verification====		====Final verification====

	* Use 'Force Build' to start the final_verification builder, all tested URLs are ~~HTPP~~ 200 and 302, everything good to go!		* Use 'Force Build' to start the final_verification builder, all tested URLs are HTTP 200 and 302, everything good to go!

KaiRo: /* Notes */

2009-07-21T16:36:40Z

Notes

← Older revision		Revision as of 16:36, 21 July 2009
Line 83:		Line 83:
	# seabld@stage		# seabld@stage
	rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/		rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/

			====Final verification====

			* Use 'Force Build' to start the final_verification builder, all tested URLs are HTPP 200 and 302, everything good to go!

KaiRo: /* Push To Mirrors */

2009-07-21T15:53:10Z

Push To Mirrors

← Older revision		Revision as of 15:53, 21 July 2009
Line 80:		Line 80:

	=== Push To Mirrors ===		=== Push To Mirrors ===

	~~'''NOT DONE YET!'''~~

	~~Will need to do this:~~

	# seabld@stage		# seabld@stage
	rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/		rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/

KaiRo: /* Notes */

2009-07-20T00:15:48Z

Notes

← Older revision		Revision as of 00:15, 20 July 2009
Line 78:		Line 78:
	cp -av ${file} langpack/seamonkey-${VERSION}.${locale}.langpack.xpi		cp -av ${file} langpack/seamonkey-${VERSION}.${locale}.langpack.xpi
	done		done

			=== Push To Mirrors ===

			'''NOT DONE YET!'''

			Will need to do this:

			# seabld@stage
			rsync -av --exclude=.log --exclude=.txt --exclude=unsigned --exclude=xpi /pub/mozilla.org/seamonkey/nightly/2.0b1-candidates/build1/ /pub/mozilla.org/seamonkey/releases/2.0b1/

KaiRo: /* zips, langpacks */

2009-07-20T00:06:33Z

zips, langpacks

@@ Line 32: / Line 32: @@
 We have no signing infrastructure for SeaMonkey right now, so I faked the signing step that is usually done after completion of builds and L10n repacks and before the update generation.
-Logged onto stage-old.mozilla.org and use those commands to do the following:
+Logged onto stage-old.mozilla.org and use those commands to do the following (now in <code>fakesign.sh</code>):
   # seabld@stage-old
   VERSION=2.0b1
@@ Line 52: / Line 52: @@
 **Win32 verification is red, but that's expected as the general notes on [[Release:Release_Automation_on_Mercurial:Documentation#Log_Analysis|verification log analysis]] point out, the .chk files for NSS differ. Apart from that, debugQA is also left and the p@m directory seems to still be there even if the log states its contents have been removed.
 **Mac verification is green, also shows debugQA being left and a nice diff of removed-files after partial update, which doesn't really matter for us, of course.

KaiRo: /* Updates and Verification */

2009-07-19T14:00:21Z

Updates and Verification

← Older revision		Revision as of 14:00, 19 July 2009
Line 51:		Line 51:
	**Linux verification is green, log analysis shows that debugQA wasn't removed, that's OK from a release POV an might just be OK overall.		**Linux verification is green, log analysis shows that debugQA wasn't removed, that's OK from a release POV an might just be OK overall.
	**Win32 verification is red, but that's expected as the general notes on [[Release:Release_Automation_on_Mercurial:Documentation#Log_Analysis\|verification log analysis]] point out, the .chk files for NSS differ. Apart from that, debugQA is also left and the p@m directory seems to still be there even if the log states its contents have been removed.		**Win32 verification is red, but that's expected as the general notes on [[Release:Release_Automation_on_Mercurial:Documentation#Log_Analysis\|verification log analysis]] point out, the .chk files for NSS differ. Apart from that, debugQA is also left and the p@m directory seems to still be there even if the log states its contents have been removed.
			**Mac verification is green, also shows debugQA being left and a nice diff of removed-files after partial update, which doesn't really matter for us, of course.

KaiRo: /* Updates and Verification */

2009-07-19T13:51:04Z

Updates and Verification

← Older revision		Revision as of 13:51, 19 July 2009
Line 49:		Line 49:
	*As I did the fake-sign step prematurely when Mac wasn't available yet due to above mentioned difficulties, the update step triggered on seeing those "signed" builds and failed due to missing Mac builds. I restarted it when Mac builds were there, but it it had the patcher-config step failing as the run before had already done that. The factory continued nevertheless and created updates correctly.		*As I did the fake-sign step prematurely when Mac wasn't available yet due to above mentioned difficulties, the update step triggered on seeing those "signed" builds and failed due to missing Mac builds. I restarted it when Mac builds were there, but it it had the patcher-config step failing as the run before had already done that. The factory continued nevertheless and created updates correctly.
	*When I kicked off the update verification steps, they failed because the verify configs contained location for 2.0a3 build that would fit pretty names but we didn't have them there yet. Because of that, I needed to manually edit the update-verify files for the correct locations and start the verification steps again (both updates and verification can just be triggered from the buildbot web interface).		*When I kicked off the update verification steps, they failed because the verify configs contained location for 2.0a3 build that would fit pretty names but we didn't have them there yet. Because of that, I needed to manually edit the update-verify files for the correct locations and start the verification steps again (both updates and verification can just be triggered from the buildbot web interface).
			**Linux verification is green, log analysis shows that debugQA wasn't removed, that's OK from a release POV an might just be OK overall.
			**Win32 verification is red, but that's expected as the general notes on [[Release:Release_Automation_on_Mercurial:Documentation#Log_Analysis\|verification log analysis]] point out, the .chk files for NSS differ. Apart from that, debugQA is also left and the p@m directory seems to still be there even if the log states its contents have been removed.

KaiRo: /* Updates and Verification */

2009-07-19T13:34:45Z

Updates and Verification

← Older revision		Revision as of 13:34, 19 July 2009
Line 44:		Line 44:

	We purposely make copies here rather than symlinking for a couple of reasons: L10n verify scripts barf when they get zip files (hence the --exclude above), 'updates' factory will blow away complete MARs upon upload if update/win32 is a symlink. The echo creates the log the automation looks for, in order to continue to l10n verify and updates.		We purposely make copies here rather than symlinking for a couple of reasons: L10n verify scripts barf when they get zip files (hence the --exclude above), 'updates' factory will blow away complete MARs upon upload if update/win32 is a symlink. The echo creates the log the automation looks for, in order to continue to l10n verify and updates.

			=== Updates and Verification ===

			*As I did the fake-sign step prematurely when Mac wasn't available yet due to above mentioned difficulties, the update step triggered on seeing those "signed" builds and failed due to missing Mac builds. I restarted it when Mac builds were there, but it it had the patcher-config step failing as the run before had already done that. The factory continued nevertheless and created updates correctly.
			*When I kicked off the update verification steps, they failed because the verify configs contained location for 2.0a3 build that would fit pretty names but we didn't have them there yet. Because of that, I needed to manually edit the update-verify files for the correct locations and start the verification steps again (both updates and verification can just be triggered from the buildbot web interface).

KaiRo: work around double-apostrophe being detected as wiki code

2009-07-19T13:29:09Z

work around double-apostrophe being detected as wiki code

← Older revision		Revision as of 13:29, 19 July 2009
Line 26:		Line 26:
	* Windows and Mac ran into build problems the first time when running client.py checkout - I had forgotten to ssh into cvs.m.o from those slaves before to accept the ssh key. Corrected that, dummied out tag/source, reduced build triggering to exclude Linux and kicked off again		* Windows and Mac ran into build problems the first time when running client.py checkout - I had forgotten to ssh into cvs.m.o from those slaves before to accept the ssh key. Corrected that, dummied out tag/source, reduced build triggering to exclude Linux and kicked off again
	*Mac then strangely ran into a hang in gathering build properties, rebooted the slave to get the master to recognize the build was broken, but the master thought the cycle was good when that step failed and triggered L10n repacks that failed as no en-US build was up yet. Reduced build triggering to Mac only and kicked off once again		*Mac then strangely ran into a hang in gathering build properties, rebooted the slave to get the master to recognize the build was broken, but the master thought the cycle was good when that step failed and triggered L10n repacks that failed as no en-US build was up yet. Reduced build triggering to Mac only and kicked off once again
	*Second try on Mac builds failed the same way, it ran on the same slave (-osx-02) as the first try as well. The error was only to be seen in the slave's twistd.log and came down to a "[Errno 4] Interrupted system call" in _syscmd_uname('-p','') which is called by twistd/buildbot itself, which makes it look even stranger. When I kicked it off once again and the build ran on a different slave (-osx-01), it worked successfully.		*Second try on Mac builds failed the same way, it ran on the same slave (-osx-02) as the first try as well. The error was only to be seen in the slave's twistd.log and came down to a "[Errno 4] Interrupted system call" in <code>_syscmd_uname('-p',<b>'</b>')</code> which is called by twistd/buildbot itself, which makes it look even stranger. When I kicked it off once again and the build ran on a different slave (-osx-01), it worked successfully.

	=== Signing ===		=== Signing ===