Spark リリースの準備

Spark におけるリリース マネージャーの役割は、いくつかの異なる責任を負うことを意味します。

セットアップの準備

新任のリリース マネージャーの場合は、以下の情報からプロセスを学ぶことができます。

GPG キーの準備

すでにキーをアップロードしている場合は、このセクションをスキップできます。

キーの生成

ここでは GPG 2.0.12 の例を示します。GPG バージョン 1 シリーズを使用している場合は、詳細について キーの生成 を参照してください。

$ gpg --full-gen-key
gpg (GnuPG) 2.0.12; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Robert Burrell Donkin
Email address: rdonkin@apache.org
Comment: CODE SIGNING KEY
You selected this USER-ID:
    "Robert Burrell Donkin (CODE SIGNING KEY) <rdonkin@apache.org>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 04B3B5C426A27D33 marked as ultimately trusted
gpg: revocation certificate stored as '/home/ubuntu/.gnupg/openpgp-revocs.d/08071B1E23C8A7E2CA1E891A04B3B5C426A27D33.rev'
public and secret key created and signed.

pub   rsa4096 2021-08-19 [SC]
      08071B1E23C8A7E2CA1E891A04B3B5C426A27D33
uid                      Jack (test) <Jack@mail.com>
sub   rsa4096 2021-08-19 [E]

公開キーの最後の 8 桁 (26A27D33) は キー ID であることに注意してください。

キーのアップロード

公開キーを生成した後、公開キーサーバー にアップロードする必要があります。

$ gpg --keyserver hkps://keys.openpgp.org --send-key 26A27D33

詳細については、キーサーバーのアップロード を参照してください。

コード署名キーで KEYS ファイルを更新する

コード署名キー (ASCII アーマード公開キーとしても知られる) を取得するには、次のコマンドを実行します。

$ gpg --export --armor 26A27D33

次に、生成されたキーを次のように KEYS ファイルに追加します。

# Move dev/ to release/ when the voting is completed. See Finalize the Release below
svn co --depth=files "https://dist.apache.org/repos/dist/dev/spark" svn-spark
# edit svn-spark/KEYS file
svn ci --username $ASF_USERNAME --password "$ASF_PASSWORD" -m"Update KEYS"

別のマシンでリリースを実行したい場合は、gpg --export-secret-keys および gpg --import コマンドを使用して、秘密キーをそのマシンに転送できます。

トップに戻る

Docker のインストール

リリース候補を作成するためのスクリプトは Docker を介して実行されます。これらのスクリプトを実行する前に Docker をインストールする必要があります。非 root ユーザーとして Docker を実行できることを確認してください。詳細については、https://docs.docker.com/install/linux/linux-postinstall を参照してください。

リリース候補の準備

リリース準備の主なステップは、リリース ブランチを作成することです。これは標準的な Git ブランチング メカニズムを介して行われ、ブランチが作成されたらコミュニティに通知する必要があります。

トップに戻る

リリース候補のカット

これが最初の RC でない場合は、前回の RC 以降に解決された JIRA の問題が Resolved とマークされ、このリリースバージョンに設定された Target Versions を持っていることを確認してください。

このリリースを対象とする保留中の PR に関する問題を追跡するには、次のようなクエリで JIRA にフィルターを作成します。project = SPARK AND "Target Version/s" = "12340470" AND status in (Open, Reopened, "In Progress")

ターゲット バージョンの文字列値を使用するには、そのターゲット バージョンに対応する数値値を、そのターゲット バージョンを対象とする既存の問題を調べ、[Target Versions] フィールドのバージョン (例: 2.2.1 を対象とする問題を見つけて、そのバージョン リンクをクリック) をクリックすることで見つけます。

git log から、それらが新しい RC に実際に入っているかどうかを確認します。release-notes ラベルが付いた JIRA の問題を確認し、破壊的変更の場合は関連する移行ガイド、または後で Web サイトのリリースニュースに文書化されていることを確認してください。

トップに戻る

自動化されたツールを使用したリリース候補の作成

リリース候補をカットするには、4 つのステップがあります。

  1. リリース候補の Git タグを作成する。
  2. リリース バイナリとソースをパッケージ化し、Apache ステージング SVN リポジトリにアップロードする。
  3. リリース ドキュメントを作成し、Apache ステージング SVN リポジトリにアップロードする。
  4. Apache ステージング Maven リポジトリにスナップショットを発行する。

