Closed rkm closed 2 years ago
pre-commit.ci really only knows about the default branch and pull request branches, I'm not sure how it would know to discover specific ones
I'm open to the idea but I have no idea how it would work
Yeah I think this would require a configuration value to be stored somewhere, either in a file in the repo or somewhere in the web component. Is that something you're hoping to avoid?
One option could be to have an optional section in .pre-commit-config.yaml
which the CI runner could look for.
there will be a section in the pre-commit config at some point. even with that though I don't know how it would work:
@asottile, good question indeed about the source of truth, in case various branches have different config value for the auto-update branch. Instead of being in the yaml file, could it be exposed as a configuration option for each repo in the commit-ci account?
accounts are entirely ephemeral (to satisfy a minimal privacy policy). I don't really want to store anything there
ok. I would consider it correct if it auto-updates on any branch where the name in the configuration is equal to that same branch name
We also have some issues with the current way this works (develop branch with main/default branch for releases) - having an option in the pre-commit.ci configuration file to specify the branch to autoupdate against would be nice.
Given that accounts are ephemeral I think that would mean the default/main branch would need to be the source of truth for the pre-commit.ci config file autoupdate settings (which should change pretty infrequently). Then that source of truth is telling pre-commit.ci that the source of truth for autoupdating the hooks is an alternate branch instead of the default.
pre-commit.ci running on pushes to a develop branch might not be essential... it already runs for PRs targeting develop, which should do a decent job of keeping pre-commit checks passing before merging develop to main.
@nightlark yeah that sounds like a reasonable idea.
would something like this satisfy everyone's usecases?
# in the `HEAD` branch for the repository
ci:
autoupdate_branch: develop
that would point the autoupdater to try and rewrite the develop
branch instead of whatever origin/HEAD
is?
That's pretty much exactly what I imagined and should cover the two most common git workflows. There are a few other CI systems that have config options that depend on changes being made to a file in the HEAD
branch of a repository (GitHub Actions workflow_dispatch
not showing a manual trigger button being one such instance), so particularly if this is mentioned in the docs, the behavior wouldn't be unheard of.
Another idea that comes to mind that would significantly increase the flexibility (though more complex to implement on your end) would be if autoupdate_branch
was treated as a regex (or GitHub pattern matching and allow using a list for the option) that made the autoupdater try to update any branches in the remote that matched.
e.g. autoupdate_branch: develop|release-.*
or autoupdate_branch: ["develop", "release-*"]
to autoupdate the develop branch and maintenance branches for releases.
I thought about that, but then it becomes expensive quick (additional HUGE paginated branch query, potentially many many PR creations)
and autoupdate is already kinda pricey -- so I'm probably going to limit it to only one branch
this is done! the docs live here: https://pre-commit.ci/#configuration-autoupdate_branch
thanks again for the issue
Thanks, that was fast! Looking forward to the new setting taking effect after the updated config makes its way into our main branch this upcoming week.
Hello hello. I had a peek at the other issues but didn't spot this exact question.
For similar tools such as dependabot, you're able to specify the target/base branch that the autoupdate is run against and merged back into. I think pre-commit-ci currently only supports the default branch though, which works well for "live at head" git workflows but not others. Would it be possible to support this feature?