Helix Swarmガイド (2020.1)

プロジェクトの追加

Swarmの[プロジェクト]ページで、[+ プロジェクトを追加]ボタンをクリックします。

注意
プロジェクトの追加権限は、管理者のみに制限もしくは特定のグループのメンバーのみに制限することができます。プロジェクトの追加権限が制限されている場合、管理者以外のユーザや、特定のグループに属しているユーザには、[+ プロジェクトを追加]ボタンは表示されません。

[プロジェクトを追加]ページが表示されます。
プロジェクトの名前を入力します。
任意: 説明を入力します。
任意: [所有者と管理者のみプロジェクトの編集を許可]チェックボックスを選択します。このチェックボックスを選択すると、新しい所有者を追加するためのフィールドが表示されます。このフィールドに文字を入力すると、その文字に一致するHelixサーバユーザが自動的に表示されます。

一度指定すると、プロジェクト定義の編集権限が、プロジェクトの所有者と管理者(Helixサーバで admin レベルまたは super レベルの権限を持つユーザ)のみに制限されます。

注意
所有者としてグループを指定することはできません。

ヒント
デフォルト設定の場合、特定のプロジェクトで[所有者と管理者のみプロジェクトの編集を許可]チェックボックスを選択すると、そのプロジェクトの所有者と管理者だけが、プロジェクトの[設定]ページを表示することができます。

Swarm管理者は、この動作を変更して、プロジェクトの所有者や管理者ではないプロジェクトメンバーが、そのプロジェクトの[設定]ページを読み取り専用として表示できるように設定することができます。詳細については、プロジェクトメンバーに対してプロジェクト設定の表示を許可するを参照してください。プロジェクトの[自動テスト]オプションと[自動展開]オプションの詳細情報は、プロジェクトの所有者と管理者を除き、プロジェクトメンバーには表示されません。そのため、プロジェクトメンバーは、プロジェクトの設定を確認することはできますが、変更することはできません。
少なくとも1人のチームメンバーを指定してください。このフィールドに文字を入力すると、Helixサーバ内でその文字に一致するプロジェクト、グループ、ユーザが自動的に表示されます(プロジェクト、グループ、ユーザの組み合わせで最大20件)。

重要
プロジェクトの作成時に、admin 権限を持っておらず、メンバーもしくは所有者として自分のアカウントを追加しなかった場合、後でこのプロジェクトの設定を編集することができません。

詳細については、「メンバーシップ」を参照してください。
デフォルトのレビュー担当者を設定します。
1. 任意: プロジェクトの[デフォルトのレビュー担当者]を指定します。
2. 任意: このプロジェクトに関連付けられているレレビューからデフォルトのレビュー担当者を削除できないようにする場合は、[デフォルトのレビュー担当者を保持]チェックボックスをクリックします。
任意: このプロジェクトをプライベートプロジェクトにする場合は、[プライベート]チェックボックスをクリックします。プライベートプロジェクトとそれに関連するレビューを表示できるのは、プロジェクトの所有者、モデレータ、メンバーと、Helixサーバで super 権限を持っているユーザのみです。

詳細情報については、「プライベートプロジェクト」を参照してください。
任意: このプロジェクトに関連付けられているレビューで必要な[最小賛成票]の値を設定します。

プロジェクト上で[最小賛成票]の値を設定した場合、ブランチ上で[最小賛成票]の値として1以上を設定しない限り、ブランチ上でプロジェクトの設定が使用されます。ブランチ上で1以上の値を設定した場合は、ブランチの設定が使用され、プロジェクトの設定は無視されます。

指定されている[最小賛成票]の要件が満たされた状態ですべての必須レビュー担当者がレビューに賛成票を入れない限り、レビューを承認することはできません。
- 複数のプロジェクトやブランチにまたがるレビューを承認するには、それらすべてのプロジェクトやブランチで[最小賛成票]の要件を満たす必要があります。
- 賛成票をカウントする場合は、必須レビュー担当者による投票が対象になります。
- プロジェクトやブランチに関連付けられているワークフローに対して[次の賛成票をカウント]ルールを[メンバー]に設定した場合、そのプロジェクトのメンバーによる賛成票のみが、プロジェクトやブランチの[最小賛成票]の値としてカウントされます。 [次の賛成票をカウント]ルールの詳細については、「ワークフロールール」を参照してください。
重要
対象となる[最小賛成票]の値が、レビューのレビュー担当者の数よりも大きい場合、そのレビューを承認することはできません。すべてのレビュー担当者がそのレビューに賛成票を入れた場合であっても、この条件は変わりません。
任意 (ワークフロー機能が無効になっている場合は表示されません): ワークフローをプロジェクトに関連付けます。