リリース候補のカット プロセスは、dev/create-release/do-release-docker.sh スクリプトによって自動化されています。このスクリプトを実行し、必要な情報を入力して、完了するまで待ちます。また、-s オプションを使用して単一のステップを実行することもできます。do-release-docker.sh -h を実行して、詳細を確認してください。

トップに戻る

リリース候補の投票を呼びかける

リリース投票は Apache Spark 開発者リスト (PMC が投票) で行われます。過去の投票スレッドを見て、どのように進行するかを確認してください。メールは この形式 に従う必要があります。

  • JIRA の全 JIRA の短縮リンクを作成するには、https://s.apache.org/ を使用します。
  • 可能であれば、リリースノートのドラフトをメールに添付してください。
  • 投票終了時刻が UTC 形式であることを確認してください。これにはこのスクリプトを使用します。
  • メールがテキスト形式であり、リンクが正しいことを確認してください。

投票が完了したら、合計を示した要約メールも送信する必要があります。件名は次のようなものになります。[VOTE][RESULT] ...。

リリースの最終化

dev/create-release/do-release-docker.sh スクリプト (finalize ステップ) は、次のステップのほとんどを自動化しますが、次のもの以外は自動化しません。

  • Algolia Crawler の設定を更新する
  • ミラーネットワークから古いリリースを削除する
  • Spark ウェブサイトの残りの部分を更新する
  • Spark Docker イメージの作成とアップロード
  • アナウンスの作成

各ステップの結果は手動で確認してください。

トップに戻る

Apache リリース ディレクトリへのアップロード

注意!

このステップは元に戻せないので、正しいステージング リポジトリを選択したことを確認してください。アーティファクトをリリース フォルダに移動すると、削除できなくなります。

投票が通過した後、バイナリを Apache ミラーにアップロードするには、バイナリを dev ディレクトリ (投票された場所) から release ディレクトリに移動します。この「移動」は、実際のリリース ディレクトリに何かを追加できる唯一の方法です。(注: リリース ディレクトリに移動できるのは PMC のみです)

# Move the sub-directory in "dev" to the
# corresponding directory in "release"
$ export SVN_EDITOR=vim
$ svn mv https://dist.apache.org/repos/dist/dev/spark/v1.1.1-rc2-bin https://dist.apache.org/repos/dist/release/spark/spark-1.1.1

# If you've added your signing key to the KEYS file, also update the release copy.
svn co --depth=files "https://dist.apache.org/repos/dist/release/spark" svn-spark
curl "https://dist.apache.org/repos/dist/dev/spark/KEYS" > svn-spark/KEYS
(cd svn-spark && svn ci --username $ASF_USERNAME --password "$ASF_PASSWORD" -m"Update KEYS")

https://apache.dokyumento.jp/dist/spark/ にリソースが存在することを確認してください。表示されるまでに時間がかかる場合があります。これは Apache ネットワーク全体にミラーリングされます。https://checker.apache.org/projs/spark.html でリリースのリリースチェッカーの結果を確認してください。

