search

mockito / shipkit

Toolkit for shipping it used by Mockito library
http://shipkit.org
MIT License
158 stars 35 forks source link

Reduce number of open PR requests created automatically #460

Open szpak opened 6 years ago

szpak commented 6 years ago

Description

Currently Shipkit creates a separate PR in a downstream project for every released version. With high pace of development in a situation they are not merged/closed regularly there could be a number of open PRs which reduces visibility and they have to be closed manually.

Proposed solution

mockitoguy commented 6 years ago

Neat idea! Do you want to take a stab at it?

Updating PR has slightly better UX but it may be more problematic to implement/add complexity. +1 to closing PR.

szpak commented 6 years ago

I consider that. It's quite a separate topic, so maybe I will have a chance to practice Kotlin a little bit :).

wwilk commented 6 years ago

I like the idea!

Closing the previous PR would be quite simple - basically two GH API calls, one for all pull requests, and then another to close some of them (usually one). It would be also good to clean up the mess (delete the branch).

The second solution - first check if there are open PRs. If not then we don't need to do anything. Otherwise we find the latest PR (GH API call), checkout the proper branch (easy - naming convention), do a version update as we do now, and then update PR instead of creating a new one.

As @szczepiq said I think the second solution would have better UX (less CRs to get around) but since these PRs may live longer, the risk of conflict with other changes is bigger. Of course this kind of conflicts can be resolved quickly and directly on GitHub but it puts this job on user.

So I think the first one is good enough.

@szpak About Kotlin - it seems that we don't have any decision yet if we are going in this direction https://github.com/mockito/shipkit/issues/453 What is your opinion about it?

LunNova commented 6 years ago

As @szczepiq said I think the second solution would have better UX (less CRs to get around) but since these PRs may live longer, the risk of conflict with other changes is bigger. Of course this kind of conflicts can be resolved quickly and directly on GitHub but it puts this job on user.

It should be possible to do the second solution, but reset to the master branch before doing the update and force push with lease to the PR branch. This would avoid building up repeated update commits and avoid merge conflicts.

szpak commented 6 years ago

@wwilk If the first solution can be delivery much faster it would be probably good to have it up and running. Then, that issues could be closed and the another enhancement could be created with "please contribute!" label waiting for someone interested in that feature having enough time to play with it.

mockitoguy commented 6 years ago

Upgrade downstream creates a lot of PRs. Let's try to limit amount of PRs open, if possible. It will add complexity but on the other hand a lot of closed PRs will spoil the history of PRs, will get searching through PRs harder.

I'm changing my vote, I'm +1 to a solution updates the existing PR.

One more consideration: we can add an option for upgrade-downstream to wait for PR build to complete and automatically merge it... This will prevent proliferation of open PRs and improve the automation in general.

Finally, the upgrade downstream feature is amazing. I absolutely love it! I did not expect this coming :)