henrikingo commented on code in PR #159: URL: https://github.com/apache/otava/pull/159#discussion_r3264873178
########## docs/RELEASE.md: ########## @@ -376,9 +464,12 @@ Once the release candidate has been reviewed and approved by the project and Inc In `otava-dist-release-repo`: ```bash -cp -r $RELEASE_VERSION-incubating-$RELEASE_CANDIDATE $RELEASE_VERSION-incubating +cp -r $OTAVA_SVN_DEV/$RELEASE_VERSION-incubating-$RELEASE_CANDIDATE $OTAVA_SVN_REL/$RELEASE_VERSION-incubating +cd $OTAVA_SVN_REL +svn update && svn status Review Comment: Thanks. I wasn't sure if these are the same repo or independent/ if this is possible. Certainly makes sense if it is. ########## docs/RELEASE.md: ########## @@ -220,12 +289,28 @@ sha512sum --check apache_otava-$RELEASE_VERSION-py3-none-any.whl.sha512 ### Publish Release Candidate ```bash -cp -r release ../otava-dist-release-repo/$RELEASE_VERSION-incubating-$RELEASE_CANDIDATE -cd ../otava-dist-release-repo +cp -r release $OTAVA_SVN_DEV/$RELEASE_VERSION-incubating-$RELEASE_CANDIDATE +cd $OTAVA_SVN_DEV +svn update && svn status + svn add $RELEASE_VERSION-incubating-$RELEASE_CANDIDATE/ -svn ci -m "[otava] Add $RELEASE_VERSION-incubating-$RELEASE_CANDIDATE" +svn ci -m "[otava] Upload $RELEASE_VERSION-incubating-$RELEASE_CANDIDATE for review and voting" +``` + +### Publish PyPI artifacts on test.pypi.org + +In svn dev/preview directory: + +```bash +# Go to dev/preview svn directory +cd $OTAVA_SVN_DEV +cd $RELEASE_VERSION-incubating-$RELEASE_CANDIDATE/pypi +# Publish to Test PyPI +twine upload --verbose --repository testpypi apache_otava-$RELEASE_VERSION-py3-none-any.whl apache_otava-$RELEASE_VERSION.tar.gz +# Verify at https://test.pypi.org/project/apache-otava/ ``` + Review Comment: This is a good point worth discussing. I moved this earlier in the process, because: * test.pypi.org in itself is 100% for testing purposes, and nothing published there can be considered a release. (Whether GA, RC or something else) * It is however the case, that this step loses the "-rcN" provenance completely. The files uploaded are identical to the files that are later published as GA. * or... if the vote fails, the files are not identical in their content but filenames and version strings are already same as they will be for the successful GA release, once it happens. * One reason to do it this way is that the sha512 signatures reference the file name of what they signed, so we cannot rename files (from *-rc1.tar.gz to *.tar.gz) without having to also edit or recreate contents of a file. * Essentially the model we are close to here is "channels", which I've mostly seen used in K8s ecosystem. Te binary or tar archve is built once, then promoted to different channels as it is condsidered Now, if I interpret you correctly, we should rather adhere to a policy where release files may (in practice) only leave ASF maintained infrastructure once the vote has passed. This is possible to do (the previous 0.8.0-incubating release was done like that). The challenge in this approach is that there's a heightened risk we approve a release, then realize it can't be published on pypi or dockerhub due to some restriction we aren't meeting correctly.. Leading to a spiral of repeat votes to get one release properly into teir channels. *** So to answer your question/requirement succinctly: These files wold NOT be marked as -rcN, or anything else that identifies them as a release canidate, rather their context should presumably make it clear they are only publised for tesing. -- 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]
