Repository navigation
Make cherry_picker configurable and customizable for other projects #225
Description
I've chatted with @asvetlov regarding aio-libs and aiohttp project, specifically regarding the workflow of backporting PRs (ref aio-libs/aiohttp#2853). They have very similar workflow with CPython, but things are still done manually there. I figured automations like cherry_picker and miss-islington will be useful for them, and likely for other projects too.
Currently cherry_picker has a number of hardcoded values and assuming the repo is CPython.
We should be able to make those configurable via a config file, so it can be adapted to other projects.
The final goal of aio-libs is to have bot similar to miss-islington to automatically backport PRs, but it depends on cherry_picker to do the actual backporting.
Questions
Are we (core devs) comfortable with making cherry_picker more general purpose? What could go wrong?
Configurable items
Only these two things need to be converted from hardcoded values into configuration items. Maybe inside a yaml file.
- the name of the repo, instead of hardcoded to
cpython. - how to detect if cherry_picker is in the right repo? Currently to detect if we are inside CPython's repo, it does
git log -r 7f777ed95a19224294949e1b4ce56bbffcb1fe9f.7f777ed95a19224294949e1b4ce56bbffcb1fe9fis the hash of the first ever commit to CPython. This hash can be in a config file.
Readme should be updated, explaining how to configure things.
In addition, we are already considering adding configuration file for other purpose (https://github.com/python/core-workflow/issues/107).
What won't change
Will not support Python < 3.6.
Compatibility with core Python's workflow and miss-islington will always be priority.
Limitations
cherry_picker might not work for projects where their backport branch names are not in the format of X.Y. There is logic in place where we sort the backport branches, backporting to the newest branch first.
Activity
brettcannon commentedon Mar 29, 2018
I don't see anything wrong with this. Would you have miss-islington read from a config and then call cherry_picker as appropriate? Or would you have cherry_picker be the one that takes the config?
Mariatta commentedon Mar 29, 2018
I'm thinking we can pass in the path of the config file to cherry_picker. If the path is not provided, it will assume the default (CPython).
So miss-islington and current CPython contributors don't need to worry about configuring anything.
asvetlov commentedon Mar 30, 2018
My 5 cents: better to not require the path-to-config passing into cherry_picker but do lookup for config file by the tool itself.
When I do manual cherry-picking of CPython PR I don't specify the path. I would not do it on manual cherry-picking of aiohttp PR as well.
asvetlov commentedon Mar 30, 2018
Defaults should remain (use CPython settings) if no config file exists in the repo, sure.
asvetlov commentedon Mar 30, 2018
Next question is what config file name should we support.
I'm inclining to
[tool:cherry-picker]section insetup.cfgbut we could provide.cherry-picker.inior.cherry-picker.tomlas well.Mariatta commentedon Mar 30, 2018
I'm thinking to go with
cherry-picker.tomljust because we already have apyproject.toml:)asvetlov commentedon Mar 30, 2018
Hide the config maybe by
<dot>prefix:.cherry-picker.toml.Like
.gitignore,.travis.ymland.pyup.yml.I expect to don't see cherry-picker config on
lsexecution.Mariatta commentedon Mar 30, 2018
Sounds good.