Maven Central リポジトリについては、Apache Nexus Repository Manager からリリースできます。これは release-build.sh publish-release ステップによって既に設定されています。ログインし、[Staging Repositories] を開き、投票されたものを検索して (例: orgapachespark-1257 は https://repository.apache.org/content/repositories/orgapachespark-1257/)、選択して [Release] をクリックし、確認します。成功すると、https://repository.apache.org/content/repositories/releases/org/apache/spark/spark-core_2.11/2.2.1/ に表示され、https://repository.apache.org/content/groups/maven-staging-group/org/apache/spark/spark-core_2.11/2.2.1/ (正しいリリースバージョンを確認) にも同様に表示されます。しばらくすると、これは Maven Central に自動的に同期されます。

トップに戻る

PyPI へのアップロード

独自の PyPI アカウントが必要です。pyspark および pyspark-connect プロジェクトへのアクセス権を持つ PyPI アカウントを持っていない場合は、PMC に両方のアクセス許可を付与するように依頼してください。

アーティファクトは twine を使用してアップロードできます。次のように実行するだけです。

twine upload -u __token__  -p $PYPI_API_TOKEN \
    --repository-url https://upload.pypi.org/legacy/ \
    "pyspark-$PYSPARK_VERSION.tar.gz" \
    "pyspark-$PYSPARK_VERSION.tar.gz.asc"

新しいリリースに一致するファイルに合わせてコマンドを調整します。twine のアップロードが間違っている場合 (HTTP エラーやその他の問題など) は、アーティファクトを pyspark-version.post0.tar.gz に名前変更し、PyPI から古いアーティファクトを削除して再アップロードできます。

トップに戻る

リポジトリから RC アーティファクトを削除する

注意! 承認された RC のドキュメントのバックアップを作成しなかった場合、これはバックアップを作成できる最後の機会です。これは次のステップで Web サイトにアップロードするために使用されます。ディレクトリを削除する前に、SVN からドキュメントをチェックアウトしてください。

投票が通過し、承認された RC をリリース リポジトリに移動したら、ステージング リポジトリから RC ディレクトリを削除する必要があります。例:

RC=v3.5.2-rc3 && \
  svn rm https://dist.apache.org/repos/dist/dev/spark/"${RC}"-bin/ \
  https://dist.apache.org/repos/dist/dev/spark/"${RC}"-docs/ \
  -m"Removing RC artifacts."

Apache Nexus Repository Manager から、未発行のステージング リポジトリも削除することを忘れないでください。

トップに戻る

ミラーネットワークから古いリリースを削除する

Spark は常に各ブランチの最新のメンテナンスリリースをミラーネットワークに保持しています。古いバージョンを削除するには、単純に svn rm を使用します。

$ svn rm https://dist.apache.org/repos/dist/release/spark/spark-1.1.0

サイトで正しいリンクが生成されるように、js/download.js を更新して、リリースがもはやミラーリングされていないことを示す必要もあります。

トップに戻る

Spark Apache™ リポジトリを更新する

合格したリリース候補のタグ付けされたコミットをチェックアウトし、正しいバージョン タグを適用します。

$ git tag v1.1.1 v1.1.1-rc2 # the RC that passed
$ git push apache v1.1.1

トップに戻る

Algolia Crawler の設定を更新する

Spark ドキュメント Web サイトの検索ボックスは、Algolia Crawler を利用しています。リリース前に、Algolia Crawler Admin Console で Apache Spark のクローラー設定を新しいバージョンに更新してください。設定へのアクセス権がない場合は、Gengliang Wang または Xiao Li に連絡してください。

トップに戻る

Spark ウェブサイトを更新する

生成されたドキュメントをアップロードする

Web サイト リポジトリは https://github.com/apache/spark-website にあります。

最新の RC の生成されたドキュメントを削除しないことをお勧めします。これにより、spark-website に直接コピーできます。そうしないと、ドキュメントを再ビルドする必要があります。

# Build the latest docs
$ git checkout v1.1.1
$ cd docs
$ PRODUCTION=1 bundle exec jekyll build

# Copy the new documentation to Apache
$ git clone https://github.com/apache/spark-website
...
$ cp -R _site spark-website/site/docs/1.1.1

# Update the "latest" link
$ cd spark-website/site/docs
$ rm latest
$ ln -s 1.1.1 latest

Spark ウェブサイトの残りの部分を更新する

次に、Spark Web サイトの残りの部分を更新します。以前のリリースがどのように文書化されているかを確認してください (HTML ファイルの変更はすべて jekyll によって生成されます)。特に:

  • documentation.md を更新して、新しいリリースのドキュメントへのリンクを追加します。
  • js/downloads.js に新しいリリースを追加します (リリースの順序に注意してください)。
  • downloads.md を更新して、リンク例で最新リリースを使用します。
  • site/static/versions.json に新しいリリースを追加します (リリースの順序に注意してください) [PySpark ドキュメントの Spark バージョン ドロップダウン 用]
  • security.md を確認して、更新する必要があるものがないか確認します。
$ git add 1.1.1
$ git commit -m "Add docs for Spark 1.1.1"

次に、リリースノートを作成します。JIRA の リリース ページ に移動し、リストからリリース バージョンを選択して、「Release Notes」をクリックします。この URL をコピーし、s.apache.org で短縮 URL を作成します。Apache アカウントにログインし、ID を spark-2.1.2 のようなものに設定します。releases/_posts の下に新しいリリース投稿を作成して、この短縮 URL を含めます。投稿の日は、作成した日付に設定します。

次に bundle exec jekyll build を実行して site ディレクトリを更新します。

プル リクエストが大きくなることを考慮して、コード変更と生成された site ディレクトリのコミットを分離して、レビューを容易にしてください。

変更を asf-site ブランチにマージした後、ASF の git と Web サイト、および GitHub ミラーとの同期を強制するために、フォローアップの空のコミットを作成する必要がある場合があります。何らかの理由で、このリポジトリの同期は信頼性が低いようです。

関連する点として、JIRA でバージョンがリリース済みとしてマークされていることを確認してください。上記のようにリリース ページを見つけます (例: https://issues.apache.org/jira/projects/SPARK/versions/12340295)。右側にある「Release」ボタンをクリックして、リリース日を入力します。

(一般的に、これはメジャーおよびマイナー リリースにのみ適用され、パッチ リリースには適用されません) 貢献者リストは、このスクリプト を介して自動生成できます。現在のリリースに対応するタグと、前のリリース (メンテナンス リリースを除く) に対応する別のタグを受け取ります。たとえば、Spark 1.2.0 をリリースする場合、現在のタグを v1.2.0-rc2 に、前のタグを v1.1.0 に設定します。初期貢献者リストを生成したら、作者名が正しく翻訳されていないという警告が表示される可能性が非常に高いです。これを修正するには、GitHub と JIRA から潜在的な置換を取得する この別のスクリプト を実行します。たとえば:

$ cd dev/create-release
# Set RELEASE_TAG and PREVIOUS_RELEASE_TAG
$ export RELEASE_TAG=v1.1.1
$ export PREVIOUS_RELEASE_TAG=v1.1.0
# Generate initial contributors list, likely with warnings
$ ./generate-contributors.py
# Set GITHUB_OAUTH_KEY.
$ export GITHUB_OAUTH_KEY=blabla
# Set either JIRA_ACCESS_TOKEN (for 4.0.0 and later) or JIRA_USERNAME / JIRA_PASSWORD.
$ export JIRA_ACCESS_TOKEN=blabla
$ export JIRA_USERNAME=blabla
$ export JIRA_PASSWORD=blabla
# Translate names generated in the previous step, reading from known_translations if necessary
$ ./translate-contributors.py

さらに、より大きなパッチの開発者に対してより具体的なクレジットを付与したい場合は、次のコマンドを使用して大きなパッチを特定できます。Git はコミットが異なるブランチにバックポートされた場合にコミットを簡単に関連付けることができないため、前のリリースからのコミットがカウントされないように、細心の注意を払う必要があります。

# Determine PR numbers closed only in the new release
$ git log v1.1.1 | grep "Closes #" | cut -d " " -f 5,6 | grep Closes | sort > closed_1.1.1
$ git log v1.1.0 | grep "Closes #" | cut -d " " -f 5,6 | grep Closes | sort > closed_1.1.0
$ diff --new-line-format="" --unchanged-line-format="" closed_1.1.1 closed_1.1.0 > diff.txt

# Grep expression with all new patches
$ EXPR=$(cat diff.txt | awk '{ print "\\("$1" "$2" \\)"; }' | tr "\n" "|" | sed -e "s/|/\\\|/g" | sed "s/\\\|$//")

# Contributor list
$ git shortlog v1.1.1 --grep "$EXPR" > contrib.txt

# Large patch list (300+ lines)
$ git log v1.1.1 --grep "$expr" --shortstat --oneline | grep -B 1 -e "[3-9][0-9][0-9] insert" -e "[1-9][1-9][1-9][1-9] insert" | grep SPARK > large-patches.txt

トップに戻る

Spark Docker イメージの作成とアップロード

apache/spark-docker は、公開される Spark Docker イメージ用の Dockerfile と GitHub Action を提供しています。Docker イメージを作成してアップロードするには、指示 に従ってください。

トップに戻る

アナウンスの作成

すべてが機能したら (Web サイトのドキュメント、Web サイトの変更)、Web サイトにアナウンスを作成してから、メーリングリストに次のような件名のメールを送信します。[ANNOUNCE] ...。アナウンスを作成するには、news/_posts の下に投稿を作成してから bundle exec jekyll build を実行します。

お好みの大人向け飲料を楽しんで、Spark リリースを作成したことをお祝いください。

トップに戻る

最新ニュース

アーカイブ