手動リリース投稿キックオフ

リリース投稿ブランチと必要なディレクトリ / ファイルを手動で作成する

自動化されたパイプラインが失敗した場合、以下の手動手順はローカルまたは GitLab Web IDE を使用して実行できます:

1. gitlab.com/gitlab-com/www-gitlab-com で master から新しいブランチ release-X-Y を作成します。
2. release-X-Y ブランチで、はじめにとブログ投稿のフロントマター情報を含むブログ投稿ファイルを作成します:
   1. sites/uncategorized/source/releases/posts/ ディレクトリに、月次リリースブログテンプレートをコピーして YYYY-MM-22-gitlab-X-Y-released.html.md という名前の新しいファイルを追加します。
   2. sites/uncategorized/source/releases/posts/YYYY-MM-22-gitlab-X-Y-release.html.md の 36 行目にリリース番号を追加し、バックティックを削除してください。
   3. sites/uncategorized/source/releases/posts/YYYY-MM-22-gitlab-X-Y-release.html.md の 3 行目と 4 行目に著者として自分の名前を追加します。
   4. sites/uncategorized/source/releases/posts/YYYY-MM-22-gitlab-X-Y-release.html.md の 41 行目にある「これには YY リリースキックオフビデオが含まれています」という行を更新し、YY（バックティックを削除することも含めて）を次のリリースに言及するよう変更します。
3. release-X-Y ブランチで、機能やその他のデータが追加されるリリース投稿データディレクトリを作成します:
   1. data/release_posts ディレクトリに新しいディレクトリ X_Y を作成します。
   2. data/release_posts/unreleased/samples/mvp.yml を data/release_posts/X_Y/mvp.yml にコピーします。

リリース投稿 MR の作成

前回の投稿がマージされた後、フィーチャーフリーズ日前に、チームからのコントリビューションを受け取れるようにする導入変更とともにマージリクエストを作成します:

1. ソースブランチは release-X-Y、ターゲットブランチは master でなければなりません。

2. タイトルを Draft: Release post - GitLab X.Y に設定します。タイトルの先頭に Draft: を付けてください。

3. 「マージリクエストが承認されたらソースブランチを削除する」が選択されていることを確認してください。

4. MR にリリース投稿テンプレートを使用してください。

   

リリース投稿 MR を作成したら、MR のチェックリストを参照して、取るべき各アクションとその期日を確認してください。使い勝手の改善、バグ、パフォーマンス改善の MR には独自のチェックリストがあり、リリース投稿マネージャーがこれらの MR を最終コンテンツアセンブリの前の 17 日までにマージするタスクが含まれていることに注意してください。

レトロスペクティブ Issue の作成

1. リリース投稿レトロスペクティブテンプレートを使用してリリース投稿レトロスペクティブ Issue を作成し、タイトルとして Release Post X.Y Retrospective を使用します。
2. Issue に適切なマイルストーンを追加します。
3. 自分を Issue に割り当てます。

注: リリース投稿 MR とすべての関連ファイルを作成したら、MR のチェックリストを参照して取るべき各アクションとその期日を確認してください。使い勝手の改善、バグ、パフォーマンス改善の MR には独自のチェックリストがあり、リリース投稿マネージャーがこれらの MR を最終コンテンツアセンブリの前の 17 日までにマージするタスクが含まれていることに注意してください。

コンテンツアセンブリ: リリース投稿アイテム（コンテンツブロック）をブランチにマージする

リリース投稿をアセンブルする時が来たら、コンテンツブロックファイルを data/release_posts/unreleased から data/release_posts/X_Y に移動し、画像を source/images/unreleased から source/images/X_Y に移動します。

これらのブロックアイテムは、各 PM が各機能のために作成したリリース投稿アイテムで構成されています。

bin/release-post-assemble スクリプトを使用するとこれが簡単にできます:

  git checkout master
  git pull
  git checkout release-X-Y
  git pull
  git merge master
  bin/release-post-assemble
  git status
  # コンテンツブロックと画像が `unreleased` から `X_Y` に移動されたことを確認
  git add .
  git commit -m "Content assembly"
  git push origin release-x-y

コンテンツアセンブリボットが失敗した場合

何らかの理由でコンテンツアセンブリボットが失敗した場合、最も簡単な対処法はファイルを手動で移動することです。変更のウォークスルー動画もこちらにあります。

1. /data/releases_posts/unreleased/ から /data/release_posts/x_y/ に（x_y はリリース投稿ディレクトリ例: 13_2）すべての .yml ファイルを手動で移動します。| 注: /samples ディレクトリは同じ場所に残してください。移動しないでください。
2. /source/images/unreleased/ から /source/images/x_y/ にすべての画像を手動で移動します。
3. VS Code などのテキストエディタを使用して、各リリース投稿 .yml ファイルの image_url: の下にある画像パスをすべて /unreleased/ から /x_y/ に検索・置換します。上の動画でこれをデモンストレーションしています。
4. git commit と git push を実行すれば完了です。

リリース投稿アセンブリ

リリース投稿アセンブリスクリプトは、リリース投稿のコンテンツブロックとその画像を現在のリリースディレクトリに移動します。

シンプルな正規表現を使用してコンテンツファイルと画像を見つけます。バリデーションは行いません。将来的には、維持するスクリプトの数を減らすためにリンターの機能と組み合わせることが簡単にできるでしょう。

