GitHub Actions und .NET

  • Artikel

In dieser Übersicht erfahren Sie, welche Rolle GitHub Actions bei der Entwicklung von .NET-Anwendungen spielt. GitHub Actions ermöglicht es Ihren Quellcoderepositorys, Continuous Integration (CI) und Continuous Delivery (CD) zu automatisieren. Darüber hinaus macht GitHub Actions komplexere Szenarien verfügbar, indem Hooks für die Automatisierung mit Code Reviews, Branchverwaltung und Problemtriage bereitstellt werden. Mit Ihrem .NET-Quellcode in GitHub können Sie GitHub Actions auf vielfältige Weise nutzen.

GitHub Actions

GitHub Actions stellt eigenständige Befehle dar, darunter:

  • actions/checkout: Diese Aktion checkt Ihr Repository unter $GITHUB_WORKSPACE aus, damit Ihr Workflow darauf zugreifen kann.
  • actions/setup-dotnet: Mit dieser Aktion wird eine .NET CLI-Umgebung für die Verwendung in Aktionen eingerichtet.
  • dotnet/versionsweeper: Mit dieser Aktion werden .NET-Repositorys nach nicht unterstützten Zielversionen von .NET durchsucht.

Diese Befehle sind zwar für eine einzelne Aktion isoliert, sind aber durch Workflowkomposition leistungsfähig. Bei Workflowkomposition definieren Sie die Ereignisse, die den Workflow auslösen. Sobald ein Workflow ausgeführt wird, gibt es verschiedene Aufträge, mit deren Ausführung er beauftragt wird. Jeder Auftrag definiert eine beliebige Anzahl von Schritten. Die Schritte delegieren Aufgaben an GitHub Actions oder rufen alternativ Befehlszeilenskripts auf.

Weitere Informationen finden Sie unter Einführung in GitHub Actions. Stellen Sie sich eine Workflowdatei als eine Komposition vor, die die verschiedenen Schritte zum Erstellen, Testen und/oder Veröffentlichen einer Anwendung darstellt. Es sind viele .NET CLI-Befehle verfügbar, von denen die meisten im Kontext einer GitHub-Aktion verwendet werden können.

Benutzerdefinierte GitHub Actions-Vorgänge

In Marketplace sind viele GitHub Actions-Vorgänge verfügbar, aber Sie können auch ihre eigenen Aktionen erstellen. Sie können GitHub Actions-Vorgänge erstellen, die .NET-Anwendungen ausführen. Weitere Informationen finden Sie unter Tutorial: Erstellen einer GitHub-Aktion mit .NET.

Workflowdatei

GitHub Actions-Vorgänge werden über eine Workflowdatei genutzt. Die Workflowdatei muss sich im Verzeichnis .github/workflows des Repositorys befinden und muss YAML sein (entweder „*.yml“ oder „*.yaml“). Workflowdateien definieren die Workflowkomposition. Ein Workflow ist ein konfigurierbarer automatisierter Prozess, der aus mindestens einem Jobs besteht. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Beispielworkflowdateien

Es gibt viele Beispiele für .NET-Workflowdateien, die als Tutorials und Schnellstarts bereitgestellt werden. Im Folgenden finden Sie einige gute Beispiele für Workflowdateinamen:

Workflowdateiname

Beschreibung

build-validation.yml

Kompiliert (oder erstellt) den Quellcode. Wenn der Quellcode nicht kompiliert wird, schlägt dieser Vorgang fehl.

build-and-test.yml

Führt die Komponententests innerhalb des Repositorys aus. Um Tests auszuführen, muss der Quellcode zuerst kompiliert werden. Dies ist eigentlich sowohl ein Build- als auch ein Testworkflow (er würde den Workflow build-validation.yml ersetzen). Fehlerhafte Komponententests führen zu Workflowfehlern.

publish-app.yml

Erstellt Pakete und veröffentlicht den Quellcode in einem Ziel.

codeql-analysis.yml

Analysiert Ihren Code auf Sicherheitslücken und Codierungsfehler. Alle ermittelten Sicherheitsrisiken können zu Fehlern führen.

