Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

All commit authors signed the Contributor License Agreement.

Thanks for the PR, we updated a bunch of actions just last week (#143757), but I guess some are from just landed PRs.

Anyway, is there anything particularly urgent about these updates?

I'd rather we fix the problem why Dependabot is broken, so we can have automation that respects the cooldown; see #137650.

@hugovk Not urgent as such, my motivation is this announcement that takes effect in April. So depends on your confidence in Dependabot being back up and running by that time as some of these actions may no longer work.

@hugovk I've just looked at why dependabot "isn't running": it actually does run but the repo's branch rulesets prevent the branch creation. Here's where you can start Dependabot manually (I just did to test what's happening): https://github.com/python/cpython/network/updates/7299823/jobs. Here's the underlying tooling logs: https://github.com/python/cpython/actions/workflows/dependabot/dependabot-updates. But the PR creation happens outside those GHA jobs, which is why the jobs are green, while the dedicated repo deps page reveals the PR creation problem:

[!error]
Dependabot failed to create a pull request
Dependabot ran into an issue when attempting to create the pull request

Dependabot encountered the following error:

Failed publishing content to GitHub: Couldn't update "dependabot/github_actions/actions/setup-python-6": Cannot change this locked branch You're not authorized to push to this branch. Visit https://docs.github.com/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches for more information.

Troubleshoot Dependabot errors

@ambv do you need help fixing the repo settings? What needs to be done is excluding certain branch patterns for the branch names dependabot creates. I usually also add patterns for other known apps and GitHub features — namely pre-commit.ci, GitHub's own Merge Queues and my own DIY lockfile updaters. Unfortunately, none of the automations are able to create such branches in forks. If we want in-fork branches, we'd have to have our own automations.

@webknjaz See the discussion about rulesets in #137650

@pgoslatara thanks for the link! In the future, I recommend including the context/motivation right in the PR description — this is the first thing people see when they open PRs to see what's inside. It's nice that you explained what the patch does but folks would also be looking to understand why and might jump to conclusions if there's no clear reason.

@hugovk I've just looked at why dependabot "isn't running":

@webknjaz Indeed, see #137650.

Some didn't want to allow dependabot/* because it means the core team could also use that pattern to get around the branch restriction, but I think that's unlikely and we should rather fix Dependabot.

There's a further suggestion to use rulesets that would also only allow Dependabot using that pattern, but no-one has worked on it.

@hugovk ack, I just left a comment in there. I've got some experience with rulesets + automating updates in less mainstream ways..

@webknjaz so I should allow creation of "dependabot/*" branches?

@ambv apparently, folks in #137650 are hesitant. If nobody objects, then yes — a branch name pattern exclusion from the rule is what you need to add, but the pattern that worked for me is dependabot/**/* to cover the slashes (these are fnmatch wildcards as implemented in Ruby, IIRC). Although, it might be enough to list the Dependabot app as allowed to bypass the rule. I'd try that first, it should be less controversial.