Gestire azioni e flussi di lavoro

Completato

In questa unità si esploreranno i diversi strumenti e le varie strategie disponibili in GitHub Enterprise Cloud e GitHub Enterprise Server per condividere e gestire GitHub Actions e i flussi di lavoro e gestirne l'utilizzo a livello aziendale.

Il contenuto è strutturato in base al livello in cui sono disponibili gli strumenti presentati: livello di azienda o livello di organizzazione.

Livello di azienda

Configurare i criteri di utilizzo di GitHub Actions

I flussi di lavoro di GitHub Actions contengono spesso azioni, ovvero set di comandi autonomi da eseguire all'interno del flusso di lavoro. Quando si crea un flusso di lavoro, è possibile creare azioni personalizzate oppure fare riferimento alle azioni pubbliche della community disponibili in GitHub Marketplace. Per questo motivo, per impedire agli utenti di eseguire azioni dannose di terze parti, è essenziale configurare specifici criteri di utilizzo per i flussi di lavoro e le azioni da eseguire in azienda.

Per la configurazione dei criteri sono disponibili numerose opzioni in Enterprise Cloud, così come in Enterprise Server se GitHub Connect è abilitato nelle impostazioni aziendali.

Per configurare i criterio di utilizzo di GitHub Actions per l'azienda, passare all'account aziendale e quindi sezionare Policies > Actions (Criteri > Azioni) nella barra laterale. Verranno visualizzate le opzioni seguenti.

L'elenco a discesa Enable for all organizations (Abilita per tutte le organizzazioni) disponibile nella parte superiore consente di decidere quali organizzazioni all'interno dell'azienda possono usare GitHub Actions (tutte, alcune o nessuna), mentre le tre opzioni sottostanti consentono di definire il livello di restrizione di GitHub Actions in queste organizzazioni.

Per abilitare solo alcune azioni da poter eseguire in azienda, selezionare Consenti azioni aziendali e seleziona le azioni non aziendali e i flussi di lavoro riutilizzabili e scegliere l'opzione appropriata al proprio caso d'uso.

Sincronizzare manualmente le azioni pubbliche per Enterprise Server

La maggior parte delle azioni create da GitHub viene automaticamente inclusa in Enterprise Server e acquisita in un secondo momento da GitHub Marketplace. Includono actions/checkout, actions/upload-artifact, actions/download-artifact, actions/labeler e varie azioni actions/setup-, tra le altre. Per ottenere tutte le azioni ufficiali incluse nell'istanza aziendale, passare alle azioni nell'istanza dell'organizzazione: https://HOSTNAME/actions.

Come accennato nella sezione Configurare i criteri di utilizzo di GitHub Actions, è possibile configurare Enterprise Server in modo che acceda automaticamente alle azioni pubbliche disponibili in GitHub Marketplace e configurare i criteri di utilizzo di tali azioni. Se, tuttavia, si vuole esercitare un controllo più attento sulle azioni pubbliche da rendere disponibili in azienda, è possibile scaricare e sincronizzare manualmente le azioni relative all'istanza aziendale usando lo strumento actions-sync.

A livello di organizzazione

Documentare gli standard aziendali

La creazione di un flusso di lavoro di GitHub Actions comporta spesso la necessità di scrivere più file e creare più repository per specificare il flusso di lavoro. La creazione include anche le azioni, i contenitori e/o gli strumenti di esecuzione da utilizzare nel flusso di lavoro. A seconda del numero di utenti presenti nell'istanza di Enterprise Cloud o Enterprise Server, è possibile che si crei rapidamente un po' di confusione se non sono stati precedentemente definiti standard aziendali per la creazione di flussi di lavoro di GitHub Actions.

Come procedura consigliata, è opportuno quindi documentare gli elementi seguenti in Wiki GitHub o come file markdown in un repository accessibile a tutti gli utenti dell'organizzazione:

• Repository per l'archiviazione
• Convenzioni di denominazione di file/cartelle
• Posizione dei componenti condivisi
• Piani per la manutenzione in corso
• Linee guida per i contributi

Creare modelli di flusso di lavoro

I modelli di flusso di lavoro costituiscono uno strumento ottimale per garantire che l'automazione venga riutilizzata e gestita a livello aziendale. Sia in Enterprise Cloud che in Enterprise Server, gli utenti con accesso in scrittura al repository .github di un'organizzazione possono creare modelli di flusso di lavoro da mettere a disposizione anche ai membri delle altre organizzazioni con gli stessi diritti di accesso in scrittura. I modelli di flusso di lavoro possono quindi essere usati per creare nuovi flussi di lavoro nei repository pubblici e privati dell'organizzazione.

La creazione di un modello di flusso di lavoro è articolata in due passaggi:

1. Creare un file di flusso di lavoro yml.

2. Creare un file di metadati json che descrive come deve essere presentato il modello agli utenti quando creano un flusso di lavoro.

   Nota

   Il file di metadati deve avere lo stesso nome del file del flusso di lavoro ma, anziché l'estensione .yml, è necessario aggiungere l'estensione .properties.json. Un file denominato octo-organization-ci.properties.json, ad esempio, conterrà i metadati per il file del flusso di lavoro octo-organization-ci.yml.

Entrambi i file devono essere inseriti in un repository .github pubblico e in una directory denominata workflow-templates, che è possibile dovere creare se non esiste già a livello di organizzazione.

Di seguito è riportato un esempio di un file di flusso di lavoro di base:

name: Octo Organization CI

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Run a one-line script
        run: echo Hello from Octo Organization

Si noti come il file precedente usi un segnaposto $default-branch. Quando si crea un flusso di lavoro usando un modello personalizzato, questo segnaposto viene automaticamente sostituito con il nome del ramo predefinito del repository.

Di seguito è riportato il file di metadati che si dovrebbe creare per il file del flusso di lavoro precedente:

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

I file di metadati usano i parametri seguenti:

Parametro	Descrizione	Richiesto
name	Nome del modello di flusso di lavoro visualizzato nell'elenco dei modelli disponibili.	Sì
description	Descrizione del modello di flusso di lavoro visualizzato nell'elenco dei modelli disponibili.	Sì
iconName	Definisce un'icona per la voce del flusso di lavoro visualizzata nell'elenco dei modelli. Deve essere un'icona SVG con lo stesso nome e deve essere archiviata nella directory workflow-templates. Per fare riferimento a un file SVG denominato example-icon.svg, ad esempio, si userà example-icon.	No
categories	Definisce la categoria di linguaggio del flusso di lavoro. Quando un utente visualizza i modelli disponibili, quelli creati con lo stesso linguaggio verranno visualizzati per primi.	No
filePatterns	Consente di usare il modello a cui fa riferimento se il repository dell'utente include un file nella directory radice corrispondente a un'espressione regolare definita.	No

Dopo aver creato un modello di flusso di lavoro, gli utenti dell'organizzazione possono trovarlo in Actions > New workflow > Workflows created by _your_organization_name (Azioni > Nuovo flusso di lavoro > Flussi di lavoro creati da _your_organization_name).