別のワークフローで置き換えることなく既存のワークフローを削除するには、[ワークフロー]ドロップダウンリストで[ワークフローがありません]を選択します。新しいプロジェクトを作成する場合は、これがデフォルトの動作になります。

ワークフローを関連付けるには、目的のワークフローを[ワークフロー]ドロップダウンリストで選択するか、検索フィールドにワークフローの名前を入力します。検索フィールドに文字を入力すると、その文字に一致する名前のワークフローが自動的に表示されます。ドロップダウンリストに表示されるのは、自分が所有しているワークフローと共有ワークフローだけです。
ヒント
- プロジェクトに関連付けられているワークフローは、そのプロジェクト内のすべてのブランチで使用されます。
- プロジェクトブランチにワークフローが関連付けられている場合、親プロジェクトのワークフローは無視され、ブランチのワークフローが使用されます。
ワークフローの詳細と、プロジェクトのワークフローとブランチのワークフローの関係については、「ワークフローの基礎」を参照してください。
任意: [+ ブランチを追加]をクリックして、ブランチのドロップダウンダイアログを表示します。
1. [名前]フィールドに、ブランチの短い名前を入力します。
2. 任意 (ワークフロー機能が無効になっている場合は表示されません): ワークフローをプロジェクトブランチに関連付けます。
  
  親プロジェクトのワークフローを使用するには、[ワークフロー]ドロップダウンリストで[プロジェクトから継承]を選択します。新しいブランチを作成する場合は、これがデフォルトの動作になります。親プロジェクトを[ワークフローがありません]に設定すると、グローバルワークフロールールがブランチで使用されます。
  
  ワークフローを関連付けるには、目的のワークフローを[ワークフロー]ドロップダウンリストで選択するか、検索フィールドにワークフローの名前を入力します。検索フィールドに文字を入力すると、その文字に一致する名前のワークフローが自動的に表示されます。ドロップダウンリストに表示されるのは、自分が所有しているワークフローと共有ワークフローだけです。
  ヒント
  - プロジェクトに関連付けられているワークフローは、そのプロジェクト内のすべてのブランチで使用されます。
  - プロジェクトブランチにワークフローが関連付けられている場合、親プロジェクトのワークフローは無視され、ブランチのワークフローが使用されます。
  ワークフローの詳細と、プロジェクトのワークフローとブランチのワークフローの関係については、「ワークフローの基礎」を参照してください。
