À propos de Dependabot sur les exécuteurs GitHub Actions

About Dependabot on GitHub Actions runners

By default, Dependabot updates are run using the built-in Dependabot application in GitHub Enterprise Cloud. 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 on self-hosted and larger runners. However, using private networking with an Azure Virtual Network (VNET) or Actions Runner Controller (ARC) is not supported.

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."

When you enforce a policy to only allow actions and reusable workflows from your enterprise, and you enable Dependabot on GitHub Actions, Dependabot will not run. To enable Dependabot to run with your enterprise actions and reusable workflows, you should choose either to allow actions created by GitHub, or allow specified actions and reusable workflows. For more information, see "Enforcing policies for GitHub Actions in your enterprise."

Enabling or disabling Dependabot on GitHub Actions 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 Enterprise Cloud 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.

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, private or internal repository.

1. On GitHub.com, navigate to the main page of the repository.

2. Under your repository name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

   

3. In the "Security" section of the sidebar, click Code security and analysis.

   Note

   If your organization is enrolled in the security configurations and global settings public beta, instead of "Code security and analysis", you will see a "Code security" dropdown menu. Select Code security, then click Configurations. For next steps on enabling Dependabot on GitHub Actions and other security features at scale with security configurations, see "Applying the GitHub-recommended security configuration in your organization."

4. Under "Code security and analysis", to the right of "Dependabot on GitHub Actions runners", click Enable to enable the feature or Disable to disable it.

Enabling or disabling for your organization

You can use the organization settings page for "Code security and analysis" to 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.

1. In the upper-right corner of GitHub.com, select your profile photo, then click Your organizations.

   

2. Next to the organization, click Settings.

3. In the "Security" section of the sidebar, click Code security and analysis.

   Note

   If your organization is enrolled in the security configurations and global settings public beta, instead of "Code security and analysis", you will see a "Code security" dropdown menu. Select Code security, then click Configurations. For next steps on enabling Dependabot on GitHub Actions and other security features at scale with security configurations, see "Applying the GitHub-recommended security configuration in your organization."

4. Under "Code security and analysis", to the right of "Dependabot on GitHub Actions runners", click Enable all to enable the feature or Disable all to disable it.

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

1. On GitHub.com, navigate to the main page of the repository.

2. Under your repository name, click Insights.

   

3. In the left sidebar, click Dependency graph.

   

4. Under "Dependency graph", click Dependabot.

5. To the right of the name of manifest file that you're interested in, click Recent update jobs.

6. 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

1. On GitHub.com, navigate to the main page of the repository.
2. Under your repository name, click Security.
3. In the left sidebar, under "Vulnerability alerts", click Dependabot.
4. Under "Dependabot", click the alert you want to view.
5. 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:

1. 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 "Expressions."
2. 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."
3. You can provide workflows triggered by Dependabot access to secrets and allow the permissions term to increase the default scope of the GITHUB_TOKEN. For more information, see "Automating Dependabot with GitHub Actions" and "Workflow syntax for GitHub Actions."