Fluxos de trabalho de cache, compartilhamento e depuração
Nesta unidade, você aprenderá a 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 fluxos de trabalho mais rápidos.
- Transmita dados de artefato entre trabalhos.
- Habilite o log de depuração para fluxos de trabalho.
- Acesse logs de fluxo de trabalho na interface do usuário do GitHub e na API REST.
- Use tokens de instalação para a autenticação do Aplicativo GitHub.
Dependências de cache com a ação de cache
Ao criar um fluxo de trabalho, você geralmente 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 fazer com que o fluxo de trabalho seja executado de maneira mais rápida e eficiente. As dependências de cache reduzem o tempo necessário para executar determinadas etapas em um fluxo de trabalho, pois os trabalhos em executores hospedados no GitHub começam em um ambiente virtual limpo a cada vez.
Para armazenar em cache as dependências de um trabalho, use a ação cache do GitHub. Essa ação recupera um cache identificado por uma chave exclusiva que você fornece. Quando a ação encontra o cache, ele recupera os arquivos armazenados em cache para o caminho que você configurar. Para usar a ação cache , 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 pesquisar um cache. | Sim |
Path |
Refere-se ao caminho do arquivo no executor 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 a key inclui o sistema operacional do executor e o hash SHA-256 do arquivo package-lock.json. Prefixar a chave com uma ID (npm-cache, nesse exemplo) é útil quando você está usando o fallback restore-keys e tem vários caches.
Transmitir dados de artefato entre trabalhos
Semelhante à ideia de armazenar em cache dependências 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 desse trabalho anterior para serem executados. Essa abordagem será ú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, o job_2 exige o job_1 por meio da sintaxe 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
Este exemplo tem dois trabalhos. job_1 grava algum texto no file.txt arquivo. Em seguida, ele usará a ação actions/upload-artifact@v2 para carregar esse artefato e armazenar os dados para uso futuro no fluxo de trabalho. job_2 requer job_1 para ser concluído usando a sintaxe needs: job_1. Em seguida, ele usará a ação actions/download-artifact@v2 para baixar esse artefato e imprimir o conteúdo de file.txt.
Habilitar o log de depuração de etapa 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, um trabalho ou uma etapa de fluxo de trabalho específico falha. Nesses cenários, você pode habilitar mais log de depuração para duas opções: execuções e etapas. Habilite esse log de diagnósticos definindo dois segredos de repositório que exigem acesso admin no repositório para 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 etapa, defina o segredo
ACTIONS_STEP_DEBUGno repositório que contém o fluxo de trabalho comotrue.
Acessar os logs de fluxo de trabalho no GitHub
Quando você pensa em automação bem-sucedida, você pretende gastar 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 você mantém o contexto da etapa de depuração atual.
Para exibir os logs de uma execução de fluxo de trabalho no GitHub:
- No seu repositório, vá até a aba 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 o fluxo de trabalho e defini-lo como Falha ao exibir apenas as execuções com falha nesse fluxo de trabalho.
Acessar os logs de fluxo de trabalho por meio da API REST
Além de exibir logs por meio do GitHub, você pode usar a API REST do GitHub para exibir logs para execuções de fluxo de trabalho, executar fluxos de trabalho novamente ou até mesmo cancelar execuções de fluxo de trabalho. Para exibir o log de uma execução de fluxo de trabalho usando a API, envie uma solicitação GET para o ponto de extremidade de logs. Tenha em mente que qualquer pessoa com acesso de leitura no repositório pode usar esse ponto de extremidade. Se o repositório for privado, você precisará usar um token de acesso com o escopo repo.
Por exemplo, uma solicitação GET 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 o installation access token para fazer solicitações à API REST e GraphQL. Essa etapa permite que o aplicativo acesse os recursos pertencentes à instalação, supondo que o aplicativo tenha recebido as permissões e o acesso necessários ao repositório. 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 à 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 para acesso do Git baseado em HTTP. Seu aplicativo deve ter a permissão do Contents repositório. 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