Ecco la ricetta per approntare uno slave Buildbot di MariaDB su Windows:

1. Preparare un ambiente di sviluppo
2. Installare Python, 32 bit. Twisted non funziona a 64 bit e builtbot non è stato testato abbastanza su Python versione 3.
3. Installare pywin32. Assicurarsi che la versione corrisponda perfettamente a quella di Python e scaricare il file .exe, non il file zip.
4. Installare Twisted
5. Installare buildbot: Scaricare e decomprimere il file zip. Nella shell di amministrazione, portarsi nella directory buildbot ed eseguire "python setup.py install". Dopodiché la directory buildbot decompressa non serve più.

Fatto questo, eseguire i seguenti comandi:

cd <somewhere>
mkdir buildbot
cd buildbot
bzr init-repo .
C:\buildbot\buildbot-slave-0.8.3\build\scripts-2.7\buildslave.bat create-slave --usepty=0 <slavedir> hasky.askmonty.org:9989 <nomeslave> <passwd>

Correggere i path nell'ultimo comando a seconda di dove si trova buildbot decompresso.

E' possibile sapere <nomeslave> e <passwd> da una delle persone di Monty Program che gestiscono il sistema buildbot. <slavedir> può essere scelta a piacere - in genere va bene <nomeslave>.

Cambiare i file <slavedir>\info\admin e <slavedir>\info\host con i valori corretti. Il valore dell'host dovrebbe includere la versione di Windows, 32 o 64 bit, e quella di Visual Studio.

Per testare lo slave buildbot:

C:\buildbot\buildbot-slave-0.8.3\build\scripts-2.7\buildslave.bat start <somewhere>\buildbot\<slavedir>

All'avvio di buildbot, si dovrebbe configurarlo come servizio. Si vedano le istruzioni a questa pagina. Sono nella sezione "Windows Buildbot service setup". Questo documento comprende anche la documentazione per l'installazione generica di Buildbot su Windows.

Perché compilare buildbot come servizio

Quando buildbot viene eseguito nella sessione utente e l'applicazione avviata da buildbot va in crash, compare una finestra popup. Alcune popup sono generate dal debug post-mortem, mentre altre sono generate dall'Error reporting di Windows. E' difficile (o impossibile per chi non ci ha mai provato prima) evitare tutte queste finestre. Per questo motivo si esegue buildbot come servizio. I servizi non generano popup.

Fallimenti comuni di Buildbot su Windows

Il test si arresta dopo aver tentato di chiamare cdb per stampare una backtrace.

MTR cerca di chiamare cdb attraverso gli operatoci backtick di Perl, quando mysqld.exe va in crash. Alla prima esecuzione, cdb sta scaricando i simboli pubblici di Windows da msdl.microsoft.com/download/symbols. I simboli sono in una cache in C:\cdb_symbols, e le successive esecuzioni sono più veloci, tuttavia le analisi crashdump sul primo crash solitamente impiegano del tempo.

Se tutto questo dà noia, si avvii il test con --mysqld=--gdb, che evita la creazione dei file crashdump, perciò cdb non viene chiamato.

Eccezione di Buildbot The process cannot access the file because it is being used by another process

Avviene perché buildbot non pulisce i processi lasciati aperti dalle esecuzioni precedenti, i quali potrebbero avere dei lock sui file necessari all'avvio di una nuova build. Attualmente si può rimediare usando i job object di Windows che permettono di terminare interi alberi di processi. Si usa la speciale utility "process launcher" chiamata "dojob . Questa procedura richiede anche che si modifichi la configurazione di Buildbot per il builder.

Scaricare dojob.cpp e compilarlo con

  cl dojob.cpp

Poi, mettere dojob.exe in una directory che si trova nella variabile PATH. Modificare la configurazione di Buildbot perché usi "dojob" per ogni comando, sostituendo "cmd /c", per esempio

factory.addStep(Compile(
        name = "cmake",
        command=["dojob", WithProperties("cd c:\\buildbot\\%(buildername)s\\build && cmake .")]
));

L'eccezione di Buildbot ShellCommand.failed: command failed: SIGKILL failed to kill process

