GitHub Actions e .NET
In questa panoramica si forniranno informazioni sul ruolo svolto da GitHub Actions 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.
Azioni di GitHub
GitHub Actions rappresenta comandi autonomi, ad esempio:
- actions/checkout: questa azione estrae il repository in
$GITHUB_WORKSPACE, in modo che il flusso di lavoro possa accedervi. - actions/setup-dotnet Questa azione configura un ambiente dell'interfaccia della riga di comando .NET da usare nelle azioni.
- dotnet/versionsweeper: questa azione esegue lo sweep dei repository .NET alla ricerca di versioni di destinazione di .NET non più supportate.
Anche se questi comandi sono isolati in una singola azione, risultano molto efficaci tramite la composizione del flusso di lavoro. Nella composizione del flusso di lavoro si definiscono gli eventi che attivano il flusso. Quando un flusso di lavoro è in esecuzione, sono disponibili vari processi che devono essere eseguiti. Ogni processo definisce un numero qualsiasi di passaggi. I passaggi delegano a GitHub Actions o in alternativa chiamano script da riga di comando.
Per altre informazioni, vedere Introduzione a GitHub Actions. Si pensi a un file del flusso di lavoro come a 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.
GitHub Actions personalizzate
Anche se nel Marketplace sono disponibili molte GitHub Actions, è possibile creare azioni personalizzate. È possibile creare GitHub Actions che eseguono applicazioni .NET. Per altre informazioni, vedere 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 altre informazioni, vedi Sintassi del flusso di lavoro per GitHub Actions.
Esempio di file del flusso di lavoro
Esistono molti esempi di file di flusso di lavoro .NET forniti come esercitazioni e guide introduttive. Ecco alcuni esempi validi di nomi di file del flusso di lavoro:
Nome file del flusso di lavoro
Descrizione
Compila il codice sorgente. Se il codice sorgente non viene compilato, l'operazione avrà esito negativo.
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.
Crea pacchetti e pubblica il codice sorgente in una destinazione.
Analizza il codice per individuare le vulnerabilità di sicurezza e gli errori di codifica. Eventuali vulnerabilità individuate potrebbero causare errori.
Segreti crittografati
Per usare segreti crittografati nei file del flusso di lavoro, fare riferimento ai segreti usando la sintassi dell'espressione del flusso di lavoro dal contesto di ambiente secrets.
${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret
I valori dei segreti non vengono mai stampati nei log. 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 sono simili ai seguenti:
MY_SECRET_VALUE: ***
Importante
Il contesto secrets fornisce il token di autenticazione GitHub con ambito nel repository, nel ramo e nell'azione. Viene fornito da GitHub senza alcun intervento dell'utente:
${{ secrets.GITHUB_TOKEN }}
Per altre informazioni, vedere Uso di segreti crittografati in un flusso di lavoro.
Eventi
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:
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 eventi (processo cron) pianificato per un flusso di lavoro:
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 l'oggetto cron del '0 0 1 * *' che attiverà l'esecuzione 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 per 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:
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 lo capisce e l'interfaccia utente cambia dinamicamente per richiedere all'utente di specificare il motivo per l'esecuzione manuale del flusso di lavoro. L'oggetto steps stamperà il motivo fornito dall'utente.
Per altre informazioni, vedere Eventi che attivano flussi di lavoro.
CLI .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. L'interfaccia della riga di comando di .NET viene usata per run come parte di un steps singolo all'interno di un file di flusso di lavoro. Il comando comune include:
Per altre informazioni, vedere Panoramica dell'interfaccia della riga di comando di .NET
Vedi anche
Per un'analisi più approfondita di GitHub Actions con .NET, prendere in considerazione le risorse seguenti:
Guida/e introduttiva/e:
Esercitazione/i:
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per