Armazene em cache, compartilhe e depure fluxos de trabalho
Nesta unidade, você aprenderá como otimizar o desempenho, passar dados entre trabalhos e solucionar problemas de fluxos de trabalho usando logs e tokens.
Para implementar esse processo, você aprenderá a:
- Dependências de cache para agilizar fluxos de trabalho.
- Passe dados de artefacto entre tarefas.
- Habilite o log de depuração para fluxos de trabalho.
- Acesse os logs de fluxo de trabalho da interface do usuário do GitHub e da API REST.
- Use tokens de instalação para autenticação do aplicativo GitHub.
Dependências de cache com a ação de cache
Ao criar um fluxo de trabalho, muitas vezes você precisa reutilizar as mesmas saídas ou baixar dependências de uma execução para outra. Em vez de baixar essas dependências repetidamente, você pode armazená-las em cache para tornar seu fluxo de trabalho executado com mais rapidez e eficiência. As dependências armazenadas em cache reduzem o tempo necessário para executar certas etapas num fluxo de trabalho, porque os trabalhos em runners hospedados no GitHub começam sempre num ambiente virtual limpo.
Para armazenar em cache dependências de um trabalho, use a ação do cache GitHub. Esta ação recupera um cache identificado por uma chave exclusiva que você fornece. Quando a ação localiza o cache, ela recupera os arquivos armazenados em cache para o caminho que você configura. Para usar a cache ação, você precisa definir alguns parâmetros específicos:
| Parâmetro | Descrição | Obrigatório |
|---|---|---|
Key |
Refere-se ao identificador de chave criado ao salvar e procurar um cache. | Sim |
Path |
Refere-se ao caminho do arquivo no corredor para armazenar em cache ou pesquisar. | Sim |
Restore-keys |
Consiste em chaves existentes alternativas para armazenar em cache se a chave de cache desejada não for encontrada. | Não |
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-
No exemplo anterior, o path é definido como ~/.npm e inclui key o sistema operacional do corredor e o hash SHA-256 do package-lock.json arquivo. Prefixar a chave com um ID (npm-cache neste exemplo) é útil quando você está usando o restore-keys fallback e tem vários caches.
Passar dados de artefato entre trabalhos
Semelhante à ideia de armazenar dependências em cache em seu fluxo de trabalho, você pode passar dados entre trabalhos dentro do mesmo fluxo de trabalho. Você pode passar os dados usando as ações upload-artifact e download-artifact. Os trabalhos que dependem dos artefatos de um trabalho anterior devem aguardar a conclusão bem-sucedida do trabalho anterior antes de poderem ser executados. Essa abordagem é útil se você tiver uma série de trabalhos que precisam ser executados sequencialmente com base em artefatos carregados de um trabalho anterior. Por exemplo, job_2 requer job_1 usando a needs: job_1 sintaxe.
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
Este exemplo tem dois trabalhos.
job_1 Escreve algum texto no file.txt ficheiro. Em seguida, ele usa a actions/upload-artifact@v2 ação para carregar esse artefato e armazenar os dados para uso futuro dentro do fluxo de trabalho.
job_2 requer job_1 ser concluído usando a needs: job_1 sintaxe. Em seguida, ele usa a actions/download-artifact@v2 ação para baixar esse artefato e, em seguida, imprimir o conteúdo do file.txt.
Habilitar o log de depuração de etapas em um fluxo de trabalho
Em alguns casos, os logs de fluxo de trabalho padrão não fornecem detalhes suficientes para diagnosticar por que uma execução, tarefa ou etapa específica do fluxo de trabalho falha. Nesses cenários, pode habilitar logs de depuração adicionais para duas opções: execuções e etapas. Habilite esse log de diagnóstico definindo dois segredos de repositório que exigem admin acesso ao repositório como true.
- Para habilitar a execução do log de diagnóstico, defina o
ACTIONS_RUNNER_DEBUGsegredo no repositório que contém o fluxo de trabalho comotrue. - Para habilitar o log de diagnóstico de etapas, defina o
ACTIONS_STEP_DEBUGsegredo no repositório que contém o fluxo de trabalho comotrue.
Acesse os logs do fluxo de trabalho no GitHub
Quando você pensa em automação bem-sucedida, você pretende passar o mínimo de tempo olhando para o que é automatizado para que você possa se concentrar no que é relevante. Mas às vezes as coisas não saem como planejado, e você precisa rever o que aconteceu. Esse processo de depuração pode ser frustrante.
O GitHub tem um layout claro e estruturado para ajudá-lo a se mover rapidamente entre trabalhos enquanto mantém o contexto da etapa de depuração atual.
Para exibir os logs de um fluxo de trabalho executado no GitHub:
- No seu repositório, vá para a guia Ações.
- No painel esquerdo, selecione o fluxo de trabalho.
- Na lista de execuções de fluxo de trabalho, selecione a execução.
- Em Trabalhos, selecione o trabalho.
- Leia a saída do log.
Se você tiver várias execuções dentro de um fluxo de trabalho, poderá selecionar o filtro Status depois de selecionar seu fluxo de trabalho e defini-lo como Falha para exibir apenas as execuções com falha nesse fluxo de trabalho.
Acessar os logs de fluxo de trabalho a partir da API REST
Além de visualizar logs via GitHub, você pode usar a API REST do GitHub para visualizar logs de execuções de fluxo de trabalho, reexecutar fluxos de trabalho ou até mesmo cancelar execuções de fluxo de trabalho. Para visualizar o registo de execução de um fluxo de trabalho com a API, envie uma GET solicitação para o endpoint de registos. Lembre-se de que qualquer pessoa com acesso de leitura ao repositório pode usar esse ponto de extremidade. Se o repositório for privado, você deverá usar um token de acesso com o repo escopo.
Por exemplo, uma GET solicitação para exibir um log de execução de fluxo de trabalho específico segue este caminho:
GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs
Identificar quando usar um token de instalação de um aplicativo GitHub
Quando seu aplicativo GitHub é instalado em uma conta, você pode autenticá-lo como uma instalação de aplicativo usando as installation access token solicitações de API REST e GraphQL. Esta etapa permite que o aplicativo acesse recursos de propriedade da instalação, supondo que o aplicativo tenha recebido o acesso e as permissões necessárias ao repositório. As solicitações de API REST ou GraphQL feitas por uma instalação de aplicativo são atribuídas ao aplicativo.
No exemplo a seguir, você substitui INSTALLATION_ACCESS_TOKEN pelo token de acesso de instalação:
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"
Você também pode usar um token de acesso de instalação para autenticar o acesso Git baseado em HTTP. A sua aplicação deve ter permissão de repositório Contents. Em seguida, você pode usar o token de acesso de instalação como a senha HTTP.
Substitua TOKEN no exemplo pelo token de acesso de instalação:
git clone https://x-access-token:TOKEN@github.com/owner/repo.git