ReleaseEngineering/Buildbot Best Practices: Difference between revisions

ReleaseEngineering/Buildbot Best Practices (view source)

Revision as of 19:29, 26 March 2009

9 bytes removed , 26 March 2009

→‎How to land a patch

Bhearsum

canmove, Confirmed users

6,441

edits

@@ Line 22: / Line 22: @@
   cd /builds/buildbot/configs
   hg diff
-* Check to make sure only your patches are going to be enabled. If more than just your changeset show up in 'hg in' you can use 'hg in -p' to look at a diff of all of the patches that are going to be pulled in. It's not uncommon for other changesets to be there in buildbot-configs, since it holds configs for so many masters. Use your common sense here.
+* Pull in changes and inspect them before you update the local repository's working directory. If there are changes other than yours which affect the master you're updating you should check with the person that landed them and make sure they are safe to take at the same time. If you are unsure or the person is unavailable they may be backed out to avoid complicating the update. Use your judgment here.
   cd /tools/buildbotcustom/buildbotcustom
-  hg in
+  hg pull
- # If there are more than just your changeset use 'hg in -p' to look at the diffs
+  hg diff -rdefault
-  hg in -p
+  # same thing for configs
-  # Same thing for configs
   cd /builds/buildbot/configs
-  hg in
+  hg pull
-  hg in -p
+  hg diff -rdefault
-* Now, assuming there are no interfering patches, pull the changes for real
+* Now, assuming there are no interfering patches, update the local repository's working directory.
   cd /tools/buildbotcustom/buildbotcustom
-  hg pull && hg up
+  hg up
   cd /builds/buildbot/configs
-  hg pull && hg up
+  hg up
 * Run checkconfig to make sure the reconfig/restart will succeed
   cd /builds/buildbot/$master

ReleaseEngineering/Buildbot Best Practices: Difference between revisions

ReleaseEngineering/Buildbot Best Practices (view source)

Revision as of 19:29, 26 March 2009

Navigation menu

Search