1.5 release #100
1.5 release #100
Conversation
Adds explicit tests for api_version.
|
I'm a little confused why this PR is still open but the 1.5 release tag already up on PyPI? |
|
Because a (flaky) test failed on the tag, which is the same commit as the PR, so it didn't merge. |
|
Hmm, that seems a bit unhealthy. Don't rely on auto-merge for future tags I guess, but only push them when the release commit to be tagged is merged? |
|
I do it that way on purpose, because if the publish build fails I have to delete the tag and try again. That happened with the last release because I forgot to bump the version, and it almost happened again this release. I prefer for "PR merged" to mean "the release is complete". If I see the PR is open that means there is still something left to do. I don't "rely" on auto-merge, but rather just use it as a way of saying "everything is good from my end, if the tests pass you can merge". It's annoying that GitHub stops a PR merge because of tag builds, since they are on the same commit. Of course the real issue here is the flakeyness of the tests, but that is just the nature of this project unfortunately. |
|
Makes sense, thanks for the context. Pushing the tag before everything else is 100% complete never works if there's builds that can fail. The risk here seems rather low that the tag has to be moved. Making the publish job run only after the other jobs all complete would be an alternative - but that slows down regular CI, so also not ideal. |
|
I think the publish build doesn't actually get cancelled by other builds, but it's hard to tell. |
No description provided.