yihua opened a new issue, #754:
URL: https://github.com/apache/hudi-rs/issues/754
The publish workflow fans out into four jobs that each publish independently:
```
validate-release-tag
├── release-crates -> publishes to crates.io
├── release-pypi-mac -> publishes to PyPI
├── release-pypi-windows -> publishes to PyPI
└── release-pypi-manylinux -> publishes to PyPI
```
Nothing gates one on another, so each uploads as soon as its own build
succeeds. When one of them fails, the others have already published, and the
release cannot be repaired in place: crates.io does not allow a version to be
published twice, so the whole release has to move to a new RC number.
This is what happened with `0.5.0-rc.1` (#750). The manylinux job failed
while all three crates had already gone to crates.io and the macOS and Windows
wheels had already gone to PyPI. The result is a version that is permanently
taken, with a PyPI release that has no Linux wheel and no sdist.
Splitting the workflow into a build phase and a publish phase would contain
this: build every wheel and the sdist first, upload them as workflow artifacts,
and run the publish jobs only once every build has succeeded. A build failure
then costs a re-run rather than a version number.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
