canmove, Confirmed users
2,850
edits
(→How to reconfig: Update script link to use default, not an old rev) |
ChrisCooper (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
A reconfig (short for "reconfigure the buildbot masters") is how changes to buildbot configurations make it into production. Buildduty is responsible for running reconfigs. | |||
In a nutshell, a reconfig consists of: | |||
* moving the ''production'' tag for the [https://hg.mozilla.org/build/buildbot-configs buildbot-configs] repository and the ''production-0.8'' tag for the [https://hg.mozilla.org/build/buildbotcustom buildbotcustom] to the current tip (or chosen revision) | |||
* updating the source checkout of both repositories on all the buildbot masters | |||
* updating the [https://hg.mozilla.org/build/tools tools] checkout on each master to the current tip | |||
* executing a buildbot reconfig command on each buildbot master | |||
We also still move the production tag for the [https://hg.mozilla.org/build/mozharness mozharness] repository until mozharness is moved fully in-tree. | |||
Please see the [https://wiki.mozilla.org/ReleaseEngineering/How_To/Land_Buildbot_Master_Changes instructions for how to land buildbot changes] for more information. | |||
It is | It is polite to ask in #releng if anyone has further changes to land before starting the reconfig process. | ||
= How to reconfig = | |||
The current state of the art is to use the [https://hg.mozilla.org/build/tools/file/default/buildfarm/maintenance/end_to_end_reconfig.sh end_to_end_reconfig.sh] script. | |||
The end_to_end_reconfig.sh script uses the original [https://wiki.mozilla.org/ReleaseEngineering/Managing_Buildbot_with_Fabric fabric scripts] as it's core, but also takes care of updating the wiki, updating bugs affected by the merge, and updating the tools checkouts on foopies as well. As such, the script has a few, indirect python module dependencies: | |||
* fabric | |||
* requests | |||
However, the script will try to install the dependencies automatically if they are missing. | |||
= Help, my reconfig is stuck! = | |||
Reconfigs can take as little as 30 minutes to run, but can take up to 2 hours depending on how busy the systems are. | |||
In general, linux test masters are the slowest to reconfig. You can tail the manage_masters-##########.log to keep up with progress. By default, this log is created in /tmp/reconfig. | |||
You | |||
If the reconfig gets stuck, see [https://wiki.mozilla.org/ReleaseEngineering/How_To/Unstick_a_Stuck_Slave_From_A_Master How To/Unstick a Stuck Slave From A Master]. | If the reconfig gets stuck, see [https://wiki.mozilla.org/ReleaseEngineering/How_To/Unstick_a_Stuck_Slave_From_A_Master How To/Unstick a Stuck Slave From A Master]. | ||