Avoid spurious "failures" on Appveyor during releases

[mgedmin]

PowerShell interprets any stderr output from a child process as an
error. This means warnings from pip about using
not-the-very-latest-version-how-dare-you and warnings from twine about
uploading the *.tar.gz which was probably already uploaded already and
might not be a bitwise identical copy because what even is
reproducibility cause the Appveyor builds to fail, even if the actual
binary wheels we want have been built and uploaded successfully.

pauses to breathe

[jamadden]

Yikes. LGTM, if we assume that the releasing person already uploaded the .tar.gz.

The rebuild of the 4.5.1 tag and wheels is my fault, I had to repush to get Travis to build mac and manylinux wheels (I had zest.releaser globally configured to add '[skip ci]' to the tag commit message because usually that's not necessary. It puts it on the third line of the message, which appveyor ignores but travis detects.)

[mgedmin]

LGTM, if we assume that the releasing person already uploaded the .tar.gz.

I usually do releases with zest.releaser which uploads the .tar.gz.

Perhaps we could use twine upload --skip-existing?

The rebuild of the 4.5.1 tag and wheels is my fault, I had to repush to get Travis to build mac and manylinux wheels

Is this why the 4.5.1 tag is not on the master branch's history? Personally I'd prefer if you forced-push directly to master for such situations, because tags hanging off to a side are a pain with git (e.g. git fetch won't fetch them -- unless you do an explicit git fetch --tags -- and so git tag -l won't list them, and all my release automation that assumes every release has a tag breaks).

Is there any reasonable way you could prevent such accidents in the future? E.g. local zest.releaser configuration overrides to remove the [skip ci] bit in the setup.cfg of every zopefoundation package would be fine by me.

[mgedmin]

FWIW I'm experimenting with twine upload --skip-existing in zopefoundation/zodbpickle#39.

[jamadden]

I usually do releases with zest.releaser which uploads the .tar.gz.

Me too.

Perhaps we could use twine upload --skip-existing?

That might be a good idea.

Is this why the 4.5.1 tag is not on the master branch's history?

I'm not sure what you mean. I see the 4.5.1 tag in the drowdown list on github and can browse into it (https://github.com/zopefoundation/BTrees/tree/4.5.1). It shows up in a 'git tag -l' on a fresh clone.

Personally I'd prefer if you forced-push directly to master for such situations, because tags hanging off to a side are a pain with git (e.g. git fetch won't fetch them -- unless you do an explicit git fetch --tags -- and so git tag -l won't list them, and all my release automation that assumes every release has a tag breaks).

I thought all I did was move the tag to a new commit that I'd reworded.

Is there any reasonable way you could prevent such accidents in the future? E.g. local zest.releaser configuration overrides to remove the [skip ci] bit in the setup.cfg of every zopefoundation package would be fine by me.

I just removed the offending configuration from my ~/.pypirc, so it won't happen again from me. We could try putting extra-message = in the [zest.releaser] section of each setup.cfg that builds and deploys wheels in case others have a similar configuration.

[jamadden]

I'm not sure what you mean

Oh, I think I understand. 5bcc3de is still in master with the [skip ci] text and isn't pointed to by the tag.

[mgedmin]

The --skip-existing solution works fine: https://ci.appveyor.com/project/mgedmin/zodbpickle/build/1.0.48 is all green!