canmove, Confirmed users
6,441
edits
ReleaseEngineering/Buildbot Best Practices: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/Buildbot Best Practices (view source)
Revision as of 15:16, 12 March 2009
, 12 March 2009→Check-in Policies
No edit summary |
|||
| Line 9: | Line 9: | ||
== Check-in Policies == | == Check-in Policies == | ||
* We track configuration updates to our masters on [[ReleaseEngineering:BuildbotMasterChanges BuildbotMasterChanges]]. Any change to a production Buildbot Master should be tracked on this page. | * We track configuration updates to our masters on [[ReleaseEngineering:BuildbotMasterChanges | BuildbotMasterChanges]]. Any change to a production Buildbot Master should be tracked on this page. | ||
* Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | * Patches should not be checked in until you are ready to update the master with them. This helps to avoid situations where an urgent fix needs to go in, and a random unrelated patch ends up getting enabled at the same time. | ||
* Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | * Production masters should never contain local changes. Even if you are just testing something you should check it in and pull it rather than making the change locally. Having temporary changes in the version control history is useful when debugging things later. | ||