You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes, but it's unlikely they'll create dependabot/something by mistake. And the core and triage teams are a trusted group; if someone does create one as a workaround, we can ask them nicely not to and then clean up. (We could have Bedevere autoclose PRs from such branches when not authored by Dependabot, but hopefully it would not be a common thing.)
When you fork a repo, by default it only copies the main branch. If you opt-in to copy all branches, well, Dependabot PRs are usually merged fairly quickly and their branches short-lived, so you'll likely not get one. Even if you did, it's clear what the branch is for, and you can easily delete it.
If you opt-in to copy all branches, well, Dependabot PRs are usually merged fairly quickly and their branches short-lived, so you'll likely not get one. Even if you did, it's clear what the branch is for, and you can easily delete it.
Hm, ok. I guess if it's once a month, it's not that bad.
I'd prefer to attempt exploring Peter's idea of syncing the PRs accross.
I take the arguments that it's a limited set of possible branch names, which are hopefully temporary. I think though we should be consistent with prohibiting all upstream branches or allowing them. We can make similar arguments for more exemptions in due course, where the root cause is that the service/tool (dependabot in this case) is insufficiently configurable. I can also see a realistic possiblilty that I update config in a future PR and accidentally push to upstream -- I name my branches in the topic/subject pattern, so dependabot/update-config is highly likely!
Personally, I'd be +0 on keeping the prohibition on upstream branches (my editor auto-fetches all new branches but doesn't auto-delete), but I'd prefer that we go back to allowing branches than creating specific exemptions for tools -- we will inevitably forget why an exemption was first needed, and if it still is (c.f. the recent IRC ping webhook!).
I don't think that will work as-is unless my understanding of rule layering is incorrect, as the rules are AND-ed together and the more restrictive subset of the rules applies—i.e. the second rule wouldn't do anything to make the first rule less strict. EDIT: Somehow I totally missed seeing the exclude for dependabot/ in the first rule, so that would work, although it may not be necessary to add a whole separate ruleset unless we want different rules to apply to the Dependabot branches.
What should also work for now is just adding Dependabot to the bypass list of the first rule as Exempt, and no need for another. That would technically allow Dependabot to create other branches that aren't dependabot/, but as it is a bot that always does this as part of its implicit contract (unless something goes horribly wrong), this shouldn't be an issue in practice (far less so than allowing anyone to create dependabot/ branches). Here's a ruleset I've crafted on my fork of the CPython repo that should do the trick.
Only concern with just adding that ruleset and removing the corresponding Branch Protection rule is that I'm not totally sure how the other classic branch protection rules and rulesets interact, so it might be a good idea to just migrate the other rules to rulesets too. They are more or less backwards compatible, have helpful additional options and customization, and rulesets can be exported and imported as JSON so non-admins (like myself, happy to help here) can craft and test them on our own forks, export them and then an admin can just import them on CPython and the other repos with similar rules (there's a verification step) instead of the awkward dance we had to do on python/core-workflow#460 with screenshots and manual admin time that took a couple rounds to get just right. This has been really helpful for Spyder as I've developed a standard set of rulesets (protect main/release branches, protect all tags, prevent creation of upstream branches) that can easily be applied across the repos in our organization.
FWIW, I've recently submitted an official detailed feature request to GitHub via internal channels (the GH Slack) regarding both this issue (Dependabot not supporting the standard fork workflow) and also the issue we found with the GitHub web UI where it does not offer the option to create a new branch on a fork when editing via the web UI if the user has write permissions, even if branch protection rules would prevent it.
Sidenote, but maybe this should be moved to core-workflow due to the topic and potential implications across other repos that use this pattern?
I don't think that will work as-is unless my understanding of rule layering is incorrect, as the rules are AND-ed together
The first rule should block creation of all branches except dependabot/*, meaning that everyone can create dependabot/* branches (this is assuming that the "Branch targeting criteria" is smart enough to target all branches exceptdependabot/*, and if I'm understanding the docs correctly it should be).
The second rule should then prevent anyone that is not @dependabot from creating dependabot/* branches, making the dependabot/* exclusion of the first rule stricter.
IOW, the two rules are supposed to be ANDed and complement each other, and should work together -- or am I missing/misunderstanding something?
Only concern with just adding that ruleset and removing the corresponding Branch Protection rule is that I'm not totally sure how the other classic branch protection rules and rulesets interact, so it might be a good idea to just migrate the other rules to rulesets too.
My understanding is that the new rulesets can coexist with the classic rules -- with the former being more complex but flexible, and the latter simpler.
There is quite a big backlog, I ran dependabot on my fork and grouped all actions updates (I left the other ones, bumping package versions) into this branch, since seting up rulesets may take a while, do we want to update them all now?
Asking to learn and understand, is there a plan to use a different tool? There is a strong open-source alternative on the market, and in contrast to Dependabot, it works perfectly with the new age of Python tooling. I was wondering if the CPython project has any thoughts about it.
FTR, here's how I manage rulesets these days — separate per-function updates + allowing branches created by certain apps (and some personal exclusions sometimes):
By the way @davidism's got https://gha-update.rtfd.io which is a CLI tool to make action bumps in workflow and action definitions. It can be used to manage updates semi-manually or integrated into a home-grown automation.
@ambv could you add a bypass entry to the rulesets that block branch creation? It should end up looking like "Dependabot [App] github.com" at the top of the screenshot above.
Once done, we can test that it works even without adding app-specific branch patterns. This would be a short-term solution. And then, long-term, we'd consider integrating Renovate in its forking mode which would fullfil the requirement of not polluting upstream with temporary bot branches. We could also go to extremes and self-host the app but I don't see this being necessary.
Activity
hugovk commentedon Aug 16, 2025
Yes, but it's unlikely they'll create
dependabot/somethingby mistake. And the core and triage teams are a trusted group; if someone does create one as a workaround, we can ask them nicely not to and then clean up. (We could have Bedevere autoclose PRs from such branches when not authored by Dependabot, but hopefully it would not be a common thing.)When you fork a repo, by default it only copies the
mainbranch. If you opt-in to copy all branches, well, Dependabot PRs are usually merged fairly quickly and their branches short-lived, so you'll likely not get one. Even if you did, it's clear what the branch is for, and you can easily delete it.ZeroIntensity commentedon Aug 16, 2025
Hm, ok. I guess if it's once a month, it's not that bad.
AA-Turner commentedon Aug 17, 2025
I'd prefer to attempt exploring Peter's idea of syncing the PRs accross.
I take the arguments that it's a limited set of possible branch names, which are hopefully temporary. I think though we should be consistent with prohibiting all upstream branches or allowing them. We can make similar arguments for more exemptions in due course, where the root cause is that the service/tool (dependabot in this case) is insufficiently configurable. I can also see a realistic possiblilty that I update config in a future PR and accidentally push to upstream -- I name my branches in the
topic/subjectpattern, sodependabot/update-configis highly likely!Personally, I'd be +0 on keeping the prohibition on upstream branches (my editor auto-fetches all new branches but doesn't auto-delete), but I'd prefer that we go back to allowing branches than creating specific exemptions for tools -- we will inevitably forget why an exemption was first needed, and if it still is (c.f. the recent IRC ping webhook!).
A
ezio-melotti commentedon Sep 27, 2025
It should be possible to do this with 🔒 Branch rulesets, which are more fine-grained.
I think this can be achieved by:
**/*branch protection rule that prevents creations of new branchesdependabot/*and no bypasses (this will replace the previous rule):@dependabotto createdependabot/*PRs:Note that I haven't tried/tested this and that there might be other combinations of rules/rulesets that achieve the same result.
CAM-Gerlach commentedon Sep 30, 2025
I don't think that will work as-is unless my understanding of rule layering is incorrect, as the rules are AND-ed together and the more restrictive subset of the rules applies—i.e. the second rule wouldn't do anything to make the first rule less strict.EDIT: Somehow I totally missed seeing the exclude fordependabot/in the first rule, so that would work, although it may not be necessary to add a whole separate ruleset unless we want different rules to apply to the Dependabot branches.What should also work for now is just adding
Dependabotto the bypass list of the first rule asExempt, and no need for another. That would technically allow Dependabot to create other branches that aren'tdependabot/, but as it is a bot that always does this as part of its implicit contract (unless something goes horribly wrong), this shouldn't be an issue in practice (far less so than allowing anyone to createdependabot/branches). Here's a ruleset I've crafted on my fork of the CPython repo that should do the trick.Only concern with just adding that ruleset and removing the corresponding Branch Protection rule is that I'm not totally sure how the other classic branch protection rules and rulesets interact, so it might be a good idea to just migrate the other rules to rulesets too. They are more or less backwards compatible, have helpful additional options and customization, and rulesets can be exported and imported as JSON so non-admins (like myself, happy to help here) can craft and test them on our own forks, export them and then an admin can just import them on CPython and the other repos with similar rules (there's a verification step) instead of the awkward dance we had to do on python/core-workflow#460 with screenshots and manual admin time that took a couple rounds to get just right. This has been really helpful for Spyder as I've developed a standard set of rulesets (protect main/release branches, protect all tags, prevent creation of upstream branches) that can easily be applied across the repos in our organization.
FWIW, I've recently submitted an official detailed feature request to GitHub via internal channels (the GH Slack) regarding both this issue (Dependabot not supporting the standard fork workflow) and also the issue we found with the GitHub web UI where it does not offer the option to create a new branch on a fork when editing via the web UI if the user has write permissions, even if branch protection rules would prevent it.
Sidenote, but maybe this should be moved to core-workflow due to the topic and potential implications across other repos that use this pattern?
ezio-melotti commentedon Oct 1, 2025
The first rule should block creation of all branches except
dependabot/*, meaning that everyone can createdependabot/*branches (this is assuming that the "Branch targeting criteria" is smart enough to target all branches exceptdependabot/*, and if I'm understanding the docs correctly it should be).The second rule should then prevent anyone that is not @dependabot from creating
dependabot/*branches, making thedependabot/*exclusion of the first rule stricter.IOW, the two rules are supposed to be ANDed and complement each other, and should work together -- or am I missing/misunderstanding something?
My understanding is that the new rulesets can coexist with the classic rules -- with the former being more complex but flexible, and the latter simpler.
hugovk commentedon Oct 1, 2025
Good idea, and give a few people different roles on that fork to test it.
StanFromIreland commentedon Oct 5, 2025
There is quite a big backlog, I ran dependabot on my fork and grouped all actions updates (I left the other ones, bumping package versions) into this branch, since seting up rulesets may take a while, do we want to update them all now?
hugovk commentedon Oct 5, 2025
No rush to update as long as things are still working, and there's no important security updates.
We'll need to keep some pending so we can confirm Dependabot is working when we fix it :)
ulgens commentedon Jan 13, 2026
Asking to learn and understand, is there a plan to use a different tool? There is a strong open-source alternative on the market, and in contrast to Dependabot, it works perfectly with the new age of Python tooling. I was wondering if the CPython project has any thoughts about it.
hugovk commentedon Jan 13, 2026
You mean Renovate? I use it in other projects and recommend it.
But Renovate also creates PRs from branches in the project repo (or can that be configured?), so I expect the same problem will occur here?
webknjaz commentedon Jan 21, 2026
FTR, here's how I manage rulesets these days — separate per-function updates + allowing branches created by certain apps (and some personal exclusions sometimes):
By the way @davidism's got https://gha-update.rtfd.io which is a CLI tool to make action bumps in workflow and action definitions. It can be used to manage updates semi-manually or integrated into a home-grown automation.
webknjaz commentedon Jan 21, 2026
@hugovk apparently, they've got a solution for this: https://docs.renovatebot.com/getting-started/running/#forking-renovate-app / https://github.com/apps/forking-renovate. Though, it looks underdocumented currently: renovatebot/renovate#40574.
webknjaz commentedon Jan 21, 2026
@ambv could you add a bypass entry to the rulesets that block branch creation? It should end up looking like "
Dependabot [App] github.com" at the top of the screenshot above.Once done, we can test that it works even without adding app-specific branch patterns. This would be a short-term solution. And then, long-term, we'd consider integrating Renovate in its forking mode which would fullfil the requirement of not polluting upstream with temporary bot branches. We could also go to extremes and self-host the app but I don't see this being necessary.
webknjaz commentedon Feb 11, 2026
@ambv I've just confirmed that the bypass solution works on another project. Could you add
Dependabotto the bypass list in the respective ruleset?StanFromIreland commentedon Mar 14, 2026
Dependabot is back, e.g. #145946!
StanFromIreland commentedon Mar 14, 2026
I wrote #145947 to group the updates.
hugovk commentedon Mar 14, 2026
I replaced some old rules with new rulesets which allow Dependabot to create branches.
actions/checkout@v6andactions/setup-python@v6to avoid the deprecated warning in capi-docs checking #145941 as a duplicate of this issuegh-137650: Group dependabot actions updates (#145947)
pythongh-137650: Group dependabot actions updates (python#145947)