• entwickelt wird nicht auf dem Master-Branch
• es wird auf Development-Branches gearbeitet
• diese werden gepusht

git push --set-upstream origin <Branchname>

• in dem Moment wird CI/CD ausgeführt
• die tauchen dann in Branches auf und dort kann ein Merge-Request angefordert werden
• die Merge-Requests tauchen dann in Merge requests auf

• Sind die Regeln/Tools die bei bestimmten Ereignissen ausgeführt werden sollen
  • zum Beispiel bei Push um den Code zu verifizieren
  • oder zu bestimmten Zeiten um ein Release zu bauen

• Pipelines → oberster Container
• Stages → die Stufen die abgearbeitet werden sollen
  • Stages werden nacheinander ausgeführt → Code prüfen, kompilieren, ausrollen
  • beinhalten Jobs
  • Jobs der gleichen Stage können parallel zueinander ausgeführt werden
• Jobs → definieren was getan werden soll
  • Jobs werden durch Runner ausgeführt
• Runner → Systeme die die Jobs entgegennehmen
  • genaugenommen ist es Software auf einem Host der die Aufträge entgegen nimmt
  • Runner starten zum Beispiel VMs oder Container auf denen dann die Executor laufen
• Executor → Systeme die die Jobs ausführen
  • genaugenommen ist es wieder ein Softwareclient
  • der cloned das Repository
  • holt sich Artefakte
  • führt dann den eigentlich Job darauf aus

• liegt im root des Repositories
• definiert was nacheinander auszuführen ist (Stages)
  • können Verify-Prozesse sein
  • können Build-Prozesse sein
• formuliert in yaml

variables:
    GIT_DEPTH: 0         

default:
    image: snom/sina-portal:2

stages:
  - static_analyses

pylint_commit:
    stage: static_analyses
    before_script:
        - echo "Installing pylint"
        - pip3 install pylint
    script:
        - echo "$CI_COMMIT_SHA"
        - echo "$CI_COMMIT_BEFORE_SHA"
        - last_ret=0
        - pythonfiles=$(git diff --name-only $CI_COMMIT_SHA $CI_COMMIT_BEFORE_SHA | grep -E '*.py$') || last_ret=$?
        - >
            if [[ $last_ret -eq 0 ]]; then echo "linting '$pythonfiles'"; pylint --max-line-length=120 --output-format=text
            --disable=import-error  --reports=n --ignore='sphinx_conf.py,common_types_pb2_grpc.py,common_types_pb.py,
            phone_system_service_pb2_grpc.py,phone_system_service_pb2.py,qa_service_pb2_grpc.py,qa_service_pb2.py,
            settings_service_pb2_grpc.py,settings_service_pb2.py' $pythonfiles; else echo "Skipped, no python 
            files to lint"; fi
    rules:
            - if: $CI_PIPELINE_SOURCE == "push"


pylint_merge:
    stage: static_analyses
    before_script:
        - echo "Installing pylint"
        - pip3 install pylint
    script:
        - echo "$CI_COMMIT_SHA"
        - echo "$CI_COMMIT_BEFORE_SHA"
        - last_ret=0
        - pythonfiles=$(git diff --name-only origin/$CI_DEFAULT_BRANCH... | grep -E '*.py$') || last_ret=$?
        - >
            if [[ $last_ret -eq 0 ]]; then echo "linting '$pythonfiles'"; pylint --max-line-length=120 --output-format=text
            --disable=import-error  --reports=n --ignore='sphinx_conf.py,common_types_pb2_grpc.py,common_types_pb.py,
            phone_system_service_pb2_grpc.py,phone_system_service_pb2.py,qa_service_pb2_grpc.py,qa_service_pb2.py,
            settings_service_pb2_grpc.py,settings_service_pb2.py' $pythonfiles; else echo "Skipped, no python 
            files to lint"; fi
    rules:
            - if: $CI_PIPELINE_SOURCE == "merge_request_event"

