Bamboo Limit Concurrent Builds über Niederlassungen

Question

Wir haben eine kleine Anzahl von gemeinsamen Datenbanken für Integrationstests und eine große Anzahl von Niederlassungen, die diese teilen. Gibt es eine Möglichkeit, zu verhindern, dass Bamboo gleichzeitig versucht, mehrere Zweige mit derselben Datenbank auszuführen?

Wenn Builds in mehreren Verzweigungen parallel ausgeführt werden, überlappen sie einander und schlagen fehl.

Answer 1

Es gibt hervorragende Feature-Anforderungen für diese BAM-12071 und BAM-2423 warten auf Atlassian, um eine Lösung zu implementieren.

In der Zwischenzeit haben wir eine schnelle und dreckige Umgehung dafür entwickelt, basierend auf der Verwendung altmodischer Dateiverriegelung (eigentlich Verzeichnis). Jede Ressource wird mit einem Variablennamen gatekeeper.resource in der Job- oder Branch-Konfiguration definiert. Zu Beginn eines Buildprozesses überprüft eine "Gatekeeper" -Stufe, ob die erforderliche Ressource unter Verwendung eines Verzeichnisnamens in einer gemeinsamen Datei auf einem gemeinsamen Server frei ist. Solange der Verzeichnisname existiert, wird die Ressource verwendet. Die erste Aufgabe der nachfolgenden Erstellungsstufe erstellt den Ressourcennamen als leeres Verzeichnis, und eine letzte Aufgabe entfernt sie. Andere Builds können nicht über die erste Stufe hinausgehen, bis die Ressource frei ist und gleichzeitig Builds stoppen. Der Nachteil ist, dass es einen lokalen Bambus-Agent bindet, und ist nicht völlig narrensicher, aber funktioniert für uns 99% der Zeit. Es funktioniert sogar über Build-Pläne, wenn die Ressourcenvariable korrekt definiert ist.

Sein als SSH Aufgabe gegen eine Linux-Instanz definiert:

# This Gatekeeper stage prevents concurrent builds against a resource 
# by looking for a directory instance in a common file area. 
# If the directory exists the build cannot proceed until it disappears. 
# The build sleeps as long as the directory exists. 
# 
# The first task in the subsequent stage is to create the directory, and 
# a final task in the build removes it. 
# As a failsafe a background half-hourly cron job should remove lock 
# dirs if they exceed 3 x the build time. 
######################################################### 
# Wait for a random number of seconds 20-120 to reduce (but not eliminate) the chance that multiple competing branch 
# builds triggered by timers both see the dir gone and start the unit test job at once and then proceed to clobber each other (i.e a race condition) 
# note: bamboo expects output every 3 minutes so do not increase beyond 180 seconds 
SLEEPYTIME=$(((RANDOM % 100) + 20)) 
echo SLEEPYTIME today is $SLEEPYTIME 
sleep $SLEEPYTIME 
# Wait for the Gatekeeper lock dir to disappear... or be older than 3 hours (previous build may have hung) 
file=/test/atlassian/bamboo-gatekeeper/inuse-${bamboo.gatekeeper.resource} 
while [ -d "$file" ] 
do 
    echo $(date +%H:%M:%S) waiting $SLEEPYTIME seconds... 
    sleep $SLEEPYTIME 
done 
exit 0 

Ersten Job Aufgabe der Build-Phase (nach dem Torwächter):

# This will fail if the lock file (actually a directory!) already exists 
file=/test/atlassian/bamboo-gatekeeper/inuse-${bamboo.gatekeeper.resource} 
mkdir "$file" 

Letzter Schritt der Build-Stufe folgt eine bauen (erfolgreich oder nicht)

file=/test/atlassian/bamboo-gatekeeper/inuse-${bamboo.gatekeeper.resource} 
rm -rf "$file" 

Es gibt auch eine ausfallsichere Cron Clean up t Fragen Sie, dass alle Ressourcen-Gateway-Verzeichnisse entfernt werden, die älter als ein paar Stunden sind (in unserem Fall 3). Sollte nicht notwendig sein, aber verhindert, dass Builds unbegrenzt gebunden werden, falls der Bambus selbst neu gestartet wird, ohne eine abschließende Aufgabe auszuführen.

# This works in conjunction with bamboo unit tests. It clears any unit test lock files after 3 hours (e.g. build has hung or killed without removing lock file) 
15,45 * * * * find /test/atlassian/bamboo-gatekeeper -name inuse* -mmin +180 -delete 

gatekeeper.resource kann als der Name von allem, was Sie wollen, definiert werden. In unserem Fall handelt es sich um ein Datenbankschema, das von Integrationstests verwendet wird. Einige unserer Niederlassungen verwenden eine gemeinsame Testumgebung, andere Niederlassungen haben ihre eigene Instanz. Diese Lösung verhindert, dass Zweige, die die allgemeine Umgebung verwenden, gleichzeitig ausgeführt werden, während Zweigstellen mit ihrer eigenen Umgebung fortfahren können.

Es ist kein vollständiger Fix, um gleichzeitige Builds auf eine bestimmte Anzahl zu beschränken, aber es reicht aus, uns über dieses Problem zu informieren, bis Atlassian eine permanente Lösung implementiert. Ich hoffe, es hilft anderen.