Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Extract the contents of the source tarball and build it with an empty maven cache by renaming your ~/.m2 directory before doing the build.
  2. Check the size of the output binary tarball for significant size increase from the last release.
    1. The Apache servers currently have a limit of 350mb for release artifacts.
    2. A significant increase in size could indicate a dependency issue that needs to be fixed.
    3. The Apache svn repo has a size limit for release artifacts. If uploading svn fails because the tarball is too big, we need to contact INFRA to increase our repo size. See here for details.
  3. Verify signatures
    1. Download the KEYS file from  https://dist.apache.org/repos/dist/release/ozone/KEYS
    2. Import its contents (which should include your public gpg key): gpg --import KEYS 
    3. Verify each .tar.gz artifact: gpg --verify <artifact>.tar.gz.asc <artifact>.tar.gz 
  4. Verify checksums
    1. Run shasum -a 512 *.tar.gz 
    2. Verify that the output checksums for each artifact match the contents of its .sha512 file and the SHA512 line in its .mds file.
  5. Make sure docs are present in the release tarball
    1. There should be a directory called docs in the top level. If there is not, then hugo  was not installed during the build and it must be re-done.
    2. Extract the release and open docs/index.html in your web browser, and check that the documentation website looks ok.
  6. Check the output of running  bin/ozone version  from the extracted release tarball
    1. After extracting the release, the output of this command should contain:
      1. The correct release
      2. The correct national park tag
      3. A non-snapshot version of Ratis.
      4. A link to the apache/ozone GitHub repository (not your fork).
      5. The git hash of the last commit the release was built on.
  7. Run the Ozone upgrade acceptance tests by running test.sh  from the compose/upgrade directory in the extracted release tarball.
    1. This check is also run by the GitHub actions CI for each commit, so it should pass with no surprises.

...