GitHub Actions Job-Abhängigkeiten – Build und Deployment

Einführung

In realen CI/CD-Pipelines bestehen Workflows selten nur aus einer einzigen Liste von Schritten. Sie setzen sich oft aus mehreren unterschiedlichen „Jobs“ zusammen, die in einer bestimmten Reihenfolge ausgeführt werden müssen.

Beispielsweise könnten Sie einen Build-Job haben, der Ihren Code kompiliert, und einen Deploy-Job, der ihn auf einen Server pusht. Sie möchten definitiv nicht, dass der Deploy-Job ausgeführt wird, wenn der Build-Job fehlschlägt, und Sie können sie nicht gleichzeitig ausführen, da das Deployment die gebauten Artefakte benötigt.

In diesem Lab teilen Sie Ihren Workflow in zwei separate Jobs auf und verwenden das Schlüsselwort needs, um eine Abhängigkeit zu erzwingen, wodurch sichergestellt wird, dass der Deploy-Job wartet, bis der Build-Job erfolgreich abgeschlossen ist.

Dieses Lab baut auf dem Repository auf, das Sie in den vorherigen Labs erstellt haben. Sie werden mit dem Repository github-actions-demo arbeiten.

Einen Build-Job definieren

Zuerst werden wir unseren bestehenden Workflow aufräumen, um einen fokussierten build-Job zu haben. Wir vereinfachen die Matrix-Strategie aus dem vorherigen Lab zur besseren Übersichtlichkeit und kehren zu einer einzelnen Version zurück, um den Fokus auf Job-Abhängigkeiten zu legen.

Klicken Sie auf der GitHub-Repository-Seite für github-actions-demo auf die grüne Schaltfläche Code.
Stellen Sie sicher, dass der Reiter HTTPS ausgewählt ist, und kopieren Sie die URL. Sie sollte wie https://github.com/your-username/github-actions-demo.git aussehen.
Öffnen Sie das Terminal in der LabEx-Umgebung. Der Standardpfad ist ~/project.
Verwenden Sie den Befehl git clone, um das Repository herunterzuladen. Ersetzen Sie your-username durch Ihren tatsächlichen GitHub-Benutzernamen.

cd ~/project
git clone https://github.com/your-username/github-actions-demo.git

Beispielausgabe:

