Memorizzare nella cache, condividere ed eseguire il debug dei flussi di lavoro

  • 8 minuti

In questa unità si apprenderà come ottimizzare le prestazioni, passare i dati tra processi e risolvere i problemi relativi ai flussi di lavoro usando log e token.

Per implementare questo processo, si apprenderà come:

  • Memorizzare nella cache le dipendenze per flussi di lavoro più veloci.
  • Passare i dati dell'artefatto tra i processi.
  • Abilitare la registrazione di debug per i flussi di lavoro.
  • Accedere ai log del flusso di lavoro dall'interfaccia utente di GitHub e dall'API REST.
  • Usare i token di installazione per l'autenticazione dell'app GitHub.

Memorizzare nella cache le dipendenze con l'azione di memorizzazione nella cache

Quando si compila un flusso di lavoro, spesso è necessario riutilizzare gli stessi output o scaricare le dipendenze da un'esecuzione a un'altra. Invece di scaricare queste dipendenze più volte, è possibile memorizzarle nella cache per velocizzare e rendere più efficiente l'esecuzione del flusso di lavoro. La memorizzazione nella cache delle dipendenze riduce il tempo necessario per eseguire determinati passaggi in un flusso di lavoro, perché ogni volta i processi negli strumenti di esecuzione ospitati in GitHub vengono avviati in un ambiente virtuale pulito.

Per memorizzare nella cache le dipendenze per un processo, usare l'azione cache di GitHub. Questa azione recupera una cache identificata da una chiave univoca specificata. Quando l'azione trova la cache, recupera i file memorizzati nella cache del percorso configurato. Per usare l'azione cache , è necessario impostare alcuni parametri specifici:

Parametro Descrizione Obbligatorio
Key Fa riferimento all'ID chiave creato durante il salvataggio e la ricerca di una cache. Sì
Path Fa riferimento al percorso del file nello strumento di esecuzione da memorizzare nella cache o da cercare. Sì
Restore-keys È costituita da chiavi esistenti alternative da memorizzare nella cache se la chiave della cache desiderata non viene trovata. NO 
steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

Nell'esempio precedente, path è impostato su ~/.npm e key include il sistema operativo dello strumento di esecuzione e l'hash SHA-256 del file package-lock.json. L'aggiunta di un prefisso alla chiave con un ID, npm-cache in questo esempio, è utile quando si usa il fallback restore-keys e si hanno più cache.

Passare i dati dell'artefatto tra i processi

Analogamente all'idea di memorizzare nella cache le dipendenze all'interno del flusso di lavoro, è possibile passare dati tra processi all'interno dello stesso flusso di lavoro. È possibile passare i dati usando le upload-artifact azioni e download-artifact . I processi dipendenti dagli artefatti di un processo precedente devono attendere che tale processo venga completato correttamente per poter essere eseguiti. Questo approccio è utile se si dispone di una serie di processi che devono essere eseguiti in sequenza in base agli artefatti caricati da un processo precedente. Ad esempio, per job_2 è necessario job_1 usando la sintassi needs: job_1.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

In questo esempio ci sono due lavori. job_1 scrive del testo nel file.txt file. Usa quindi l'azione actions/upload-artifact@v2 per caricare questo artefatto e memorizzare i dati per un uso futuro all'interno del flusso di lavoro. job_2 richiede che job_1 venga completato usando la sintassi needs: job_1. Usa quindi l'azione actions/download-artifact@v2 per scaricare tale artefatto e stampare il contenuto di file.txt.

Abilitare la registrazione di debug dei passaggi in un flusso di lavoro

In alcuni casi, i log del flusso di lavoro predefiniti non forniscono dettagli sufficienti per diagnosticare il motivo per cui un'esecuzione, un processo o un passaggio del flusso di lavoro specifici ha esito negativo. In questi scenari è possibile abilitare più registrazione di debug per due opzioni: esecuzioni e passaggi. Abilitare questa registrazione diagnostica impostando due segreti del repository per cui è necessario l'accesso admin al repository su true.

  • Per abilitare l'esecuzione della registrazione diagnostica, impostare il ACTIONS_RUNNER_DEBUG segreto nel repository che contiene il flusso di lavoro su true.
  • Per abilitare la registrazione diagnostica dei passaggi, impostare il segreto ACTIONS_STEP_DEBUG nel repository che contiene il flusso di lavoro su true.

Accedere ai log del flusso di lavoro in GitHub

Quando si pensa all'automazione di successo, si mira a dedicare il minor tempo a esaminare ciò che è automatizzato in modo da poter concentrarsi su ciò che è rilevante. Ma a volte le cose non vanno come pianificate e devi esaminare ciò che è successo. Questo processo di debug può essere frustrante.

GitHub offre un layout chiaro e strutturato che consente di spostarsi rapidamente tra processi mantenendo il contesto del passaggio di debug corrente.

Per visualizzare i log di un flusso di lavoro eseguito in GitHub:

  1. Nel repository, vai alla scheda Azioni.
  2. Nel riquadro sinistro selezionare il flusso di lavoro.
  3. Nell'elenco delle esecuzioni del flusso di lavoro, selezionare l'esecuzione.
  4. In Lavori, seleziona il lavoro.
  5. Leggere l'output del log.

Se sono presenti più esecuzioni all'interno di un flusso di lavoro, è possibile selezionare il filtro Stato dopo aver selezionato il flusso di lavoro e impostarlo su Errore per visualizzare solo le esecuzioni non riuscite nel flusso di lavoro.

Accedere ai log del flusso di lavoro dall'API REST

Oltre a visualizzare i log tramite GitHub, è possibile usare l'API REST di GitHub per visualizzare i log per le esecuzioni del flusso di lavoro, rieseguire i flussi di lavoro o persino annullare le esecuzioni del flusso di lavoro. Per visualizzare il log dell'esecuzione di un flusso di lavoro usando l'API, inviare una GET richiesta all'endpoint dei log. Tenere presente che chiunque abbia accesso in lettura al repository può usare questo endpoint. Se il repository è privato, è necessario usare un token di accesso con l'ambito repo.

Ad esempio, una GET richiesta di visualizzare un log di esecuzione del flusso di lavoro specifico segue questo percorso:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Identificare quando usare un token di installazione da un'app GitHub

Quando l'app GitHub è installata in un account, è possibile autenticarla come installazione dell'app utilizzando il installation access token per effettuare richieste API REST e GraphQL. Questo passaggio consente all'app di accedere alle risorse di proprietà dell'installazione, presupponendo che all'app siano state concesse le autorizzazioni e l'accesso al repository necessari. Le richieste API REST o GraphQL effettuate da un'installazione dell'app vengono attribuite all'app.

Nell'esempio seguente sostituire INSTALLATION_ACCESS_TOKEN con il token di accesso all'installazione:

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

È anche possibile usare un token di accesso all'installazione per l'autenticazione per l'accesso Git basato su HTTP. L'app deve disporre dell'autorizzazione del Contents repository. È quindi possibile usare il token di accesso all'installazione come password HTTP.

Sostituire TOKEN nell'esempio con il token di accesso all'installazione.

git clone https://x-access-token:TOKEN@github.com/owner/repo.git