bharos opened a new issue, #13637: URL: https://github.com/apache/gravitino/issues/13637
### What would you like to be improved? Two release-script behaviours made the 1.3.1 run harder than it needed to be. Both share a shape: a step that cannot be retried, or one that reports success without doing anything. **1. `finalize` cannot be re-run once it reaches PyPI.** The stage runs: git tag, build the Python dist, `twine upload`, `svn mv` from dev to release, KEYS sync. The `twine upload` has no `--skip-existing`, so a second attempt fails with `400 File already exists` before it reaches the svn steps. The stage writes no marker on failure, so `do-release.sh` restarts it from the top and hits the same wall every time. This bites hardest because the `svn mv` needs `dist/release` karma, which is PMC-only. A release manager without it fails at exactly the step that cannot be retried, after the PyPI version is already spent. In 1.3.1 the tag was pushed and the package uploaded, then: ``` svn: E175013: Access to '/repos/dist/!svn/rvr/88099/dev/gravitino/v1.3.1-rc3' forbidden ``` The same applies to the RC upload in the `package` stage. **2. `publish-docker.sh --dry-run` blocks the real run, and the block reports success.** The state marker is written on every run, including dry runs, but the skip guard only tests that the file exists. So the documented "preview first" workflow disables the real run, which exits 0 with `Stage 'docker' is already complete` having dispatched nothing. Nobody finds out until someone pulls the tag. ### How should we improve? Add `--skip-existing` to both `twine upload` calls, and have the docker guard ignore a marker that records a dry run. -- 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]