3. ディポ構文を使用して、[パス]フィールドに1つ以上のブランチパスを入力します。複数のパスを入力する場合は、1行に1つずつパスを入力してください。
  ヒント
  - ブランチパスの先頭にマイナス記号(-)を指定すると、そのパスとそのパス上に存在するファイルを除外することができます。
  - リスト内の先頭のファイルパスから順に、ブランチパスが処理されます。
  以下に例を示します。
  
  //depot/main/swarm/...
  
  -//depot/main/swarm/test/...
  
  //depot/main/swarm/test/ResultSummary.html
  
  最初のパスには、プロジェクトブランチ内の//depot/main/swarm/ディレクトリに保管されているすべてのディレクトリとファイルが含まれます。
  
  2番目のパスでは、プロジェクトブランチ内の-//depot/main/swarm/test/ディレクトリに保管されているすべてのファイルが除外されます。
  
  3番目のパスには、2番目のパスで除外された//depot/main/swarm/test/ディレクトリ内のResultSummary.htmlファイルが含まれます。
  注意
  - ワイルドカードは使用できませんが、例外として、Helixサーバワイルドカードの「...」をブランチパスの末尾に指定することができます。
  - ブランチパスでは、大文字と小文字が区別されます。
  - ブランチを保存する場合、ブランチパスとそのパス上に存在するファイルが正しいかどうかについてはチェックされません。
    - ワイルドカードの「...」が末尾に指定された正しくないパスを入力した場合、そのパスが作成されるまで、プロジェクトファイルブラウザにそのパスは表示されません。そのため、まだ作成されていないパスを指定することができます。
    - まだコミットされていないファイルや存在しないファイルが末尾に指定されたパスを入力し、プロジェクトファイルブラウザを使用してそのパスに移動すると、Swarmによって404エラーが表示されます。
  注意
  最上位のビューで、Helixサーバの一部のコミットがプロジェクトの[コミット]タブに表示されない場合があります。各ブランチビューには、コミットが正しく表示されます。
  
  プロジェクトの[コミット]タブの最上位のクライアントビューは、プロジェクト内のすべてのブランチによって構成されています。
  
  例えば、「Alpha」というプロジェクトが以下のブランチによって構成されているとします。
  
  ブランチ: QA:
  
  //depot/alpha/dev/QA/...
  
  ブランチ: Dev:
  
  //depot/alpha/dev/...
  
  -//depot/alpha/dev/QA/...
  
  作成順にブランチを処理し、それらすべてのブランチで先頭のパスから順に処理することにより、プロジェクトの[コミット]タブのビューが生成されます。
  
  上記のAlphaプロジェクトの場合は、以下のような動作になります。
  
  最初のパスでは、//depot/alpha/dev/QA/内のすべてのディレクトリとファイルが、プロジェクトの[コミット]タブの最上位ビューに表示されます。
  
  2番目のパスでは、//depot/alpha/dev/内のすべてのディレクトリとファイルが、プロジェクトの[コミット]タブの最上位ビューに表示されます。
  
  3番目のパスでは、//depot/alpha/dev/QA/内のすべてのディレクトリとファイルが、プロジェクトの[コミット]タブの最上位ビューから除外されます。
  
  結果: QAブランチで表示されるはずの、//depot/alpha/dev/QA/に対するコミットが、プロジェクトの[コミット]タブの最上位ビューに表示されなくなります。
  
  ブランチが単純な構成になっている場合は、ブランチを作成する際に上記の例を考慮することにより、この問題を回避することができます。上記の例では、Devブランチを作成してからQAブランチを作成すると、//depot/alpha/dev/QA/ディレクトリがプロジェクトの[コミット]タブの最上位ビューから除外されることがないため、この問題を回避することができます。
4. 任意: プロジェクトブランチの[デフォルトのレビュー担当者]を指定します。
  
  このフィールドに文字を入力すると、Helixサーバ内でその文字に一致するユーザとグループが自動的に表示されます(ユーザとグループの組み合わせで最大20件)。デフォルトのレビュー担当者として追加するユーザまたはグループをクリックします。新しいレビューを作成するたびに、デフォルトのレビュー担当者がそのレビューに追加されます。
  - ユーザを追加する場合: ユーザIDの左側に表示されている星形のアイコンをクリックすると、そのユーザによる投票を必須にするかどうかを切り替えることができます。星型アイコンがオンになっている場合は、レビューを承認するためにはそのユーザによる投票が必須であることを意味しています。星形アイコンがオフになっている場合は、そのユーザによる投票が任意であることを表しています。
  - グループを追加する場合: グループIDの左側に表示されている星形のアイコンをクリックし、そのグループを、必須レビュー担当者(1票)、必須レビュー担当者(すべての票)、任意レビュー担当者のいずれにするかを選択します。星形アイコンがオンになっている場合は、レビューを承認するためにはすべてのグループメンバーが投票する必要があることを意味しています。星形アイコンがオンになっていて、アイコン内に「1」が表示されている場合は、レビューを承認するためには、1人以上のグループメンバーが賛成票を入れ、反対票を入れたメンバーがだれもいない状態になっている必要があることを意味しています。星形アイコンがオフになっている場合は、グループメンバーによる投票が任意であることを意味しています。
  デフォルトのレビュー担当者リストからデフォルトのレビュー担当者を削除するには、ユーザIDまたはグループIDの右側に表示されているXアイコンをクリックします。
  重要
  複数のプロジェクトまたは複数のプロジェクトブランチにレビューが含まれている場合は、以下の点に注意してください。
  - レビューが含まれているすべてのプロジェクトとプロジェクトブランチについて、デフォルトのレビュー担当者リストが結合され、そのレビューに追加されます。
  - レビューが含まれているプロジェクトとプロジェクトブランチで、それぞれ異なるレビュー担当者オプションがデフォルトのレビュー担当者に対して設定されている場合、最も制限の厳しいレビュー担当者オプションがそのレビューで使用されます。
  例: プロジェクトA、プロジェクトB、プロジェクトブランチbの一部であるレビューを作成したとします。
  
  プロジェクトA: デフォルトのレビュー担当者Xは、任意のレビュー担当者
  
  プロジェクトB: デフォルトのレビュー担当者Xは、任意のレビュー担当者
  
  プロジェクトブランチb: デフォルトのレビュー担当者Xは、必須レビュー担当者
  
  結果: デフォルトのレビュー担当者Xは、必須レビュー担当者としてレビューに追加されます。
  注意
  #reviewが含まれている新しいチェンジリストの説明内でユーザまたはグループが@mentionされた場合、そのユーザやグループは、レビュー担当者としてレビューに追加されます。これらのレビュー担当者のいずれかがすでにデフォルトのレビュー担当者として指定されている場合は、そのレビュー担当者がもう一度レビューに追加されることはありません。最も制限の厳しいレビュー担当者オプションが、レビューに対して使用されます。
  
  注意
  デフォルトのレビュー担当者をHelixサーバから削除した場合、そのレビュー担当者が新しいレビューに追加されることはありません。