• Variables definiert globale Variablen
  • GIT_DEPTH definiert wie viele Commits zurück gecloned werden soll
    • normalerweise werden nur einige Commits zurück gecloned (shallow clone)
      • spart Plattenplatz und erhöht Geschwindigkeit
      • das kann nicht ausreichend sein wenn man zum Beispiel nur Dateien prüfen will die zwischen dem aktuellen und dem vorhergehenden Commit angefasst wurdten
• default → Defaults
  • image: Das Image für den Container der die Jobs ausführen soll (per Default)
    • in diesem Fall kommt es von der offiziellen Docker-Registry
• stages → die Stages
  • enthält Liste von Stages
  • ein Stage ist eine Gruppe von Aufgaben → Verification, Building usw.
  • werden nacheinander abgearbeitet
  • bestehen aus mehreren Jobs
  • Jobs können parallel verarbeitet werden
• pylint_commit → Job
  • Jobs können beliebige Namen haben
  • stage: Besagt von welchem Stage der Job ist
  • before_script → Welche Befehle vor der Script-Sektion ausgeführt werden sollen (Vorbereitungen)
    • Liste
    • jeder Listeneintrag ist ein Shell-Befehl (die Shell kann geändert werden)
  • script → Script was ausgeführt werden soll als Job
    • Liste
    • jeder Eintrag ist ein Shell-Befehl
      • Variablen vorhergehender Befehle stehen in nachfolgenden Befehlen zur Verfügung
      • wenn ein Befehl fehlschlägt (Return-Code != 0) schlägt der ganze Job fehl
        • es werden keine weiteren Stages ausgeführt
        • es werden keine weiteren Befehle ausgeführt
  • rules → Bedingungen unter denen der Job überhaupt ausgeführt wird
    • if → Definiert eine Bedingung
      • Die Variable CI_PIPELINE_SOURCE definiert was die Pipeline ausgelöst hat
        • u.a. relevant wenn Jobs für Merges ausgeführt werden sollen → das ist normalerweise nicht der Fall, sondern nur bei Commits
        • „push“ → ein Commit
        • „merge_request_event“ → ein Merge-Request
• pylint_merge → ein weiterer Job
  • dieser wird nur für Merge-Requests ausgeführt → siehe rules-Sektion
  • ansonsten ist es weitestgehend gleich zur vorhergehenden Job-Sektion

• funktioniert so lange kein Regel-File im Repository vorhanden ist
• erkennt automatisch die Sprache des Projekts
• baut den Code automatisch
• scannt den Code automatisch entsprechend automatischer Regeln
• testet die Anwendung

• innerhalb des Repositories
• Settings
• CI/CD
• Auto DevOps
• „Default to Auto DevOps pipeline“ anklicken

• generell die Dinge unter Settings
• Settings → Merge Requests
  • Approval
    • wie viele Leute müssen approven damit ein Merge-Request durchgeht
  • Merge Method
    • ob ein Merge-Commit erstellt wird oder nicht
  • Squash commits when merging
    • ob die History des gemergten Branches als solche erhalten bleibt oder gesquast wird
  • Merge checks
    • Ob alle Pipelines erfolgreich durchlaufen worden sein müssen bevor gemerged werden kann → das wird man in der Regel wollen
    • Ob alle Diskussionen beantwortet sein müssen bevor gemerged werden kann
  • Merge suggestions
    • Für die Merge-Message vorgeschlagene Texte
• Settings → Integrations
  • darüber kann man externe Plattformen/Dienste einbinden
    • zum Beispiel Jira als Issue-Tracker
  • eine Alternative dazu ist Webhooks
• Settings → Repository
  • Protected branches → es macht in der Regel den Zugriff auf den Master-Branch zu beschränken/zu deaktivieren, so dass in Feature-Branches gearbeitet wird, die dann gemerged werden
• Settings → CI/CD
  • Runners → erlaubt Runners festzulegen (auf externen Maschinen oder innerhalb von gitlab)