Cloning into 'github-actions-demo'...
remote: Enumerating objects: X, done.
remote: Counting objects: 100% (X/X), done.
remote: Total X (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (X/X), done.

Navigieren Sie in das geklonte Repository:

cd ~/project/github-actions-demo

Erstellen Sie eine neue Workflow-Datei .github/workflows/job-dependencies.yml mithilfe des WebIDE-Editors. Sie finden die Datei im Dateiexplorer auf der linken Seite unter project/github-actions-demo/.github/workflows/.
Beginnen Sie mit der Erstellung der grundlegenden Workflow-Struktur. Fügen Sie den Workflow-Namen und den Trigger hinzu:

name: Job Dependencies

on: [push]

Fügen Sie den jobs-Abschnitt hinzu und definieren Sie den build-Job mit seinem Runner:

jobs:
  build:
    runs-on: ubuntu-latest

Fügen Sie den steps-Abschnitt hinzu. Fügen Sie zuerst den Checkout-Schritt hinzu, um den Repository-Code abzurufen:

steps:
  - uses: actions/checkout@v4

Fügen Sie den Node.js-Setup-Schritt hinzu:

- name: Use Node.js
  uses: actions/setup-node@v4
  with:
    node-version: "20"

Fügen Sie den Schritt zum Installieren der Abhängigkeiten hinzu:

- name: Install dependencies
  run: npm install

Fügen Sie den Schritt zum Ausführen der Tests hinzu:

- name: Run tests
  run: npm test

Fügen Sie den Build-Schritt hinzu, der das Artefaktverzeichnis und die Datei erstellt:

- name: Build project
  run: |
    mkdir dist
    echo "Build artifact created at $(date)" > dist/build.txt

Fügen Sie abschließend den Schritt zum Hochladen des Artefakts hinzu. Dieser Schritt ist entscheidend, da er die Build-Ausgabe speichert, damit der nächste Job sie verwenden kann:

- name: Upload build artifact
  uses: actions/upload-artifact@v4
  with:
    name: dist-files
    path: dist

Ihre vollständige Datei sollte nun wie folgt aussehen:

name: Job Dependencies

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: |
          mkdir dist
          echo "Build artifact created at $(date)" > dist/build.txt
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist

Erklärung

Wir haben die matrix-Strategie zur Vereinfachung entfernt.
Wir haben den Schritt Upload build artifact beibehalten. Dies ist entscheidend, da der nächste Job diese Dateien benötigen wird!

Speichern Sie die Datei (Strg+S oder Cmd+S), nachdem Sie Änderungen vorgenommen haben.

Einen Deploy-Job definieren, der den Build benötigt

Nun fügen wir einen zweiten Job namens deploy hinzu. Dieser Job soll nur ausgeführt werden, wenn build erfolgreich ist. Dies erreichen wir durch die Verwendung von needs: build.

Fügen Sie den folgenden deploy-Job zu Ihrer .github/workflows/job-dependencies.yml-Datei hinzu. Stellen Sie sicher, dass er auf derselben Einrückungsebene wie build liegt.
Beginnen Sie mit dem Hinzufügen der Deploy-Job-Definition mit seinem Runner und der Abhängigkeit:

deploy:
  runs-on: ubuntu-latest
  needs: build

Die Zeile needs: build ist entscheidend – sie teilt GitHub Actions mit, dass dieser Job vom erfolgreichen Abschluss des build-Jobs abhängt.

Fügen Sie den steps-Abschnitt hinzu. Fügen Sie zuerst den Schritt zum Herunterladen des Artifacts hinzu:

steps:
  - name: Download artifact
    uses: actions/download-artifact@v4
    with:
      name: dist-files
      path: dist

Dies lädt das Artifact herunter, das im build-Job hochgeladen wurde. Der name muss mit dem im Upload-Schritt verwendeten Namen übereinstimmen.

Fügen Sie den Deploy-Schritt hinzu:

- name: Deploy project
  run: |
    echo "Deploying project..."
    ls -R dist
    echo "Deployment successful!"

Dieser Schritt simuliert eine Bereitstellung, indem die heruntergeladenen Dateien aufgelistet werden.

Ihre vollständige Dateistruktur sollte wie folgt aussehen:

name: Job Dependencies

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build project
        run: |
          mkdir dist
          echo "Build artifact created at $(date)" > dist/build.txt
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: dist-files
          path: dist

  deploy:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Download artifact
        uses: actions/download-artifact@v4
        with:
          name: dist-files
          path: dist
      - name: Deploy project
        run: |
          echo "Deploying project..."
          ls -R dist
          echo "Deployment successful!"

Erklärung

needs: build: Dies ist die Schlüsselzeile. Sie teilt GitHub Actions mit, dass dieser Job vom erfolgreichen Abschluss des build-Jobs abhängt.
uses: actions/download-artifact@v4: Da Jobs auf verschiedenen virtuellen Maschinen laufen, teilen sie keine Dateisysteme. Um den im build-Job erstellten dist-Ordner zu erhalten, müssen wir das zuvor hochgeladene Artifact herunterladen.
name: dist-files: Muss mit dem im Upload-Schritt verwendeten Namen übereinstimmen.

Speichern Sie die Datei (Strg+S oder Cmd+S).

Commit, Push und sequenzielle Ausführung überprüfen

Lassen Sie uns nun überprüfen, ob die Jobs in der richtigen Reihenfolge ausgeführt werden.

Stellen Sie sicher, dass Sie sich im Repository-Verzeichnis befinden:

cd ~/project/github-actions-demo

Stagen Sie die Änderungen:

git add .

Committen Sie die Änderungen:

git commit -m "Add deploy job with dependency on build"

Pushen Sie die Änderungen in das Remote-Repository auf GitHub:

git push

Hinweis zur Authentifizierung:
Wenn Sie git push ausführen, werden Sie von der WebIDE automatisch zur Authentifizierung aufgefordert. Befolgen Sie diese detaillierten Schritte:

Es erscheint ein Popup mit der Meldung: "The extension 'GitHub' wants to sign in using GitHub." Klicken Sie auf Allow.
Es erscheint eine neue Benachrichtigung. Klicken Sie auf "Copy&Continue to GitHub" und anschließend im nächsten Dialog auf "Open".
Melden Sie sich im geöffneten Browserfenster bei Ihrem GitHub-Konto an und geben Sie den kopierten Autorisierungscode ein. Nach Bestätigung der Autorisierung schließt sich die Seite automatisch.
Warten Sie einige Sekunden, und Sie werden sehen, wie das Terminal den Push-Vorgang erfolgreich abschließt.

Datenschutzhinweis: Die WebIDE wird zu Authentifizierungszwecken vollen Zugriff auf Ihr GitHub-Konto anfordern. Sie müssen sich keine Sorgen um Datenschutzbedenken machen – die LabEx VM wird sofort nach Abschluss des aktuellen Labs zerstört, und Ihre Anmelde- und Autorisierungsinformationen werden nicht gespeichert.

Dieser Authentifizierungsprozess erfordert keine manuelle Konfiguration von Benutzername oder Personal Access Token (PAT).

Überprüfung auf GitHub

Besuchen Sie Ihr Repository auf GitHub in einem Webbrowser.
Klicken Sie auf den Tab Actions.
Klicken Sie auf den neuesten Workflow-Lauf.
Betrachten Sie den Visualisierungs-Graph. Sie sollten zwei Kreise (Jobs) sehen, die durch eine Linie verbunden sind.
- Der build-Job befindet sich links.
- Der deploy-Job befindet sich rechts.
Beobachten Sie den Fortschritt. Sie werden feststellen, dass deploy im Status "Pending" oder "Waiting" verharrt, bis build grün (Success) wird.
Sobald build abgeschlossen ist, startet deploy.
Klicken Sie auf die Logs des deploy-Jobs, um die Nachricht "Deploying project..." und die Dateiliste des heruntergeladenen Artifacts zu sehen.

Zusammenfassung

In diesem Lab haben Sie gelernt, wie man Multi-Job-Workflows in GitHub Actions orchestriert. Sie haben:

Separate Jobs für build und deploy erstellt.
Das Schlüsselwort needs verwendet, um eine Abhängigkeit zu definieren, wodurch sichergestellt wird, dass deploy nur nach build ausgeführt wird.
upload-artifact und download-artifact verwendet, um Daten (Dateien) zwischen diesen separaten Jobs zu übergeben.

Dieses Muster ist grundlegend für den Aufbau robuster CI/CD-Pipelines, bei denen Sie einmal bauen und dann nur dann in mehrere Umgebungen (Staging, Produktion) deployen möchten, wenn vorherige Schritte erfolgreich waren.