18 日のコンテンツアセンブリに備えて、リリース投稿マネージャーはローカル開発環境が最新であることを確認してください（例: 最新バージョンの Ruby を実行していること）。事前にローカル開発環境を準備するためのステップについては、リリース投稿 MR チェックリストの「コンテンツアセンブリと初期レビュー」セクションに従ってください。

スクリプトのエラーと是正措置の例

development.md には、ローカル開発環境をセットアップする手順が含まれています。

何をすべきかが明確でない場合に遭遇する可能性のある一般的なエラーをいくつか示します。

必要な Ruby Gem がありません

このようなあいまいなエラーが発生する可能性があります:

Traceback (most recent call last):
  6: from ./bin/release-post-item:5:in `<main>'
  5: from ./bin/release-post-item:5:in `require_relative'
  4: from /Users/chase/work/www-gitlab-com/lib/release_posts.rb:13:in `<top (required)>'
  3: from /Users/chase/work/www-gitlab-com/lib/release_posts.rb:13:in `require_relative'
  2: from /Users/chase/work/www-gitlab-com/lib/release_posts/post_entry.rb:6:in `<top (required)>'
  1: from /Users/chase/.asdf/installs/ruby/2.6.6/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:117:in `require'
/Users/chase/.asdf/installs/ruby/2.6.6/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:117:in `require': cannot load such file -- styled_yaml (LoadError)

この場合、Ruby は styled_yaml という名前のファイルをロードしようとしています。これが gem（自己完結した Ruby ライブラリ）であることは明確ではありませんが、出力の require ステートメントが未解決の依存関係があることを示しています。この場合に取るべきアクションは bundle install を実行することです。 ./bin/doctor を実行することもでき、何をすべきかガイダンスを提供するはずです。ここに不安を感じる場合や困難に遭遇した場合は、アドバイスを求めてリリース投稿 DRI に連絡してください。

Ruby のバージョンの不一致

Ruby バージョンマネージャーがインストールされている場合、ruby 3.0.0 Not installed. Run "asdf install ruby 3.0.0" のようなエラーがターミナルに表示されることがあります。

ハンドブックスクリプトを実行するために必要なものと比較して、Ruby バージョンが古い可能性があります。./bin/doctor を実行して、現在の Ruby バージョンと .tool-versions ファイルのバージョンを比較できます。

取るべきアクションは、必要な Ruby バージョンをインストールすることです

最も一般的な Ruby バージョンマネージャーで Ruby をインストールするには、以下を試してください:

• asdf の場合: asdf install ruby 3.0.0 を実行
• rbenv の場合: brew upgrade rbenv ruby-build && rbenv install 3.0.0 を実行
• rvm の場合: rvm install 3.0.0 を実行

ここに不安を感じる場合や困難に遭遇した場合は、アドバイスを求めてリリース投稿 DRI に連絡してください。

ハンドブックは現在rvm を推奨していますが、エンジニアリングは asdf を採用しています。このドキュメントに rbenv への参照も見つかるかもしれません。どれでも問題ありませんが、それぞれ少し動作が異なり、Ruby バージョンマネージャーは一つだけ必要です。

macOS のアップグレード、特に以前のバージョンから Catalina 以降へのアップグレードによって、Ruby バージョンマネージャーの設定が誤っているか変更されている可能性もあります。このシナリオに対する具体的なアクションを提案することは難しいため、アドバイスを求めてリリース投稿 DRI に連絡することをお勧めします。

Gem は正しくインストールされるが、それでも gem が見つからないエラーが発生する

Ruby gem パッケージマネージャーは bundler と呼ばれます。インストールされている bundler のバージョンによっては、--path that_other_directory を渡すことで gem を通常（および必要な）場所とは異なる場所にインストールするように bundler を設定できます。これらの設定は ./.bundle/config または ./bundle/config に保存されます。

./bundle/config ファイルを確認すると次のように表示されることがあります:

BUNDLE_PATH: "that_other_directory"

この場合に取るべきアクションは、そのファイル ./bundle/config と場合によっては ./bundle/config を編集して BUNDLE_PATH 設定を削除し、bundle install を再実行することです。 多くの場合 vendor である that_other_directory も削除したい場合があります。ここに不安を感じる場合や困難に遭遇した場合は、アドバイスを求めてリリース投稿 DRI に連絡してください。

ロックサポート

ローカルコミットをオリジンにプッシュする際に、ロックサポートに関してこのようなメッセージが表示されることがあります:

Locking support detected on remote "origin". Consider enabling it with:
  $ git config lfs.https://work-gitlab/gitlab-com/www-gitlab-com.git/info/lfs.locksverify true

この提案は安全に無視できます。Git LFS ファイルロックの詳細ドキュメントを参照してください。

JAMF と git-lfs の競合

コミットを gitlab.com にプッシュしようとする過程で、git が gitlab.com の SSL 証明書を確認しようとしています。JAMF がインストールされている場合（コンプライアンス上インストールされているはずです）、git が gitlab.com に対して異なる証明書を見つけ、Post "https://gitlab.com/gitlab-com/www-gitlab-com.git/info/lfs/locks/verify": x509: certificate signed by unknown authority error: failed to push some refs to 'gitlab.com:gitlab-com/www-gitlab-com.git' というエラーが発生することがあります。

この場合に取るべきアクションは IT に連絡することです

詳細については、この Issue を参照してください。

ページのソースコードを見る - ページの編集 - please contribute.