5. 任意: このブランチに関連付けられているレレビューからデフォルトのレビュー担当者を削除できないようにする場合は、[このブランチに関連付けられているレビューの、デフォルトのレビュー担当者を保持]チェックボックスをクリックします。
6. 任意: このブランチに関連付けられているレビューで必要な[最小賛成票]の値を設定します。
  
  親プロジェクトの設定を継承するには、[最小賛成票]の値を未設定のままにします。新しいブランチを作成する場合は、これがデフォルトの動作になります。
  
  ブランチの設定を使用し、親プロジェクトの設定を無視する場合は、ブランチ上で[最小賛成票]の値を1以上に設定します。
  
  指定されている[最小賛成票]の要件が満たされた状態ですべての必須レビュー担当者がレビューに賛成票を入れない限り、レビューを承認することはできません。
  - 複数のプロジェクトやブランチにまたがるレビューを承認するには、それらすべてのプロジェクトやブランチで[最小賛成票]の要件を満たす必要があります。
  - 賛成票をカウントする場合は、必須レビュー担当者による投票が対象になります。
  - プロジェクトやブランチに関連付けられているワークフローに対して[次の賛成票をカウント]ルールを[メンバー]に設定した場合、そのプロジェクトのメンバーによる賛成票のみが、プロジェクトやブランチの[最小賛成票]の値としてカウントされます。 [次の賛成票をカウント]ルールの詳細については、「ワークフロールール」を参照してください。
  重要
  対象となる[最小賛成票]の値が、レビューのレビュー担当者の数よりも大きい場合、そのレビューを承認することはできません。すべてのレビュー担当者がそのレビューに賛成票を入れた場合であっても、この条件は変わりません。
7. 任意: [モデレータのみレビューの承認と却下を許可]チェックボックスを選択します。このチェックボックスを選択すると、新しいモデレータを追加するためのフィールドが表示されます。このフィールドに文字を入力すると、Helixサーバ内でその文字に一致するグループとユーザが自動的に表示されます。
  
  特定のグループをモデレータとして指定すると、そのグループに属しているすべてのメンバーに、対象となるプロジェクトブランチのモデレータ権限が付与されます。
  
  ブランチ仕様を入力してプロジェクトを保存すると、モデレータが設定されているブランチに関連するレビューの状態を変更する際に、以下の制限が適用されます。
  - モデレータのみレビューの承認と却下が許可されます。モデレータはまた、レビューを他の状態に移行することもできます。
  - モデレータではないレビューの作成者は、レビューの状態を、[レビューが必要]、[リビジョンが必要]、[アーカイブ済み]のいずれかに変更し、コミット済みのチェンジリストを添付することができます。
    
    通常、レビューの作成者は、モデレータが設定されているブランチ上で、レビューの状態を[承認済み]や[却下]に変更することはできません。ただし、モデレータでもある作成者はモデレータ権限を持ち、自分のレビューを承認または却下することができます。
    
    disable_self_approveが有効な場合、モデレータである作成者は自分のレビューを承認することはできません(admin権限を持つユーザであっても承認することはできません)。
  - プロジェクトメンバーは、レビューの状態を[レビューが必要]または[リビジョンが必要]に変更し、コミット済みのチェンジリストを添付することができます。プロジェクトメンバーは、レビューの状態を、[承認済み]、[却下]、[アーカイブ済み]に変更することはできません。
  - プロジェクトのメンバー、モデレータ、またはレビューの作成者であるユーザは、レビューの状態を移行することはできません。
  - レビューの作成者またはプロジェクトメンバーは、自分に対して許可されている状態になっていないレビュー([却下]状態のレビューなど)を、別の状態に移行することはできません。
  これらの制約は、レビューを開始する人には影響しません。
