Clean up appveyor.yml #147
Conversation
- Make sure that the Python we want actually exists (and install it if necessary) -- this will make our lives easier next year, when Python 3.9 shows up - Make the test run quiet (setup.py test -q ignores the -q) - Pass --skip-existing to twine upload so the build of the tag can be retried if necessary without causing spurious failures I think it might also be a good idea to add a custom version template to avoid nonsense like https://ci.appveyor.com/project/mgedmin/zope-interface/builds/28770734, but I'm not entirely sure what happened there and whether a custom version template would help. (All I know is all my project appveyors YML have `version: build-{build}-{branch}` and I've never seen that kind of error.)
There was a problem hiding this comment.
LGTM.
I don't understand the comment about a custom version template. For whatever reason, I can't see any test output at https://ci.appveyor.com/project/mgedmin/zope-interface/builds/28770734.
Nothing is clickable. Navigating to that build starting from the main zope.interface History page doesn't help.
Appveyor assigns each build a version number: https://www.appveyor.com/docs/build-configuration/#build-versioning. This number must be unique. Somehow, when I ran zest.releaser and pushed to GitHub, appveyor managed to assign the same build number to two different builds:
as a result, one of the two builds failed with the error message you've screenshotted. I've restarted the build for that commit, which created a new version number: I don't want to do this every time somebody pushes a release. I think it's a bug on appveyor's side, but I wonder if I could use the configurable version format setting in appveyor.yml to avoid it in the future? |
|
Looking at https://ci.appveyor.com/project/mgedmin/findimports/history I think it would work!
There was no race condition in the screenshot ({build} was expanded to 34 and 35), but if that had happened, there would've been no conflict, as {branch} was expanded to the git tag for one build and 'master' for the other build. |
|
|
||
| artifacts: | ||
| - path: 'dist\*.whl' | ||
| name: wheel | ||
|
|
||
| deploy_script: | ||
| - ps: if ($env:APPVEYOR_REPO_TAG -eq $TRUE) { pip install twine; twine upload dist/* } | ||
| - ps: if ($env:APPVEYOR_REPO_TAG -eq $TRUE) { pip install twine; twine --skip-existing upload dist/* } |
There was a problem hiding this comment.
This part was not so good: https://ci.appveyor.com/project/mgedmin/zope-interface/builds/28777006/job/g40lp9dhkof95mf2
Fixed in 1a84324.
Make sure that the Python we want actually exists (and install it if
necessary) -- this will make our lives easier next year, when Python
3.9 shows up
Make the test run quiet (setup.py test -q ignores the -q)
Pass --skip-existing to twine upload so the build of the tag can be
retried if necessary without causing spurious failures
I think it might also be a good idea to add a custom version template to
avoid nonsense like https://ci.appveyor.com/project/mgedmin/zope-interface/builds/28770734,
but I'm not entirely sure what happened there and whether a custom
version template would help. (All I know is all my project appveyors
YML have
version: build-{build}-{branch}and I've never seen that kindof error.)