(Vista molto raramente?). Solitamente accade dopo aver ritentato diverse volte dei test che falliscono. Sembra che l'opzione --retries= di MTR non sia sicura su Windows. La soluzione è eseguire il test senza usarla.

L'eccezione di Buildbot Connection to the other side was lost in a non-clean fashion.

E' sintomo di problemi di rete intermittenti, che fanno sì che Buildbot abortisca completamente la build corrente. Si può rimediare in uno dei seguenti modi:

• Nel file buildbot.tac specificare un valore keepalive pià elevato, come 60000.
• Se si sta eseguendo Windows come host dentro VMWare, sostituire la scheda di rete e1000 con vmxnet3
• Se l'host della build è dietro un firewall, è meglio che il firewall non abbia un time out troppo breve per le connessioni inattive. Configurare un time out di almeno 24 ore.
• Se l'host della build è dietro un firewall, è meglio disabilitare il Windows Firewall per evitare una potenziale causa di problemi.
• Modificare la voce di registro KeepAliveTime con un valore più basso, come 60000 (uguale a 60 secondi). Per ulteriori informazioni, si veda TechNet
• Accertarsi che il master Buildbot non abbia picchi prolungati di attività della CPU al 100%, perché in questo caso i keepalive non funzionano. Se dal log del master Buildbot twisted.log risulta che i dati vengono frequentemente caricati dal disco, incrementare il valore buildCacheSize nel file di configurazione del master in modo che sia maggiore per numero di build per ogni builder.

Configurazione alternativa di Buildbot per Windows (sperimentale)

Se la configurazione predefinita di Buildbot per Windows non è sufficientemente affidabile a causa di errori "connection lost in a non-clean fashion", si può utilizzare la seguente. Esegue il demone buildbot su un host Linux mentre effettua le build su Windows, aggirando così i problemi di Twisted su Windows.

Si noti che la procedura seguente riduce _significativamente_ la sicurezza complessiva dell'host Windows. Si raccomanda caldamente di usare un firewall standalone su una macchina virtuale.

• Impostare il server Windows per il login automatico, con l'utente che eseguirà la build. Questo previene problemi causati dall'esecuzione di programmi come servizi, e ci libera dalle considerazioni relative a quei servizi;

• Installare FreeSSHd su Windows. La combinazione OpenSSHd/Cygwin non dovrebbe funzionare.
  • Non eseguire FreeSSHd come servizio, ma piuttosto come applicazione lanciata automaticamente su console all'avvio della sessione utente che esegue le builds. Questo permette alla UI di FreeSSHd di funzionare correttamente;
  • Generare una coppia di chiavi usando PuTTYGen e inserire la parte pubblica in un file con il nome corretto, nella directory delle chiavi specificata nella GUI di FreeSSHd
  • Usando la GUI di FreeSSHd, creare un nuovo utente e impostarlo perché usi l'autenticazione con chiave;
  • Impostare la home path di SFTP alla directory in cui avverranno le build.

• Disabilitare UAC (User Access Control) (o impostarlo al livello più basso) utilizzando il Users Control Panel. Aggiungere l'utente buildbot al gruppo Administrators.

• Esportare la chiave privata da PuTTYGen e copiarla in un host Linux.

• Installare buildbot sull'host Linux.

• Il file di configurazione di buildbot assomiglierà a quanto segue:

f_win2008r2_i386_release.addStep(ShellCommand(
        command=["ssh", "-i", "/home/buildbot/keys/id_rsa", "buildbot@win2008r2-build", "cmd", "/C", "whoami"]
));

Le seguenti considerazioni sono valide per questa configurazione:

• buildbot non esegue una pulizia appropriata della directory delle build sull'host Windows prima di ogni build (pulisce solo sul lato Linux). Per questo motivo, come prima cosa deve essere effettuata una pulizia della directory con rmdir;
• Bzr() non può essere usato per il checkout dei rami BZR, perché si aspetta che il comando bzr checkout venga eseguito localmente. Perciò bisogna usare una chiamata implicita bzr checkout tramite un comando SSH;