# Solução de problemas do Dependabot no GitHub Actions

Este artigo fornece informações de solução de problemas para problemas que você pode encontrar ao usar Dependabot com GitHub Actions.

## Solução de falhas quando Dependabot aciona fluxos de trabalho existentes

Depois de configurar as atualizações do Dependabot para GitHub.com, você poderá ver as falhas quando os fluxos de trabalho existentes forem disparados por eventos do Dependabot.

Por padrão, as execuções de fluxo de trabalho do GitHub Actions disparadas pelo Dependabot dos eventos `push`, `pull_request`, `pull_request_review` ou `pull_request_review_comment` são tratados como se eles fossem abertos de um fork do repositório. Ao contrário dos fluxos de trabalho disparados por outros atores, isso significa que eles recebem o `GITHUB_TOKEN` somente leitura e não têm acesso a nenhum segredo que esteja normalmente disponível. Isso fará com que quaisquer fluxos de trabalho que tentam gravar no repositório falhem quando forem acionados por Dependabot.

Há três maneiras de resolver este problema:

1. Você pode atualizar seus fluxos de trabalho para que não sejam mais disparados pelo Dependabot usando uma expressão como: `if: github.actor != 'dependabot[bot]'`. Para saber mais, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/learn-github-actions/expressions).
2. Modifique seus fluxos de trabalho para usar um processo de duas etapas que inclui `pull_request_target` que não tem essas limitações. Para saber mais, confira [Solução de problemas do Dependabot no GitHub Actions](/pt/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions#restrictions-when-dependabot-triggers-events).
3. Forneça fluxos de trabalho disparados pelo acesso do Dependabot aos segredos e permita que o termo `permissions` aumente o escopo padrão do `GITHUB_TOKEN`.

Algumas dicas de solução de problemas são fornecidos neste artigo. Você também pode conferir [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions).

### Acessando segredos

Quando um evento Dependabot aciona um fluxo de trabalho, os únicos segredos disponíveis para o fluxo de trabalho são os segredos Dependabot.
GitHub Actions os segredos **não estão disponíveis**. Portanto, você deve armazenar todos os segredos utilizados por um fluxo de trabalho disparado por eventos Dependabot como segredos Dependabot. Para obter mais informações, consulte [Configurando o acesso a registros privados para Dependabot](/pt/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot#storing-credentials-for-dependabot-to-use).

Dependabot os segredos são adicionados ao `secrets` contexto e referenciados usando exatamente a mesma sintaxe que os segredos para GitHub Actions. Para obter mais informações, consulte [Usar segredos em ações do GitHub](/pt/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow).

Se você tiver um fluxo de trabalho que será disparado por Dependabot e também por outros atores, a solução mais simples é armazenar o token com as permissões necessárias em uma ação e em um Dependabot segredo com nomes idênticos. Em seguida, o fluxo de trabalho pode incluir uma única chamada para esses segredos. Se o segredo de Dependabot tiver um nome diferente, use condições para especificar os segredos corretos para que diferentes atores os usem.

Para obter exemplos que usam condições, confira [Automatizando o Dependabot com GitHub Actions](/pt/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions).

Para acessar um registro de contêiner privado na AWS com um nome de usuário e uma senha, um fluxo de trabalho precisa incluir um segredo para `username` e `password`.

Neste exemplo, quando Dependabot aciona o fluxo de trabalho, os segredos de Dependabot com os nomes `READONLY_AWS_ACCESS_KEY_ID` e `READONLY_AWS_ACCESS_KEY` são usados. Se outro ator disparar o fluxo de trabalho, as ações secretas com esses nomes serão usadas.

```yaml copy
# Esse fluxo de trabalho usa ações que não são certificadas pelo GitHub.
# São fornecidas por terceiros e regidas por
# termos de serviço, política de privacidade e suporte separados
# online.
name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Login to private container registry for dependencies
        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
        with:
          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)
```

### Como alterar as permissões `GITHUB_TOKEN`

Por padrão, os fluxos de trabalho GitHub Actions acionados por Dependabot recebem um `GITHUB_TOKEN` com permissões somente de leitura. Use a chave `permissions` no fluxo de trabalho para aumentar o acesso ao token:

```yaml copy
name: CI
on: pull_request

# Set the access for individual scopes, or use permissions: write-all
permissions:
  pull-requests: write
  issues: write
  ...

jobs:
  ...
```

Para obter mais informações, consulte [Usar GITHUB\_TOKEN para autenticação em fluxos de trabalho](/pt/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token).

## Reexecutando manualmente um fluxo de trabalho

Quando você executar manualmente um Dependabot fluxo de trabalho, ele será executado com os mesmos privilégios de antes, mesmo que o usuário que iniciou a nova execução tenha privilégios diferentes. Para obter mais informações, consulte [Reexecutando fluxos de trabalho e tarefas](/pt/actions/managing-workflow-runs/re-running-workflows-and-jobs).