Verschlüsselte Geheimnisse

Um verschlüsselte Geheimnisse in Ihren Workflowdateien zu verwenden, verweisen Sie mithilfe der Workflowausdruckssyntax aus dem secrets-Kontextobjekt auf die Geheimnisse.

${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret

Geheimniswerte werden nie in die Protokolle ausgegeben. Stattdessen werden ihre Namen mit einem Sternchen ausgegeben, das ihre Werte darstellt. Wenn beispielsweise jeder Schritt innerhalb eines Auftrags ausgeführt wird, werden alle Werte, die er verwendet, an das Aktionsprotokoll ausgegeben. Geheimniswerte werden ähnlich wie im folgenden Beispiel gerendert:

MY_SECRET_VALUE: ***

Wichtig

Der secrets-Kontext stellt das GitHub-Authentifizierungstoken bereit, das auf das Repository, den Branch und die Aktion bezogen ist. Es wird von GitHub ohne Benutzereingriff bereitgestellt:

${{ secrets.GITHUB_TOKEN }}

Weitere Informationen finden Sie unter Verwenden verschlüsselter Geheimnisse in einem Workflow.

Ereignisse

Workflows werden durch viele verschiedene Ereignistypen ausgelöst. Neben Webhookereignissen, die am häufigsten vorkommen, gibt es auch geplante Ereignisse und manuelle Ereignisse.

Beispiel für ein Webhookereignis

Im folgenden Beispiel wird gezeigt, wie ein Webhookereignistrigger für einen Workflow angegeben wird:

name: code coverage

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main, staging

jobs:
  coverage:

    runs-on: ubuntu-latest

    # steps omitted for brevity

Im vorherigen Workflow lösen die Ereignisse push und pull_request die Ausführung des Workflows aus.

Beispiel für ein geplantes Ereignis

Das folgende Beispiel zeigt, wie ein geplanter Ereignistrigger (Cron-Auftrag) für einen Workflow angegeben wird:

name: scan
on:
  schedule:
  - cron: '0 0 1 * *'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    # steps omitted for brevity

Im vorherigen Workflow gibt das schedule-Ereignis cron von '0 0 1 * *' an. Die Ausführung des Workflows wird also am ersten Tag jedes Monats ausgelöst. Das Ausführen von Workflows nach einem Zeitplan eignet sich hervorragend für Workflows, deren Ausführung sehr lange dauert oder die Aktionen ausführen, die weniger häufig Aufmerksamkeit erfordern.

Beispiel für ein manuelles Ereignis

Im folgenden Beispiel wird gezeigt, wie ein manueller Ereignistrigger für einen Workflow angegeben wird:

name: build
on:
  workflow_dispatch:
    inputs:
      reason:
        description: 'The reason for running the workflow'
        required: true
        default: 'Manual run'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: 'Print manual run reason'
        if: ${{ github.event_name == 'workflow_dispatch' }}
        run: |
          echo 'Reason: ${{ github.event.inputs.reason }}'

    # additional steps omitted for brevity

Im vorherigen Workflow erfordert das workflow_dispatch-Ereignis einen reason als Eingabe. GitHub erkennt dies und ändert die Benutzeroberfläche dynamisch, um den Benutzer zur Angabe des Grunds für die manuelle Ausführung des Workflows aufzufordern. steps gibt den vom Benutzer angegebenen Grund aus.

Weitere Informationen findest du unter Ereignisse, die Workflows auslösen.

.NET CLI

Die .NET-Befehlszeilenschnittstelle (CLI) ist eine plattformübergreifende Toolkette zum Entwicklung, Erstellen, Ausführen und Veröffentlichen von .NET-Anwendungen. Die .NET CLI wird als Teil einzelner steps innerhalb einer Workflowdatei ausgeführt (run). Häufig verwendete Befehle sind:

Weitere Informationen finden Sie unter Übersicht über die .NET CLI.

Siehe auch

Eine ausführlichere Betrachtung von GitHub Actions mit .NET finden Sie in den folgenden Ressourcen: