CI build
GitLab Runner
Typen:
Specific GitLab Runner
Sahred GitLab Runner
Group GitLab Runner
Konfigurationsdateien:
config.toml:
Diese Datei befindet sich auf dem GitLab Server
Enthält die Konfiguration für die einzelnen GitLab Runner
.gilab-ci.yml:
Diese Datei befindet sich standardmäßig im Root-Ordner des Git-Repositories
Enthält die einzelnen Jobs die ausgeführt werden, wenn das Repository durch einen git-push aktualisiert wird.
Beispiel config.toml
concurrent = 8
check_interval = 0
[session_server]
session_timeout = 1800
[[runners]]
name = "clean"
url = "https://git.awinia.lan/"
token = "8BUky95eUg4x411kXhp7"
limit = 8
executor = "shell"
shell = "powershell"
[runners.custom_build_dir]
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
Beschreibung:
concurrent: (global) Definiert über alle existierenden GitLab Runner hinweg die maximale Anzahl der parallel ausgeführten Jobs
token: eindeutig für jeder GitLab Runner. token und url können von der GitLab Webseite entnommen werden.
limit: definiert die maximale Anzahle an Jobs, die von einem GitLab Runner parallel gestartet werden können.
Beispiel .gitlab-ci.yml
variables:
GIT_CLEAN_FLAGS: -f -d -x
cache:
paths:
- name_of_to_cached_file
stages:
- build
- test
- deploy
before_script:
- >
function Build-Linux-Target {
""" do build """
}
- >
function Build-Win-Target {
""" do build """
}
- >
function Run-Tests {
""" do test """
}
- >
function Deploy {
""" do test """
}
job1:
stage: build
artifacts:
expire_in: '10 mins'
paths:
- artifact_name
script:
""" do build """
- Build-Linux-Target
job2:
stage: build
script:
""" do build """
- Build-Win-Target
job3:
stage: test
script:
""" do tests """
- Run-Tests
dependencies:
- artifact_name
job4:
stage: deploy
script:
""" do stuff """
- Deploy
dependencies:
- artifact_name
Beschreibung:
Stages dienen der Gruppierung und Bestimmung der Ausführungsreihenfolge von Jobs. So gibt es in unserem Beispiel 3 Stages (build, test, und deploy). Alle werden im Schlüssel stages zu Beginn der yml-Datei angelegt. Die hier angegebene Reihenfolge legt fest, dass als erstes alle Jobs der Stage build ausgeführt werden müssen, bevor ein Job der Stage test ausgeführt wird
Jobs müssen immer zu einer Stage gehören - bewschrieben durch den Schlüssel stage. Jobs beinhalten die einzelnen Schritte - beschrieben mittels des Schlüssels script - die in diesem Job ausgeführt werden. Gehören mehrere Jobs zu einer Stage können diese prinzipiell parallel ausgeführt werden. Vorausgesetzt die Gitlab Runner Konfiguration ist entsprechend so konfiguriert (concurrent und limit)
cache: mit Hilfe von Caching kann man vermeiden, dass vorhandene Pakete wiederholt installiert werden.
artifacts: Durch diesen Schlüssel werden die Artefakte eines Jobs definiert. Ein Artefakt (Ordner bzw. Dateien), dass in einer Stage von einem Job hergestellt worden ist, kann so von einer zukünftigen Stage weiter verwendet werden. D.h. das Artefakt braucht nur einmal erzeugt zu werden. Neben der klareren Struktur ergibt sich auch hier eine Zeitersparnis, denn das Artefakt braucht nicht erneut generiert zu werden.
dependencies: Hat ein Job eine Abhängigkeit zu einem Artefakt, so kann er nur erfolgreich ausgeführt werden, wenn das Artefakt auch wirklich existiert bzw. generiert worden ist. Mit dem Schlüssel dependencies wird klargestellt, dass ein Job von der Ausführung eines oder mehreren Jobs einer vorher ausgeführten Stage abhängt.