34 Musterlösungen zu den Übungsaufgaben

34.1 1. Einführung in die Job-Definitionen

Aufgabe 1: Erstelle eine .gitlab-ci.yml-Datei mit einem Job, der “Hello World” auf der Konsole ausgibt.
Ziel: Ein einfacher Einstieg, um das Grundgerüst eines GitLab CI Jobs zu verstehen und die Pipeline zu testen.

Musterlösung:

# .gitlab-ci.yml
job_hello_world:
  script:
    - echo "Hello World"

34.2 2. Stages konfigurieren

Aufgabe 2: Erweitere die .gitlab-ci.yml um eine Stage build. Füge einen Job hinzu, der in dieser Stage läuft und die Meldung “Build erfolgreich” ausgibt.
Ziel: Einführung in Stages, um zu zeigen, wie Jobs in verschiedenen Phasen definiert werden können.

Musterlösung:

# .gitlab-ci.yml
stages:
  - build

job_build:
  stage: build
  script:
    - echo "Build erfolgreich"

34.3 3. Bedingte Ausführung mit Branches

Aufgabe 3: Definiere einen Job, der nur im main-Branch läuft. Im main-Branch soll die Ausgabe “Job läuft im Hauptbranch” erscheinen; für alle anderen Branches soll die Nachricht “Job läuft in einem Nebenbranch” erscheinen.
Ziel: Nutzung branchspezifischer Bedingungen zur Steuerung der Job-Ausführung.

Musterlösung:

# .gitlab-ci.yml
stages:
  - test

job_branch_specific:
  stage: test
  script:
    - |
      if [ "$CI_COMMIT_REF_NAME" == "main" ]; then
        echo "Job läuft im Hauptbranch";
      else
        echo "Job läuft in einem Nebenbranch";
      fi
  only:
    - main
    - branches

34.4 4. Einsatz von Variablen

Aufgabe 4: Füge einen Job hinzu, der die Umgebungsvariable MY_VAR liest und auf der Konsole ausgibt. Setze MY_VAR als Pipeline-Variable in GitLab.
Ziel: Einführung in den Einsatz von Umgebungsvariablen innerhalb der Pipeline.

Musterlösung:

# .gitlab-ci.yml
stages:
  - test

job_with_variable:
  stage: test
  script:
    - echo "Die Variable MY_VAR ist: $MY_VAR"

(Hinweis: MY_VAR wird in den Pipeline-Einstellungen von GitLab als Umgebungsvariable definiert.)

34.5 5. Artefakte definieren und speichern

Aufgabe 5: Erstelle einen Job, der eine Textdatei mit einer Nachricht erstellt und diese als Artefakt speichert, sodass sie nach Abschluss der Pipeline heruntergeladen werden kann.
Ziel: Veranschaulichung, wie Artefakte erstellt und in GitLab gespeichert werden.

Musterlösung:

# .gitlab-ci.yml
stages:
  - build

job_with_artifact:
  stage: build
  script:
    - echo "Dies ist ein Artefakt." > artefakt.txt
  artifacts:
    paths:
      - artefakt.txt

34.6 6. Abhängigkeiten zwischen Jobs

Aufgabe 6: Erstelle zwei Jobs, bei denen der zweite Job nur ausgeführt wird, wenn der erste erfolgreich abgeschlossen wurde. Der erste Job soll “Erster Job ausgeführt” ausgeben und eine Datei status.txt erstellen. Der zweite Job soll die Datei lesen und die darin enthaltene Nachricht auf der Konsole ausgeben.
Ziel: Einführung in Abhängigkeiten zwischen Jobs und das Konzept von Artefakten zwischen verschiedenen Jobs.

Musterlösung:

# .gitlab-ci.yml
stages:
  - build
  - test

job_create_file:
  stage: build
  script:
    - echo "Erster Job ausgeführt" > status.txt
  artifacts:
    paths:
      - status.txt

job_read_file:
  stage: test
  script:
    - cat status.txt
  dependencies:
    - job_create_file

34.7 7. Bedingte Ausführung basierend auf Umgebungen

Aufgabe 7: Füge einen Job hinzu, der nur in der production-Umgebung ausgeführt wird und eine Nachricht “Dieser Job läuft nur in der Produktionsumgebung” ausgibt.
Ziel: Verständnis der bedingten Ausführung basierend auf Umgebungen und der Umgebungskonfiguration in GitLab CI.

Musterlösung:

# .gitlab-ci.yml
stages:
  - deploy

deploy_to_production:
  stage: deploy
  script:
    - echo "Dieser Job läuft nur in der Produktionsumgebung"
  environment:
    name: production
  only:
    - main

34.8 8. Parallelisierte Jobs

Aufgabe 8: Erstelle zwei Jobs, die parallel laufen und jeweils eine Nachricht ausgeben (z.B., “Job 1 läuft” und “Job 2 läuft”).
Ziel: Erklären, wie Jobs parallel ausgeführt werden können, um die Pipeline-Zeit zu optimieren.

Musterlösung:

