Note
You must opt in to run Dependabot on GitHub Actions. Future releases of GitHub will remove the ability to opt in and always run Dependabot on GitHub Actions. For more information, see "About Dependabot on GitHub Actions runners."
About Dependabot on GitHub Actions runners
By default, Dependabot updates are run using the built-in Dependabot application in GitHub. You can instead choose to run Dependabot updates on GitHub Actions, to take advantage of better performance, and increased visibility and control of Dependabot updates jobs.
Using GitHub Actions runners allows you to more easily identify Dependabot job errors and manually detect and troubleshoot failed runs. You can also integrate Dependabot into your CI/CD pipelines by using GitHub Actions APIs and webhooks to detect Dependabot job status such as failed runs, and perform downstream processing. For more information, see "REST API endpoints for GitHub Actions" and "Webhook events and payloads."
You can run Dependabot on GitHub Actions using:
- GitHub-hosted runners
- Larger runners. These runners are GitHub-hosted, with advanced features, such as more RAM, CPU, and disk space. For more information, see "About larger runners."
- Self-hosted runners
Using private networking with either an Azure Virtual Network (VNET) or Actions Runner Controller (ARC) is not supported.
Tip
Running Dependabot on GitHub-hosted and self-hosted runners does not count towards your included GitHub Actions minutes. For more information, see "About billing for GitHub Actions."
Enabling Dependabot on GitHub Actions may increase the number of concurrent jobs run in your account. If required, customers on enterprise plans can request a higher limit for concurrent jobs. For more information, contact us through the GitHub Support portal, or contact your sales representative.
If you are transitioning to using Dependabot on GitHub Actions runners and you restrict access to your organization's or repository's private resources, you may need to update your list of allowed IP addresses. For example, if you currently limit access to your private resources to the IP addresses that Dependabot uses, you should update your allowlist to use the GitHub-hosted runners IP addresses sourced from the meta API endpoint. For more information, see "REST API endpoints for meta data."
Enabling or disabling Dependabot on GitHub-hosted runners
This section only applies to standard GitHub-hosted runners, not larger runners.
New repositories that you create in your user account or in your organization will automatically be configured to run Dependabot on GitHub Actions if any of the following is true:
- Dependabot is installed and enabled, and GitHub Actions is enabled and in use.
- The "Dependabot on GitHub Actions runners" setting for your organization is enabled.
For existing repositories, you can opt in to run Dependabot on GitHub Actions as follows.
Future releases of GitHub will remove the ability to disable running Dependabot on GitHub Actions.
If you restrict access to your organization's or repository's private resources, you may need to update your list of allowed IP addresses prior to enabling Dependabot on GitHub Actions runners. You can update your IP allow list to use the GitHub-hosted runners IP addresses (instead of the Dependabot IP addresses), sourced from the meta REST API endpoint.
Warning
You should not rely on the GitHub Actions IP addresses for authentication to private registries. These GitHub Actions addresses are not only used by GitHub, and should not be trusted for authentication. Instead, use a self-hosted runner to ensure greater control over your network access. For more information, see "Managing Dependabot on self-hosted runners."
Note, disabling and re-enabling the "Dependabot on GitHub Actions runners" settings will not trigger a new Dependabot run.
Enabling or disabling for your repository
You can manage Dependabot on GitHub Actions for your public or private repository.
-
On GitHub.com, navigate to the main page of the repository.
-
Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.
-
In the "Security" section of the sidebar, click Code security and analysis.
-
Under "Dependabot", to the right of "Dependabot on Actions runners", click Enable to enable the feature or Disable to disable it.
Enabling or disabling for your organization
You can enable Dependabot on GitHub Actions for all existing repositories in an organization.
Only repositories with the following configuration will be updated to run Dependabot on GitHub Actions the next time a Dependabot job is triggered.
- Dependabot is enabled in the repository.
- GitHub Actions is enabled in the repository.
If a repository in your organization has Dependabot enabled but GitHub Actions disabled, Dependabot will not run on GitHub Actions, but will continue to run using the built-in Dependabot application.
- In the upper-right corner of GitHub, select your profile photo, then click Your organizations.
- Next to the organization, click Settings.
- In the "Security" section of the sidebar, click Code security then Global settings.
- Under "Dependabot", select "Dependabot on Actions runners" to enable the feature or deselect to disable it.
For more information, see "Configuring global security settings for your organization."
Enabling or disabling Dependabot on larger runners
If you run into Dependabot timeouts and out-of-memory errors, you may want to use larger runners, as you can configure these runners to have more resources.
Note
You can only enable larger runners for Dependabot at the organization level. GitHub will bill your organization at the regular Actions runner pricing. For more information, see "About billing for GitHub Actions."
- Add a larger runner to your organization. For more informaton, see "Managing larger runners."
- Add the
dependabot
label to the larger runner. - Optionally, call the larger runner
dependabot
. - Opt in the organization to self-hosted runners. For more information, see "Managing Dependabot on self-hosted runners." This step is required, as it ensures that future Dependabot jobs will run on the larger GitHub-hosted runner that has the
dependabot
label.
Managing Dependabot on GitHub Actions runners
When a Dependabot on GitHub Actions job is run, you can review the workflow run history directly from the Dependabot job logs. For more information, see "Viewing Dependabot job logs."
You can also navigate to a Dependabot workflow run from the Actions tab in a repository. For more information, see "Viewing workflow run history."
To re-run a Dependabot version updates or Dependabot security updates job, use the appropriate procedure below. You cannot re-run a Dependabot job on GitHub Actions as you would for other GitHub Actions workflows and jobs, that is, by using the Actions tab in a repository. You cannot view usage data for Dependabot updates workflows and jobs in your organization's GitHub Actions usage metrics.
Re-running a Dependabot version updates job
-
On GitHub.com, navigate to the main page of the repository.
-
Under your repository name, click Insights.
-
In the left sidebar, click Dependency graph.
-
Under "Dependency graph", click Dependabot.
-
To the right of the name of manifest file that you're interested in, click Recent update jobs.
-
To the right of the affected manifest file, click Check for updates to re-run a Dependabot version updates job and check for new updates to dependencies for that ecosystem.
Re-running a Dependabot security updates job
- On GitHub.com, navigate to the main page of the repository.
- Under your repository name, click Security.
- In the left sidebar, under "Vulnerability alerts", click Dependabot.
- Under "Dependabot", click the alert you want to view.
- In the section displaying the error details for the alert, click Try again to re-run the Dependabot security updates job.
Troubleshooting failures when Dependabot triggers existing workflows
After you set up Dependabot updates for GitHub.com, you may see failures when existing workflows are triggered by Dependabot events.
By 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.
There are three ways to resolve this problem:
- 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." - 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 "Automating Dependabot with GitHub Actions." - You can provide workflows triggered by Dependabot access to secrets and allow the
permissions
term to increase the default scope of theGITHUB_TOKEN
. For more information, see "Automating Dependabot with GitHub Actions" and "Workflow syntax for GitHub Actions."