Delen via

GitHub Actions en .NET

  • Artikel

In dit overzicht leert u welke rol GitHub Actions spelen in .NET-toepassingsontwikkeling. Met GitHub Actions kunnen uw broncodeopslagplaatsen continue integratie (CI) en continue levering (CD) automatiseren. Bovendien maken GitHub Actions geavanceerdere scenario's mogelijk, waarbij automatiseringshooks worden geboden voor codebeoordelingen, het beheer van vertakkingen en het prioriteren van problemen. Met uw .NET-broncode in GitHub kunt u gitHub Actions op veel manieren gebruiken.

GitHub Actions

GitHub Actions vertegenwoordigen zelfstandige opdrachten, zoals:

  • acties/uitchecken: met deze actie wordt uw opslagplaats uitgecheckt onder $GITHUB_WORKSPACE, zodat uw werkstroom er toegang toe heeft.
  • actions/setup-dotnet - Deze actie installeert een .NET CLI-omgeving voor gebruik in acties.
  • dotnet/versionsweeper : Deze actie doorzoekt .NET-opslagplaatsen voor niet-ondersteunde doelversies van .NET.

Hoewel deze opdrachten zijn geïsoleerd tot één actie, zijn ze krachtig via werkstroomsamenstelling. In werkstroomsamenstelling definieert u de gebeurtenissen die de werkstroom activeren. Zodra een werkstroom wordt uitgevoerd, zijn er verschillende taken die hij moet uitvoeren. Elke taak definieert een willekeurig aantal stappen. De stappen delegeren aan GitHub Actions of opdrachtregelscripts aanroepen.

Zie Inleiding tot GitHub Actionsvoor meer informatie. U kunt een werkstroombestand beschouwen als een samenstelling die de verschillende stappen vertegenwoordigt voor het bouwen, testen en/of publiceren van een toepassing. Veel .NET CLI-opdrachten beschikbaar zijn, waarvan de meeste kunnen worden gebruikt in de context van een GitHub Action.

Aangepaste GitHub Actions

Hoewel er veel GitHub Actions beschikbaar zijn in de Marketplace-, kunt u uw eigen acties ontwerpen. U kunt GitHub Actions maken waarop .NET-toepassingen worden uitgevoerd. Zie Zelfstudie: Een GitHub-actie maken met .NETvoor meer informatie.

Werkstroombestand

GitHub Actions worden gebruikt via een werkstroombestand. Het werkstroombestand moet zich in het .github/workflows bevinden map van de opslagplaats en is naar verwachting YAML (ofwel *.yml of *.yaml). Werkstroombestanden definiëren de werkstroomsamenstelling. Een werkstroom is een configureerbaar geautomatiseerd proces dat bestaat uit een of meer taken. Zie Werkstroomsyntaxis voor GitHub Actionsvoor meer informatie.

Voorbeeldbestanden voor workflows

Er zijn veel voorbeelden van .NET-werkstroombestanden die worden aangeboden als zelfstudies en quickstarts. Hier volgen enkele goede voorbeelden van namen van werkstroombestanden:

naam van het werkstroombestand

Beschrijving

build-validation.yml

Compileert (of bouwt) de broncode. Als de broncode niet wordt gecompileerd, mislukt dit.

build-and-test.yml

Voert de eenheidstests uit binnen de repository. Als u tests wilt uitvoeren, moet de broncode eerst worden gecompileerd. Dit is eigenlijk zowel een build- als testwerkstroom (deze vervangt de build-validation.yml werkstroom). Mislukte eenheidstests veroorzaken een werkstroomfout.

publish-app.yml

Pakt de broncode in en publiceert deze naar een bestemming.

codeql-analysis.yml

Analyseert uw code voor beveiligingsproblemen en coderingsfouten. Eventuele gedetecteerde beveiligingsproblemen kunnen fouten veroorzaken.

Versleutelde geheimen

Als u versleutelde geheimen in uw werkstroombestanden wilt gebruiken, verwijst u naar de geheimen met behulp van de syntaxis van de werkstroomexpressie van het secrets contextobject.

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

Geheime waarden worden nooit afgedrukt in de logboeken. In plaats daarvan worden hun namen afgedrukt met een sterretje dat hun waarden vertegenwoordigt. Als elke stap bijvoorbeeld binnen een taak wordt uitgevoerd, worden alle waarden die worden gebruikt, uitgevoerd in het actielogboek. Geheime waarden worden ongeveer als volgt weergegeven:

MY_SECRET_VALUE: ***

Belangrijk

De secrets context biedt het GitHub-authenticatietoken dat betrekking heeft op de repository, branch en actie. Het wordt geleverd door GitHub zonder tussenkomst van de gebruiker:

${{ secrets.GITHUB_TOKEN }}

Zie Versleutelde geheimen gebruiken in een werkstroomvoor meer informatie.

Gebeurtenissen

Werkstromen worden geactiveerd door veel verschillende typen gebeurtenissen. Naast Webhook-gebeurtenissen, die het meest voorkomen, zijn er ook geplande gebeurtenissen en handmatige gebeurtenissen.

Voorbeeld van een webhook-gebeurtenis

In het volgende voorbeeld ziet u hoe u een webhook-gebeurtenistrigger voor een werkstroom opgeeft:

name: code coverage

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

jobs:
  coverage:

    runs-on: ubuntu-latest

    # steps omitted for brevity

In de voorgaande werkstroom zullen de gebeurtenissen push en pull_request de werkstroom starten.

Voorbeeld van geplande gebeurtenis

In het volgende voorbeeld ziet u hoe u een geplande gebeurtenistrigger (cron-taak) voor een werkstroom opgeeft:

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

jobs:
  build:
    runs-on: ubuntu-latest

    # steps omitted for brevity

In de voorgaande werkstroom geeft de schedule gebeurtenis de cron van '0 0 1 * *' op die de werkstroom op de eerste dag van elke maand activeert. Het uitvoeren van werkstromen volgens een planning is ideaal voor werkstromen die lang duren voordat ze worden uitgevoerd of acties uitvoeren waarvoor minder frequente aandacht is vereist.

Voorbeeld van handmatige gebeurtenis

In het volgende voorbeeld ziet u hoe u een handmatige gebeurtenistrigger voor een werkstroom opgeeft:

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

In de voorgaande werkstroom vereist de workflow_dispatch gebeurtenis een reason als invoer. GitHub ziet dit en de gebruikersinterface wijzigt dynamisch om de gebruiker te vragen de reden op te geven voor het handmatig uitvoeren van de workflow. De steps drukt de opgegeven reden van de gebruiker af.

Zie gebeurtenissen die werkstromen activerenvoor meer informatie.

.NET CLI

De .NET-opdrachtregelinterface (CLI) is een platformoverschrijdende hulpprogrammaketen voor het ontwikkelen, bouwen, uitvoeren en publiceren van .NET-toepassingen. De .NET CLI wordt gebruikt om te run als onderdeel van afzonderlijke steps binnen een werkstroombestand. Algemene opdrachten zijn onder andere:

Zie .NET CLI-overzichtvoor meer informatie.

Zie ook

Bekijk de volgende bronnen voor een uitgebreider overzicht van GitHub Actions met .NET: