CI-freundliche Git-Repos¶
Im Folgenden möchte ich einige Tipps geben, wie Git-Repositories und Kontinuierliche Integration mit GitLab CI/CD oder GitHub Actions gut zusammenspielen können.
Speichert große Dateien außerhalb eures Repositories¶
Jedes Mal, wenn ein neuer Build erstellt wird, muss das Arbeitsverzeichnis geklont werden. Wenn euer Repository jedoch mit großen Artefakten aufgebläht ist, verlangsamt sich dieser und ihr müsst länger auf die Ergebnisse warten.
Wenn euer Build jedoch von Binaries aus anderen Projekten oder großen Artefakten abhängt, kann ein externes Speichersystem sinnvoll sein, das diejenigen Dateien, die ihr zu Beginn eures Builds im Build-Verzeichnis benötigt, zum Download bereitstellt.
Verwendet Shallow-Clones¶
Jedes Mal, wenn ein Build ausgeführt wird, klont euer Build-Server euer
Projektarchiv in das aktuelle Arbeitsverzeichnis. Dabei klont Git üblicherweise
die gesamte Historie des Repos, wodurch dieser Vorgang mit der Zeit immer länger
dauert. Es sei denn, ihr verwendet sog. Shallow-Clones, bei
denen mit git clone --depth nur der aktuelle Snapshot des Repos und mit
git clone --branch nur der relevante Zweig heruntergezogen wird,
z.B. git clone --depth 1 -b MYBRANCH
REPOSITORY-URL
.
Dies verkürzt die Download-Zeit vor allem bei Repositories mit einer langen Geschichte und vielen Zweigen.
Alternativ könnt ihr --shallow-since
verwenden um Repositories nur von einem
bestimmten Datum an herunterzuladen, z.B. git
clone --shallow-since 1.week.ago REPOSITORY-URL oder :samp:`git clone
--shallow-since 2025-01-21
.
Git kann seit Version 1.9 einfache Änderungen an Dateien, wie z.B. das Aktualisieren einer Versionsnummer, auch in Shallow-Clones vornehmen, ohne dass hierfür die gesamte Historie heruntergeladen wurde.
Warnung
In einem Shallow-Clone kann git fetch
jedoch dazu führen, dass ein fast
vollständiger Commit-Verlauf heruntergeladen wird. Auch andere
Git-Operationen können zu unerwarteten Ergebnissen führen und die
vermeintlichen Vorteile von Shallow-Clones zunichte machen, sodass wir
bei umfangreicheren Operationen empfehlen, eure Shallow-Clone-Repositories
mit git fetch --unshallow
zu vervollständigen. Mit git rev-parse
--is-shallow-repository
könnt ihr anschließend herausfinden, ob euer
Repository nun auch tatsächlich vollständig ist.
Eine andere Möglichkeit, eure Repositories weiterzuverwenden, zeige ich euch im folgenden Abschnitt.
Cache des Repos auf Build-Servern¶
Dies beschleunigt auch das Klonen, da die Repos nur aktualisiert werden müssen.
Bemerkung
Der Cache von Repos ist nur dann von Vorteil, wenn die Build-Umgebung von Build zu Build bestehen bleibt. Wenn euer Build-Agent, z.B. Amazon EC2, den Build wieder abbaut, könnt ihr mit Caching jedoch nichts gewinnen.
Wählt die Trigger mit Bedacht¶
Es versteht sich fast von selbst, dass es eine gute Idee ist, CI auf all euren aktiven Zweigen laufen zu lassen. Aber es ist meist keine gute Idee, alle Builds auf allen Zweigen gegen alle Commits laufen zu lassen.
Üblicherweise geben wir allen im Entwicklungsteam die Möglichkeit, ihre
Zweig-Builds auf Knopfdruck zu erstellen, anstatt sie automatisch auszulösen.
Dies scheint uns ein guter Weg, um ein Gleichgewicht zwischen regelmäßigen Tests
und der Einsparung von Ressourcen zu schaffen. In kritischen Zweigen wie
main
oder stable
werden Builds jedoch automatisch ausgelöst. Zudem
erhalten wir automatisiert auch bei jedem Merge- oder Pull-Request zeitnahe
Testergebnisse.