Leggere in inglese

Condividi tramite

GitHub Actions e .NET

  • Articolo

In questa panoramica si apprenderà quale ruolo GitHub Actions svolgere nello sviluppo di applicazioni .NET. GitHub Actions consente ai repository di codice sorgente di automatizzare l'integrazione continua (CI) e il recapito continuo (CD). Oltre a ciò, GitHub Actions espone scenari più avanzati, fornendo hook per l'automazione con revisioni del codice, gestione dei rami e valutazione dei problemi. Con il codice sorgente .NET in GitHub è possibile sfruttare GitHub Actions in molti modi.

GitHub Actions

GitHub Actions rappresenta comandi autonomi, ad esempio:

  • azioni/checkout: questa azione esegue il checkout del repository sotto $GITHUB_WORKSPACE, in modo che il flusso di lavoro possa accedervi.
  • actions/setup-dotnet: quest'azione configura un ambiente CLI .NET per l'uso nelle azioni.
  • dotnet/versionsweeper: questa azione esegue una scansione dei repository .NET per le versioni di destinazione non supportate di .NET.

Anche se questi comandi sono isolati in una singola azione, sono potenti tramite composizione del flusso di lavoro. Nella composizione del flusso di lavoro si definiscono gli eventi che attivano il flusso di lavoro. Quando un flusso di lavoro è in esecuzione, ci sono vari processi che deve eseguire. Ogni lavoro definisce un numero indeterminato di passaggi . I passaggi delegano a GitHub Actions o in alternativa chiamano gli script della riga di comando.

Per ulteriori informazioni, vedere Introduzione a GitHub Actions. Si pensi a un file del flusso di lavoro come una composizione che rappresenta i vari passaggi per compilare, testare e/o pubblicare un'applicazione. Sono disponibili molti comandi dell'interfaccia della riga di comando di .NET, la maggior parte dei quali può essere usata nel contesto di un'azione GitHub.

Azioni GitHub personalizzate

Anche se in Marketplaceè disponibile un sacco di GitHub Actions, è consigliabile crearne uno personalizzato. È possibile creare GitHub Actions che eseguono applicazioni .NET. Per ulteriori informazioni, consulta Esercitazione: Creare un'azione GitHub con .NET.

File del flusso di lavoro

GitHub Actions viene usato tramite un file del flusso di lavoro. Il file del flusso di lavoro deve trovarsi nella directory .github/workflows del repository e deve essere YAML (*.yml o *.yaml). I file del flusso di lavoro definiscono la composizione del flusso di lavoro . Un flusso di lavoro è un processo automatizzato configurabile costituito da uno o più processi. Per ulteriori informazioni, vedere la sintassi del flusso di lavoro per GitHub Actions.

File del flusso di lavoro di esempio

Esistono molti esempi di file workflow .NET forniti come tutorial e quickstart. Ecco alcuni esempi validi di nomi di file del flusso di lavoro:

nome file del flusso di lavoro

Descrizione

build-validation.yml

Compila (o costruisce) il codice sorgente. Se il codice sorgente non viene compilato, l'operazione avrà esito negativo.

build-and-test.yml

Esegue gli unit test all'interno del repository. Per eseguire i test, è necessario prima compilare il codice sorgente, ovvero un flusso di lavoro di compilazione e di test ,che sostituisce il flusso di lavoro build-validation.yml. Gli unit test non superati causeranno un errore del flusso di lavoro.

publish-app.yml

Crea pacchetti e pubblica il codice sorgente in una destinazione.

codeql-analysis.yml

Analizza il codice per individuare le vulnerabilità di sicurezza e gli errori di codifica. Eventuali vulnerabilità individuate potrebbero causare errori.

Segreti crittografati

Per utilizzare i segreti crittografati nei file di workflow, fai riferimento ai segreti usando la sintassi dell'espressione del flusso di lavoro dall'oggetto di contesto secrets.

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

I valori segreti non vengono mai registrati nei registri. I nomi vengono invece stampati con un asterisco che rappresenta i relativi valori. Ad esempio, quando ogni passaggio viene eseguito all'interno di un processo, tutti i valori usati vengono restituiti nel log azioni. I valori dei segreti appaiono simili ai seguenti:

Console 
MY_SECRET_VALUE: ***

Importante

Il contesto secrets fornisce il token di autenticazione GitHub relativo al repository, al ramo e all'azione. Viene fornito da GitHub senza alcun intervento dell'utente:

yml 
${{ secrets.GITHUB_TOKEN }}

Per altre informazioni, vedere Uso di segreti crittografati in un flusso di lavoro.

Avvenimenti

I flussi di lavoro vengono attivati da molti tipi diversi di eventi. Oltre agli eventi webhook, che sono i più comuni, esistono anche eventi pianificati ed eventi manuali.

Esempio di evento webhook

L'esempio seguente illustra come specificare un trigger di eventi webhook per un flusso di lavoro:

yml 
name: code coverage

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

jobs:
  coverage:

    runs-on: ubuntu-latest

    # steps omitted for brevity

Nel flusso di lavoro precedente, gli eventi push e pull_request attiveranno l'esecuzione del flusso di lavoro.

Esempio di evento pianificato

L'esempio seguente illustra come specificare un trigger di evento pianificato (processo cron) per un flusso di lavoro:

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

jobs:
  build:
    runs-on: ubuntu-latest

    # steps omitted for brevity

Nel flusso di lavoro precedente, l'evento schedule specifica il cron di '0 0 1 * *' che attiverà l'avvio del flusso di lavoro il primo giorno di ogni mese. L'esecuzione di flussi di lavoro in base a una pianificazione è ideale per i flussi di lavoro che richiedono molto tempo per l'esecuzione o l'esecuzione di azioni che richiedono meno attenzione.

Esempio di evento manuale

L'esempio seguente illustra come specificare un trigger di eventi manuale per un flusso di lavoro:

yml 
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

Nel flusso di lavoro precedente, l'evento workflow_dispatch richiede un reason come input. GitHub visualizza questo e l'interfaccia utente cambia dinamicamente per richiedere all'utente di specificare il motivo per l'esecuzione manuale del flusso di lavoro. Il steps stamperà il motivo fornito dall'utente.

Per altre informazioni, vedere Eventi che attivano flussi di lavoro.

CLI di .NET

L'interfaccia della riga di comando di .NET è una toolchain multipiattaforma per lo sviluppo, la compilazione, l'esecuzione e la pubblicazione di applicazioni .NET. La .NET CLI viene utilizzata per run come parte di singoli steps all'interno di un file del flusso di lavoro. I comandi comuni includono:

Per altre informazioni, vedere panoramica dell'interfaccia della riga di comando di .NET .

Vedere anche

Per un'analisi più approfondita di GitHub Actions con .NET, prendere in considerazione le risorse seguenti: