Starting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot updates as an Actions workflow. With this change, the job that Dependabot runs to generate pull requests will run in GitHub Actions. This is the start of an effort to consolidate Dependabot’s compute platform to Actions, with further migration plans to be announced later.
Who can opt-in?
GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions today.
What if I’m on Enterprise Server (GHES)?
GitHub Enterprise Server (GHES) and Proxima users already run Dependabot on Actions; no further steps are required to enable Dependabot on Actions for these users.
Why choose to run Dependabot as an Actions workflow today?
Enabling Dependabot on Actions will yield performance benefits like faster Dependabot runs and increased visibility into errors to manually detect and troubleshoot failed runs. Actions APIs and webhooks will also be able to detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines. There will be no change or impact to the Dependabot functionality, and there will be no impact to billed Actions minutes (i.e. Dependabot runs are free).
Will this count towards Actions minutes or costs?
This does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone. Beginning today, using Dependabot as an Actions workflow is free for everyone and generally available on all repositories.
What’s the next migration phase for Dependabot on Actions?
Over the course of the next year, we are migrating all Dependabot workflows to run on Actions compute infrastructure. You can opt-in today to gain access to these benefits, but they’ll be coming soon to all repos without needing to opt-in as well. We’re excited for faster runs, increased troubleshooting visibility, and other future benefits running Dependabot on Actions will unlock. We’ll be in close contact with those organizations who own repositories with Actions disabled and Dependabot enabled as we kick off the compute infrastructure migration. If you have questions or concerns, please contribute to our community discusson or contact our support team.
How to enable Dependabot on Actions?
GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions runners at either the repository or organization level from the Code security and analysis settings pages. For more information, see our documentation on enabling Dependabot on Actions runners.
When will Dependabot support self-hosted runners and larger GitHub-Hosted runners?
May 2024
When will VNETs be supported?
This work is still in progress; we don’t yet have an estimated date when these will be available.
Can I use Actions workflows and APIs to trigger Dependabot jobs?
Today, Dependabot jobs can only be triggered from the Dependabot UI, and not by Actions workflows or APIs.
If I see a Dependabot job fail in Actions, how can I restart it?
If I enable Dependabot on Actions, can I later opt-out?
At this time, you can opt out of enabling Dependabot on Actions. However, this ability will change within the next year as we consolidate Dependabot’s compute platform to Actions.
What if I don’t want to turn on Actions for my repository or organization? What happens if Actions is disabled in a repository but Dependabot is enabled to run on Actions?
During this opt-in phase of the compute infrastructure migration, if you enable Dependabot on Actions but disable Actions at the repository or organization level, Dependabot will run on the legacy compute infrastructure. Please enable Actions either in your Dependabot-enabled repository or across your organization if you wish to opt in to run Dependabot on Actions.
Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉
You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to the repository network are protected.
Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.
This migrates the content from https://codeql.github.com/docs/codeql-for-visual-studio-code and provides a consistent, single-site experience with improved text, descriptions, images, and navigation.
On May 8, 2024, we’ll begin automatically redirecting from the original codeql.github.com location to the new location.
The source files now exist in Markdown format in the public, open-source docs repository. If you would like to contribute, you can consult and follow the steps listed in the GitHub Docs contributing guide.