8. [完了]ボタンをクリックして、ブランチ仕様の内容を確定します。
モデレータが設定されているブランチを定義すると、そのブランチに設定されているモデレータの数がブランチリストに表示されます。

ヒント
ブランチの[Xモデレータ]テキストにカーソルを置くと、そのブランチのモデレータが表示されます。
任意: ジョブフィルタを指定します。ジョブフィルタを使用すると、ジョブとプロジェクトの関連付けに使用される条件を指定することができます。例えば「Subsystem=ProjectA」と入力すると、[サブシステム]フィールドがProjectAに設定されているジョブが現在のプロジェクトに関連付けられます。

注意
このジョブフィルタは、他のHelixサーバクライアントで使用できるフィルタよりも単純なフィルタです。フィルタはfield=valueのペアで記述する必要があり、キーワードのみを使用することはできません。ワイルドカード検索用のアスタリスクは使用できますが、その他のフィルタ式構文は使用できません。
プロジェクトメンバーとモデレータは、新しいレビューの開始時にデフォルトで通知を受け取ります。プロジェクトメンバー、モデレータ、フォロワーは、変更がコミットされたときに通知を受け取ります。

以下に示す操作のうち、どちらの操作が実行されたときに通知を送信するかを選択します。
- 新しいレビューが要求されたときに、メンバーとモデレータに電子メールを送信: プロジェクトに対して新しいレビューが要求された場合に、そのプロジェクトのすべてのメンバーとモデレータが、電子メール通知リストに追加されます。
- 変更がコミットされたときに、メンバー、モデレータ、フォロワーに電子メールを送信: プロジェクトに対して変更がコミットされた場合に、そのプロジェクトのすべてのメンバー、モデレータ、フォロワーが、電子メール通知リストに追加されます。
注意
- 特定のグループがプロジェクトのメンバーまたはモデレータである場合、個々のプロジェクトメンバーやモデレータの場合と同じロジックを使用して、そのグループに属しているすべてのメンバーに通知が送信されます。
- @mentionを指定したユーザとグループや、レビューまたはチェンジリストに明示的に追加されたユーザとグループの場合、新しいレビューまたはコミットされたレビューの通知機能が無効になっている場合であっても、通知が送信されます。
任意: [自動テスト]の横にある[有効]チェックボックスをクリックして、自動テストの設定フィールドを表示します。

テストの実行をトリガするURLを指定します。ダイアログで説明されているように、特別な引数を使用することで重要な詳細をテストスイートに知らせるURLを作成できます。詳細については、テストスイートを統合してレビューの承認または却下を通知するを参照してください。
任意: [自動展開]の横にある[有効]チェックボックスをクリックして、自動展開の設定フィールドを表示します。

プロジェクトコードの展開をトリガするURLを指定します。ダイアログで説明されているように、特別な引数を使用することで重要な詳細を展開プログラムに知らせるURLを作成できます。詳細については、レビュー内で自動的にコードを展開するを参照してください。
[保存]をクリックします。

注意
いずれかの必須フィールドに値が入力されていない場合は、[保存]ボタンが無効になります。

重要
自分が編集できないプロジェクトを作成することもできます。自分ではないユーザを所有者として指定し、自らをメンバーとしても指定しなかった場合にこのような状態になります。 Swarmは、ユーザがプロジェクトを保存する際に、こうした状態を検出することができます(ただし、すべてを検出できるわけではありません)。こうした状態が検出された場合は、警告ダイログが表示されます。

このダイアログが表示された場合に[続行]をクリックすると、自分の所有権とメンバーシップを除いてプロジェクトが保存されます。プロジェクトの編集を続行する場合は、[キャンセル]をクリックします。このダイアログが表示されている間は、プロジェクトページの[保存]ボタンと[キャンセル]ボタンが無効になります。
これで、このプロジェクト内のレビューに対して、Swarmのワークフローを使用することができます。

の検索では、個の結果が出ました。