<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le lun. 17 oct. 2016 à 21:18, Ryan Schmidt <<a href="mailto:buildbot@ryandesign.com">buildbot@ryandesign.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Oct 17, 2016, at 3:19 AM, Pierre Tardy <<a href="mailto:tardyp@gmail.com" class="gmail_msg" target="_blank">tardyp@gmail.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hello.<br class="gmail_msg">
> On buildbot eight, the database only store information of the build requests before the build is started.<br class="gmail_msg">
><br class="gmail_msg">
> Switching to a new database you will only lose the buildrequests and not the builds which are stored in pickle files.<br class="gmail_msg">
<br class="gmail_msg">
So, if I wait until all scheduled builds have been completed and the builders are all idle, I could then stop the system, switch the config to postgresql, start the system, and not have lost any information about prior builds? If so, that would be fine.<br class="gmail_msg">
<br class="gmail_msg"></blockquote><div>Correct.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We use buildbot to build binaries of ports for MacPorts. When a new version of macOS is released and we set up a new buildbot worker and builder for it, we need to build all 20,000 ports on it.<br class="gmail_msg"></blockquote><div><br></div><div>Indeed, in that case, multimaster can't help.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
With our old buildbot setup, we would force a single build that would build all 20,000 ports. This build would take several weeks to complete. If a problem was encountered that caused the build to abort, we had to start over. And when it did complete, the huge log that was generated caused an out of memory condition in buildbot, but not before making the web interface unresponsive for a few minutes.<br class="gmail_msg"></blockquote><div><br></div><div>That makes lot of sense to me. this is a good idea.</div><div><br></div><div>Maybe you could batch builds per 100 packages if this makes sense.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
With our new buildbot setup, the single build that gets forced in turn triggers individual builds for each port on another builder. We haven't tried doing this for all 20,000 ports yet, but I have tried doing around 3,000 ports at once, and the process of triggering the individual builds took several minutes, during which the web interface would become unresponsive. Also, looking at a builder page for a builder that has hundreds of scheduled builds can take a long time to display.<br class="gmail_msg"></blockquote><div><br></div><div>How do you do that? via a trigger step?</div><div><br></div><div>> <span class="inbox-inbox-Apple-converted-space"> </span>Also, looking at a builder page for a builder that has hundreds of scheduled builds can take a long time to display.</div><div><div>Those hundreds of buildrequests will be stored on the db indeed pg may help.</div><br class="inbox-inbox-Apple-interchange-newline"></div><div><br></div></div></div>