cherry_picker 1.3.1 breaks miss islington

[JulienPalard]

See python/miss-islington#219

I reverted cherry_picker to 1.2.2 and the "bug" dissapeared. @ewdurbin did not found nothing in the logs, and myself has not really investigated the issue more than checking if reverting fixes it.

[Mariatta]

GitMate.io thinks possibly related issues are #257 (🤖 miss-islington Heroku app errors), python/miss-islington#7 (Trigger the backport by leaving comments to miss-islington), #121 (Missed code style in cherry_picker/readme.rst), #63 (cherry_picker needs Python 3.6), and #56 (cherry_picker.py requires Python 3.6).

[webknjaz]

So #315 wasn't enough? Feel free to ping me with new info since it's probably my change that caused the regression.

[samdoran]

I am hitting this issue using cherry_picker 1.3.1 and 1.3.0 with Ansible. It seems it sets state = BACKPORT_COMPLETE in the local git config, resulting in an error on subsequent runs.

sdoran@mbp-2018 ~/S/ansible (devel) [2]> tail -n 2 .git/config
[cherry-picker]
	state = BACKPORT_COMPLETE

> cherry_picker --pr-remote fork f27eccabbd stable-2.7
🐍 🍒 ⛏
Usage: cherry_picker [OPTIONS] [COMMIT_SHA1] [BRANCHES]...
Try "cherry_picker -h" for help.

Error: Run state cherry-picker.state=BACKPORT_COMPLETE in Git config is not known.
Perhaps it has been set by a newer version of cherry-picker. Try upgrading.
Valid states are: BACKPORT_PAUSED, UNSET. If this looks suspicious, raise an issue at https://github.com/python/core-workflow/issues/new.
As the last resort you can reset the runtime state stored in Git config using the following command: `git config --local --remove-section cherry-picker`

Clearing that section from the local config gets around the issue.

Reverting to cherry_picker==1.2.2 also works.

[webknjaz]

@samdoran I'm pretty sure that the issue has been created by 1.3.0. 1.3.1 doesn't clear that (by design). After cleaning up the state, 1.3.1 should work. BACKPORT_COMPLETE state has been completely removed from the source code so you can't get that anymore.

[webknjaz]

@Mariatta @JulienPalard @samdoran @asvetlov it turned out that the dists on PyPI (both wheel and tarball) contain an outdated version of the source code prior to #315 which is why 1.3.1 is still broken.

I'll try to track down how this happened now.

[asvetlov]

Thanks!

[webknjaz]

So the tag points to the branch which doesn't have the relevant commit there: https://github.com/python/core-workflow/releases/tag/cherry-picker-v1.3.1
Build: https://travis-ci.org/python/core-workflow/builds/507624424

It points to a commit in the release PR https://github.com/python/core-workflow/pull/317/commits (5e60b22).
But that tree doesn't contain the "merge" commit 04b6587 which has the necessary changes: https://github.com/python/core-workflow/commits/5e60b229027ac70b0a68dd4d36ac68f9bee53fd4

...
|
* b93c761 Cherry-picker post release changes (#318)
|
* 4a3a323 Release 1.3.1 (#317)
* a48e378 Moderninze the pyproj.toml (#316)
| * 5e60b22 (tag: cherry-picker-v1.3.1, refs/pull/origin/317) merge conflict wasn't resolved properly
| * d354dc0 Release 1.3.1
* | 04b6587 Cherry-picker: Remove BACKPORT_COMPLETE. UNSET state after finished. (#315)
|/  
* 9cf0ac1 cherry-picker: Run Travis CI test on Windows (#311)
|
...
(master)

As you can see that PR's branch derives from 9cf0ac1 which doesn't yet have the bugfix.

[webknjaz]

@Mariatta the only fix here is to cut the new release. Just make sure to merge everything before creating a branch for that.

[Mariatta]

Sorry for the delay and the trouble. v1.3.2 has just been released to fix this. Thanks.