[FLINK-33348] CLONE - CLONE - Build and stage Java and Python artifacts

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.18.0
• Assignee: Jing Ge
• Reporter: Jing Ge
• Created: 24/Oct/23 12:42
• Updated: 24/Oct/23 12:44
• Resolved: 24/Oct/23 12:44

Description

1. Create a local release branch ( this step can not be skipped for minor releases):

   $ cd ./tools
   tools/ $ OLD_VERSION=$CURRENT_SNAPSHOT_VERSION NEW_VERSION=$RELEASE_VERSION RELEASE_CANDIDATE=$RC_NUM releasing/create_release_branch.sh
   

2. Tag the release commit:

   $ git tag -s ${TAG} -m "${TAG}"
   

3. We now need to do several things:
   1. Create the source release archive
   2. Deploy jar artefacts to the Apache Nexus Repository, which is the staging area for deploying the jars to Maven Central
   3. Build PyFlink wheel packages
      You might want to create a directory on your local machine for collecting the various source and binary releases before uploading them. Creating the binary releases is a lengthy process but you can do this on another machine (for example, in the "cloud"). When doing this, you can skip signing the release files on the remote machine, download them to your local machine and sign them there.
4. Build the source release:

   tools $ RELEASE_VERSION=$RELEASE_VERSION releasing/create_source_release.sh
   

5. Stage the maven artifacts:

   tools $ releasing/deploy_staging_jars.sh
   

   Review all staged artifacts (https://repository.apache.org/). They should contain all relevant parts for each module, including pom.xml, jar, test jar, source, test source, javadoc, etc. Carefully review any new artifacts.

6. Close the staging repository on Apache Nexus. When prompted for a description, enter “Apache Flink, version X, release candidate Y”.
   Then, you need to build the PyFlink wheel packages (since 1.11):
7. Set up an azure pipeline in your own Azure account. You can refer to Azure Pipelines for more details on how to set up azure pipeline for a fork of the Flink repository. Note that a google cloud mirror in Europe is used for downloading maven artifacts, therefore it is recommended to set your Azure organization region to Europe to speed up the downloads.
8. Push the release candidate branch to your forked personal Flink repository, e.g.

   tools $ git push <remote> refs/heads/release-${RELEASE_VERSION}-rc${RC_NUM}:release-${RELEASE_VERSION}-rc${RC_NUM}
   

9. Trigger the Azure Pipelines manually to build the PyFlink wheel packages
   1. Go to your Azure Pipelines Flink project → Pipelines
   2. Click the "New pipeline" button on the top right
   3. Select "GitHub" → your GitHub Flink repository → "Existing Azure Pipelines YAML file"
   4. Select your branch → Set path to "/azure-pipelines.yaml" → click on "Continue" → click on "Variables"
   5. Then click "New Variable" button, fill the name with "MODE", and the value with "release". Click "OK" to set the variable and the "Save" button to save the variables, then back on the "Review your pipeline" screen click "Run" to trigger the build.
   6. You should now see a build where only the "CI build (release)" is running
10. Download the PyFlink wheel packages from the build result page after the jobs of "build_wheels mac" and "build_wheels linux" have finished.
    1. Download the PyFlink wheel packages
       1. Open the build result page of the pipeline
       2. Go to the Artifacts page (build_wheels linux -> 1 artifact)
       3. Click wheel_Darwin_build_wheels mac and wheel_Linux_build_wheels linux separately to download the zip files
    2. Unzip these two zip files

       $ cd /path/to/downloaded_wheel_packages
       $ unzip wheel_Linux_build_wheels\ linux.zip
       $ unzip wheel_Darwin_build_wheels\ mac.zip

    3. Create directory ./dist under the directory of flink-python:

       $ cd <flink-dir>
       $ mkdir flink-python/dist

    4. Move the unzipped wheel packages to the directory of flink-python/dist:

       $ mv /path/to/wheel_Darwin_build_wheels\ mac/* flink-python/dist/
       $ mv /path/to/wheel_Linux_build_wheels\ linux/* flink-python/dist/
       $ cd tools

Finally, we create the binary convenience release files:

tools $ RELEASE_VERSION=$RELEASE_VERSION releasing/create_binary_release.sh

If you want to run this step in parallel on a remote machine you have to make the release commit available there (for example by pushing to a repository).
This is important: the commit inside the binary builds has to match the commit of the source builds and the tagged release commit.
When building remotely, you can skip gpg signing by setting SKIP_GPG=true. You would then sign the files manually after downloading them to your machine:

$ for f in flink-*-bin*.tgz; do gpg --armor --detach-sig $f; done
$ gpg --armor --detach-sig apache-flink-*.tar.gz

The release manager need to make sure the PyPI project apache-flink and apache-flink-libraries has enough available space for the python artifacts. The remaining space must be larger than the size of tools/releasing/release/python. Login with the PyPI admin account (account info is only available to PMC members) and check the remaining space in project settings.

Request an increase if there's not enough space. Note, it could take some days for PyPI to review our request.

 

---

Expectations

• Check hashes (e.g. shasum -c *.sha512)
• Check signatures (e.g. gpg --verify flink-1.2.3-source-release.tar.gz.asc flink-1.2.3-source-release.tar.gz)
• grep for legal headers in each file.
• If time allows check the NOTICE files of the modules whose dependencies have been changed in this release in advance, since the license issues from time to time pop up during voting. See Verifying a Flink Release "Checking License" section.