Dependabot on Actions
#120779
-
Select Topic AreaProduct Feedback BodyAboutStarting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot as an Actions workflow. This capability already exists for GitHub Enterprise Server (GHES) users and no further action is required enable Dependabot on Actions. This is the start of an effort to consolidate Dependabot's compute platform to Actions, with further migration plans to be announced in the coming months. 👀 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. 🏁 Self-hosted runners, larger GitHub-hosted runners, and actions runner control (ARC) 🏃 will be supported in early May 2024; stay tuned for more. Will this count towards Actions minutes or costs?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 still free). :free Let us know what you think!Have you used Dependabot on Actions? What do you think? Links to learn more: |
Beta Was this translation helpful? Give feedback.
Replies: 10 comments 21 replies
-
Will we be able to have a more flexible schedule on dbot pr's moving to actions? We'd like to run quarterly whereas monthly is the longest duration available in the configuration. |
Beta Was this translation helpful? Give feedback.
-
Is this feature available for everyone now? I can't see the "Dependabot on GitHub Actions Runners" setting in neither my own repositories nor my organizations'. |
Beta Was this translation helpful? Give feedback.
-
Does this mean that Dependabot can now access the secrets normally available for Actions Workflows? So that we no longer have to duplicate certain secrets in the dedicated |
Beta Was this translation helpful? Give feedback.
-
Do you also plan to release a GitHub Action to run dependabot in your own workflows? https://github.com/github/dependabot-action is published but according to the docs, not usable. This will also enable you to adjust the scheduler to finally run on weekends too, and to start the bot from mobile (using workflow-dispatch). |
Beta Was this translation helpful? Give feedback.
-
Can't see how to file a bug with you guys but I managed to break Dependabot with my project. I enabled Dependabot on Actions and it crashes with:
I believe it's trying to re-add that key because it is indeed a value specified multiple times in my .csproj file (but conditionally, a condition that Dependabot doesn't understand and isn't accounting for):
Here's a link to the run: https://github.com/PowerShell/PowerShellEditorServices/actions/runs/8842186132/job/24280433435 After that crash it claims it found no matching dependencies in my two configured groups (because it never finished analyzing) and then exits with sucess 🙃 |
Beta Was this translation helpful? Give feedback.
-
Could you clarify on how to select larger runners for dependabot to run on? |
Beta Was this translation helpful? Give feedback.
-
Hey! I'm excited for this new feature but came across an issue while testing. Are there any plans to make the I'n currently working in a Github Enterprise environment which has a set of shared enterprise-level runners across all organisations that have a dependabot label assigned to them. However within our organisation we host our own set of runners using ARC. Currently I do not see a way to target only our organisation-level runners. |
Beta Was this translation helpful? Give feedback.
-
We're running Dependabot on the GitHub Actions runners since the beginning, and today I noticed something odd. It could be unrelated to this, but I noticed that a cache was restored from a key, that should not exist in the current PR. I created a PR and saw the following cache restore happening:
As you can see, it restored PR 31901's cache, instead of the current PR 31916 When I checked PR 31901, It was a Dependabot PR for a grouped update. Could it be that there is an issue with the cache scope permissions for Dependabot runs? It seems that Dependabot was able to write to the Another interesting observation is that these caches don't show up at all when using: $ gh cache list --key phpstan
No caches found in Org/RepoName |
Beta Was this translation helpful? Give feedback.
-
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
@carlincherry I notice there's no way to disable Dependabots on Actions at an organisational level. We've seen a couple of our repos start running Dependabot jobs on Actions runners, and want to disable them, but as you can see in the screenshot: we have not ticked the option. It feels to me like there are three potential settings:
And the unticked option is being interpreted as 3. Can we disable it for all repositories at the organisation level? |
Beta Was this translation helpful? Give feedback.
The setting is available for me now.