# .gitlab-ci.yml
stages:
  - test

job_parallel_1:
  stage: test
  script:
    - echo "Job 1 läuft"

job_parallel_2:
  stage: test
  script:
    - echo "Job 2 läuft"

34.9 9. Retries bei fehlgeschlagenen Jobs

Aufgabe 9: Definiere einen Job, der bei einem Fehler automatisch bis zu dreimal wiederholt wird. Simuliere im Job einen Fehler durch exit 1.
Ziel: Einführung in das retry-Keyword und das Verständnis, wie Wiederholungen bei fehlgeschlagenen Jobs konfiguriert werden.

Musterlösung:

# .gitlab-ci.yml
stages:
  - test

job_with_retry:
  stage: test
  script:
    - echo "Dieser Job wird bei Fehlern bis zu 2-mal wiederholt."
    - exit 1
  retry: 2

34.10 10. Manuelle und automatisierte Jobs

Aufgabe 10: Erstelle einen Job, der manuell gestartet werden muss und eine Nachricht ausgibt, wenn er aktiviert wird. Ein zweiter Job soll automatisch im Anschluss ausgeführt werden, sobald der manuelle Job erfolgreich abgeschlossen ist.
Ziel: Unterschied zwischen automatisierten und manuellen Jobs kennenlernen und Steuerung der Pipeline-Abläufe.

Musterlösung:

# .gitlab-ci.yml
stages:
  - build
  - deploy

manual_job:
  stage: build
  script:
    - echo "Dieser Job muss manuell gestartet werden."
  when: manual

automatic_job_after_manual:
  stage: deploy
  script:
    - echo "Automatischer Job nach manuellem Start"
  needs: ["manual_job"]

34.11 11. Branch-spezifische Jobs mit only

Aufgabe 11: Erstelle einen Job, der nur ausgeführt wird, wenn er auf einem feature-Branch läuft. Der Job soll die Nachricht “Dieser Job läuft nur auf Feature-Branches” ausgeben.
Ziel: Nutzung des only-Keywords, um Jobs branch-spezifisch zu definieren.

Musterlösung:

# .gitlab-ci.yml
stages:
  - test

job_feature_branch:
  stage: test
  script:
    - echo "Dieser Job läuft nur auf Feature-Branches"
  only:
    - /^feature-.*$/

34.12 12. Ausschluss spezifischer Branches mit except

Aufgabe 12: Erstelle einen Job, der auf allen Branches außer dem main-Branch ausgeführt wird. Der Job soll “Dieser Job wird nicht auf dem main-Branch ausgeführt” ausgeben.
Ziel: Demonstration des except-Keywords zur branch-spezifischen Steuerung der Pipeline.

Musterlösung:

# .gitlab-ci.yml
stages:
  - test

job_except_main:
  stage: test
  script:
    - echo "Dieser Job wird nicht auf dem main-Branch ausgeführt"
  except:
    - main

34.13 13. Verwendung von tags zur Auswahl spezifischer Runner

Aufgabe 13: Erstelle einen Job, der nur auf Runnern mit dem Tag docker ausgeführt wird. Der Job soll “Dieser Job wird nur auf Docker-Runnern ausgeführt” ausgeben.
Ziel: Einsatz des tags-Keywords, um Jobs gezielt auf spezifischen Runnern auszuführen.

Musterlösung:

# .gitlab-ci.yml
stages:
  - build

job_docker_runner:
  stage: build
  script:
    - echo "Dieser Job wird nur auf Docker-Runnern ausgeführt"
  tags:
    - docker

34.14 14. Regeln für Job-Ausführung mit rules

Aufgabe 14: Erstelle einen Job, der abhängig vom Commit-Message-Inhalt ausgeführt wird. Wenn die Commit-Message das Wort “deploy” enthält, soll der Job “Deploy-Job ausgeführt” ausgeben. Andernfalls soll der Job nicht ausgeführt werden.
Ziel: Nutzung des rules-Keywords zur feineren Steuerung der Job-Ausführung basierend auf Bedingungen.

Musterlösung:

# .gitlab-ci.yml
stages:
  - deploy

job_with_rules:
  stage: deploy
  script:
    - echo "Deploy-Job ausgeführt"
  rules:
    - if: '$CI_COMMIT_MESSAGE =~ /deploy/'
      when: always
    - when: never

34.15 15. Kombination von only, rules, und tags

Aufgabe 15: Erstelle einen Job, der nur auf dem main-Branch und nur bei Merges in diesen Branch ausgeführt wird, allerdings nur auf Runnern mit dem Tag production. Der Job soll die Nachricht “Deployment in Produktionsumgebung” ausgeben.
Ziel: Kombination von branch-spezifischen Regeln und Runners, um den Job präzise zu steuern.

Musterlösung:

# .gitlab-ci.yml
stages:
  - deploy

deploy_to_production:
  stage: deploy
  script:
    - echo "Deployment in Produktionsumgebung"
  tags:
    - production
  only:
    - main
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: always
    - when: never