@serhiy-storchaka Do you have an example of such PR?

I usually look at documentation changes, so I'm not familiar with make regen-all.

1. Is there a way to detect when make regen-all should be run? For example, what are the affected paths?

2. Will it hurt if we run make regen-all for each backport?

Thanks :)

and should this be done even when using cherry-picker.py command line?

The recent example: python/cpython#4118.

For running make regen-all you need more than just git. First, you need to run ./configure. For regenerating the grammar parser you need to build and run a special binary. All this takes a time. It is more efficient to run different commands depending on the files containing conflicts.

We're running the webservice in heroku, and I don't think we can run ./configure from within heroku, it doesn't have the necessary software/libraries installed.
So I don't think we can do this.

I think https://github.com/heroku/heroku-buildpack-apt could work here.
Someone would need to run apt build-dep python3.7 on a system similar to Heroku to generate the list of required packages and write it to a file named «Aptfile».

Then the issue may be limitations (time) on background jobs or one-off dynos or whatever is used to run configure.

Time shouldn't be an issue. Backport jobs are all done in the worker dyno.

But I don't know a thing about the buildpack in Heroku..

I’ve used that buildpack (in addition to the base Python buildpack), would be happy to discuss setting it up!

perhaps even a custom merge driver could be written for this? (at least, specifically for the argument clinic files which is what I hit in python/cherry-picker#18)

and then the various cherry-picking / etc. tooling can use that merge driver?