{"meta":{"title":"Troubleshooting Dependabot on GitHub Actions","intro":"This article provides troubleshooting information for issues you may encounter when using Dependabot with GitHub Actions.","product":"Security and code quality","breadcrumbs":[{"href":"/en/code-security","title":"Security and code quality"},{"href":"/en/code-security/reference","title":"Reference"},{"href":"/en/code-security/reference/supply-chain-security","title":"Supply chain security"},{"href":"/en/code-security/reference/supply-chain-security/troubleshoot-dependabot","title":"Troubleshoot Dependabot"},{"href":"/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions","title":"Dependabot on Actions"}],"documentType":"article"},"body":"# Troubleshooting Dependabot on GitHub Actions\n\nThis article provides troubleshooting information for issues you may encounter when using Dependabot with GitHub Actions.\n\n## Troubleshooting failures when Dependabot triggers existing workflows\n\nAfter you set up Dependabot updates for GitHub.com, you may see failures when existing workflows are triggered by Dependabot events.\n\nBy default, GitHub Actions workflow runs that are triggered by Dependabot from `push`, `pull_request`, `pull_request_review`, or `pull_request_review_comment` events are treated as if they were opened from a repository fork. Unlike workflows triggered by other actors, this means they receive a read-only `GITHUB_TOKEN` and do not have access to any secrets that are normally available. This will cause any workflows that attempt to write to the repository to fail when they are triggered by Dependabot.\n\nThere are three ways to resolve this problem:\n\n1. You can update your workflows so that they are no longer triggered by Dependabot using an expression like: `if: github.actor != 'dependabot[bot]'`. For more information, see [Evaluate expressions in workflows and actions](/en/actions/reference/workflows-and-actions/expressions).\n2. You can modify your workflows to use a two-step process that includes `pull_request_target` which does not have these limitations. For more information, see [Troubleshooting Dependabot on GitHub Actions](/en/code-security/reference/supply-chain-security/troubleshoot-dependabot/dependabot-on-actions).\n3. You can provide workflows triggered by Dependabot access to secrets and allow the `permissions` term to increase the default scope of the `GITHUB_TOKEN`.\n\nSome troubleshooting advice is provided in this article. You can also see [Workflow syntax for GitHub Actions](/en/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions).\n\n### Accessing secrets\n\nWhen a Dependabot event triggers a workflow, the only secrets available to the workflow are Dependabot secrets. GitHub Actions secrets are **not available**. You must therefore store any secrets that are used by a workflow triggered by Dependabot events as Dependabot secrets. For more information, see [Configuring access to private registries for Dependabot](/en/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/configure-access-to-private-registries#storing-credentials-for-dependabot-to-use).\n\nDependabot secrets are added to the `secrets` context and referenced using exactly the same syntax as secrets for GitHub Actions. For more information, see [Using secrets in GitHub Actions](/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets#using-secrets-in-a-workflow).\n\nIf you have a workflow that will be triggered by Dependabot and also by other actors, the simplest solution is to store the token with the permissions required in an action and in a Dependabot secret with identical names. Then the workflow can include a single call to these secrets. If the secret for Dependabot has a different name, use conditions to specify the correct secrets for different actors to use.\n\nFor examples that use conditions, see [Automating Dependabot with GitHub Actions](/en/code-security/tutorials/secure-your-dependencies/automate-dependabot-with-actions).\n\nTo access a private container registry on AWS with a user name and password, a workflow must include a secret for `username` and `password`.\n\nIn this example, when Dependabot triggers the workflow, the Dependabot secrets with the names `READONLY_AWS_ACCESS_KEY_ID` and `READONLY_AWS_ACCESS_KEY` are used. If another actor triggers the workflow, the actions secrets with those names are used.\n\n```yaml copy\n# This workflow uses actions that are not certified by GitHub.\n# They are provided by a third-party and are governed by\n# separate terms of service, privacy policy, and support\n# documentation.\nname: CI\non:\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout repository\n        uses: actions/checkout@v6\n\n      - name: Login to private container registry for dependencies\n        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c\n        with:\n          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com\n          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}\n          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}\n\n      - name: Build the Docker image\n        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)\n```\n\n### Changing `GITHUB_TOKEN` permissions\n\nBy default, GitHub Actions workflows triggered by Dependabot get a `GITHUB_TOKEN` with read-only permissions. You can use the `permissions` key in your workflow to increase the access for the token:\n\n```yaml copy\nname: CI\non: pull_request\n\n# Set the access for individual scopes, or use permissions: write-all\npermissions:\n  pull-requests: write\n  issues: write\n  ...\n\njobs:\n  ...\n```\n\nFor more information, see [Use GITHUB\\_TOKEN for authentication in workflows](/en/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token).\n\n## Manually re-running a workflow\n\nWhen you manually re-run a Dependabot workflow, it will run with the same privileges as before even if the user who initiated the rerun has different privileges. For more information, see [Re-running workflows and jobs](/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs)."}