グローバルワークフロールール

このセクションでは、ワークフローを有効にする方法と、Swarmに対してグローバルなワークフロールールを設定する方法について説明します。

ヒント

構成情報を変更しても、構成キャッシュを再ロードしない限り、その構成情報がSwarmで使用されることはありません。構成キャッシュを再ロードすると、変更した構成情報がSwarmで強制的に使用されます。Swarm構成キャッシュを再ロードするには、admin ユーザまたはsuper ユーザでなくてはなりません。[ユーザID]ドロップダウンメニューに移動して[システム情報]を選択し、[キャッシュ情報]タブをクリックしてから[構成の再ロード]ボタンボタンをクリックします。

ワークフローの前提条件

Swarm 2019.2以降では、ワークフロー機能がデフォルトで有効になっています。

ヒント

以前のバージョンのSwarmをアップグレードする場合は、トリガを更新する必要があります。詳細については、「Swarmのアップグレード」を参照してください。

ワークフロー機能を使用するための前提条件を以下に示します。

ワークフロー

Swarm 2019.2以降、ワークフローはデフォルトで有効になっています。

ワークフロー機能を無効にするには、SWARM_ROOT/data/config.phpファイルを編集用として開き、以下に示すコードブロック内のworkflowセクションで、enabled構成可能変数の値をfalseに設定します。

    'workflow' => array(
        'enabled' => false, // Switches the workflow feature on. Default is true
    ),			

デフォルト値はtrueです。

ヒント

Swarmconfig.phpファイルでワークフロー機能を無効にした場合、ワークフローがSwarmで処理されなくなりますが、Helixサーバがワークフロートリガスクリプトを実行するたびに、わずかなオーバーヘッドが発生します。次のワークフロートリガ行をコメント化すると、このオーバーヘッドをなくすことができます: swarm.enforce change-submitswarm.strict change-contentswarm.shelvesub shelve-submit

グローバルワークフロー

注意
  • [グローバルワークフロー]ページを編集できるのは、super 権限またはadmin 権限を持っているSwarmユーザと、グローバルワークフローを所有しているユーザだけです。
  • 古いバージョンのSwarmでは、Swarmconfig.phpファイルでグローバルワークフローのルールを設定していました。Swarm 2020.1以降、Swarm[ワークフロー]ページでグローバルワークフローのルールを設定するようになりました。旧バージョンのSwarmをアップグレードすると、グローバルワークフローの設定が、グローバルワークフローというワークフローに自動的に移行されます。
  • 旧バージョンのSwarmでは、Swarmconfig.phpファイルでグローバルテストの設定を行っていました。Swarm 2020.1からは、Swarm[ワークフロー]ページでグローバルワークフローにテストを追加するようになりました。グローバルワークフローに追加されたテストは、グローバルテストとして機能します。旧バージョンのSwarmをアップグレードすると、グローバルテストが自動的に移行されます。各グローバルテストは、次のように移行されます: テストの所有者がSwarmのadminユーザとして設定され(共有はされない)、テスト名が元のテスト名に戻り、テストの説明が元のテストタイトルとして設定され、最後にグローバルワークフローに追加されます。

グローバルワークフロールールにより、必要に応じてルールをグローバルに適用できるため、すべてのプロジェクトで、基本的な社内ポリシーに従うことができます。グローバルワークフローの各ルールは、[強制的にオフ] (これがデフォルト)または[強制的にオン]を使用して設定することができます。これにより、そのルールがSwarmで使用されるかどうかが決まります。

  • 強制的にオフ: これを選択すると、ワークフロールールの設定が、ワークフローに関連付けられていないプロジェクトとプロジェクトブランチに適用されます。プロジェクトまたはプロジェクトブランチにSwarmのワークフローが関連付けられている場合は、グローバルルールが無視されます。
  • 強制的にオン: これを選択すると、最小限のワークフロールール設定が、すべてのプロジェクトとプロジェクトブランチに適用されます。プロジェクトまたはプロジェクトブランチにワークフローが関連付けられている場合、グローバルルールがワークフロールールにマージされ、最も制限の厳しい設定が使用されます。

グローバルワークフロールールを編集するには、以下の手順を実行します

  1. Swarm[ワークフロー]ページに移動します。
  2. [グローバルワークフロー]をクリックして設定ページを開きます。
  3. ヒント

    デフォルト設定の場合、グローバルワークフローの名前は「グローバルワークフロー」として表示されますが、これは変更することができます。簡単に区別できるように、グローバルワークフローは必ずワークフローリストの先頭に表示され、他のワークフローとは違う背景色で表示されます。

    グローバルワークフロー設定の画像

  4. 任意: 必要に応じて名前を変更します。ただし、簡単に区別できるように、「グローバルワークフロー」のままにすることをお勧めします。
  5. 任意: 必要に応じて、グローバルワークフローの説明を入力します。
  6. 任意: 必要に応じて、自分以外の所有者を追加します。このフィールドに文字を入力すると、Helixサーバ内でその文字に一致するグループやユーザが自動的に表示されます(グループとユーザの組み合わせで最大20件)。

    重要
    • グローバルワークフローには、1人以上の所有者が必要です。
    • 所有者である自分自身をワークフローから削除すると、super ユーザ権限を持っていない限り、このワークフローの設定を編集できなくなります。
  7. グローバルルール:

    グローバルワークフローの各ルールは、ルールの横にある[強制]スライダで[強制的にオフ] (これがデフォルト)または[強制的にオン]を使用して設定することができます。これにより、そのルールがSwarmで使用されるかどうかが決まります。

    • 強制的にオフ: これを選択すると、ワークフロールールの設定が、ワークフローに関連付けられていないプロジェクトとプロジェクトブランチに適用されます。プロジェクトまたはプロジェクトブランチにSwarmのワークフローが関連付けられている場合は、グローバルルールが無視されます。
    • 強制的にオン: これを選択すると、最小限のワークフロールール設定が、すべてのプロジェクトとプロジェクトブランチに適用されます。プロジェクトまたはプロジェクトブランチにワークフローが関連付けられている場合、グローバルルールがワークフロールールにマージされ、最も制限の厳しい設定が使用されます。
    重要
    • [強制的にオフ]を使用して設定されたグローバルワークフロールールを変更すると、ワークフローが関連付けられていないプロジェクトとプロジェクトブランチでワークフローが変更されます。
    • [強制的にオン]を使用して設定されたグローバルワークフロールールを変更すると、すべてのプロジェクトとプロジェクトブランチでワークフローが変更されます。

    レビューなしのコミット時:

    このルールは、レビューが関連付けられていないチェンジリストがSwarmの外部でサブミットされた場合に適用されます。

    以下に示すいずれかのオプションを選択します。

    • 許可: チェンジリストのチェック処理は実行されず、レビューがない状態でチェンジリストがサブミットされます。
    • レビューを作成: チェンジリストがサブミットされ、そのチェンジリストに対して自動的にレビューが作成されます。
    • 却下: チェンジリストのサブミットが却下されます。
    • ヒント

      チェンジリストの説明内で#reviewキーワードを指定してチェンジリストをサブミットした場合も、選択したルールが適用されます。

    レビューありのコミット時: このルールは、以下の場合に適用されます。

    • Swarmレビューがコミットされた場合。
    • レビューが関連付けられているチェンジリストがSwarmの外部でサブミットされた場合。

    以下に示すいずれかのオプションを選択します。

    • 許可: チェンジリストのレビュー状態はチェックされません。関連付けられているレビューが承認されていない場合であっても、チェンジリストがコミットされます。
    • 承認済みでない場合は却下: 関連するレビューが承認済みで、チェンジリストの内容がそのレビューの内容と一致している場合にのみ、チェンジリストがサブミットされます。
    • ヒント

      #review-nnnnn#replace-nnnnn#append-nnnnnのうち、いずれかのキーワードをチェンジリストの説明内で指定してそのチェンジリストをサブミットした場合も、選択したルールが適用されます(「nnnnn」はレビューID)。

    終了状態のレビューの更新時:

    特定の状態になっているレビューの内容を自動的に変更されないように保護する場合は、このルールを使用します。デフォルトの場合、[アーカイブ済み][却下][承認:コミット]の状態になっているレビューが保護されます。保護対象となるレビューの状態は、Swarmの管理者が設定します。

    ヒント

    レビューが保護されている場合であっても、Swarm UIでそのレビューを手動で更新することができます。

    チェンジリストをレビューに追加すると、このルールが適用されます。

    以下に示すいずれかのオプションを選択します。

    • 許可: レビューはチェックされません。レビューの状態に関係なく、チェンジリストがレビューに追加されます。これが、デフォルトの設定です。
    • 却下: レビューの状態が、end_state構成可能変数で指定されたいずれかの状態に一致する場合、以下のような動作になります。
      • レビューの[変更を追加]ボタンが無効になります。
      • チェンジリストの説明内で、#review-nnnnn#replace-nnnnn、または#append-nnnnnを指定し(「nnnnn」はレビューID)、Swarmの外部でそのチェンジリストを追加すると、そのチェンジリストが却下されます。

    次の賛成票をカウント:

    デフォルトでは、レビューに対するすべての賛成票が、そのレビューに関連するプロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。カウントする賛成票を、レビューが関連付けられているプロジェクトのメンバーだけに制限する場合は、このルールを使用します。

    特定のユーザがレビューに賛成票を入れた場合に、このルールが適用されます。

    以下に示すいずれかのオプションを選択します。

    • すべてのユーザ: レビュー内で設定されているすべてのレビュー担当者による投票がカウントされます。これが、デフォルトの設定です。
    • Members: レビューが関連付けられているプロジェクトのメンバーが投票した賛成票だけが、プロジェクトまたはブランチで設定されている[最小賛成票]の値としてカウントされます。
    ヒント

    プロジェクトやブランチで[最小賛成票]の値を設定する方法については、「プロジェクトの最小賛成票」と「ブランチの最小賛成票」を参照してください。

    自動的にレビューを承認:

    デフォルトでは、手動でレビューを承認する必要があります。レビューを自動的に承認する場合は、このルールを使用します。

    ユーザがレビューに対して投票した場合、必須レビュー担当者がレビューに追加された場合、必須レビュー担当者が任意レビュー担当者になった場合に、このルールが適用されます。

    以下に示すいずれかのオプションを選択します。

    • しない: レビューが自動的に承認されることはありません。これが、デフォルトの設定です。
    • 投票数ベース: 以下の場合に、レビューが自動的に承認されます。
      • レビューに対する反対票がない場合。
      • レビューのモデレータが設定されていない場合。モデレータが設定されているレビューを自動的に承認することはできません。
      • すべての必須レビュー担当者が、レビューに対して賛成票を入れた場合。
      • レビューで設定されている[最小賛成票]の値が、そのレビューに関連するすべてのプロジェクトとブランチの要件を満たしている場合。
      • 承認をブロックするように設定されているすべてのテストがパスした場合。
      重要

      モデレータが設定されているレビューを自動的に承認することはできません。モデレータの詳細については、「モデレータ」を参照してください。

      ヒント

      自動的に承認されたレビューは、手動でコミットする必要があります。

  8. すべてのワークフロールールを無視できるメンバーまたはグループ

    任意: ディポ全体にわたってすべてのワークフロールールを無視する場合は、すべてのワークフロールールを無視できるユーザとグループ(サブグループを含む)をこのフィールドに追加します。このフィールドに文字を入力すると、Helixサーバ内でその文字に一致するユーザとグループが自動的に表示されます(ユーザとグループの組み合わせで最大20件)。

    通常、この権限は、信頼できる少数のユーザとグループに対して付与します(プロジェクトの所有者や管理者など)。

    ヒント

    この設定は、Swarmの UI、P4Dコマンドライン、P4Dクライアント、Swarm APIで実行される操作に適用されます。

  9. [テスト]
  10. 任意: ワークフローにテストを追加します。テストは、ワークフローに関連付けられたレビューの作成時、更新時、または送信時に実行されます。テストの[日時]ドロップダウンから選択されます。

    ヒント
    • テストは、[保存]ボタンをクリックしたときにのみワークフローに保存されます。
    • レビューが複数のワークフローに関連付けられている場合、それらすべてのワークフローのすべてのテストがレビュー用に実行されます。同じテストが複数の関連付けられたワークフローで行われる場合、そのテストは1回だけ実行されます。

    テストを追加するには: 

    1. テスト領域で、[+タスクの追加]リンクの画像をクリックします。
    2. [テスト]ドロップダウンリストから実行するテストを選択します。
    3. テストを実行する日時を[日時]ドロップダウンリストから選択します。

      ヒント
      • レビューコンテンツの変更とは、レビュー内のファイルまたはファイルのコンテンツが変更されたときを指します。レビューの説明を変更しても、テストはトリガされません。

      • オンデマンドテストは、レビュー内容の変更チェックによる影響を受けることはありません。

      • [更新時]では、テストは次の場合に実行されます。
        • レビューが作成された場合。
        • レビューが送信され、レビューコンテンツが以前のレビューリビジョンと比較して変更された場合。

        • レビューが更新され、以前のレビューリビジョン以降にレビューコンテンツが変更された場合。
      • ヒント

        最後にテストにパスしてからレビューの内容が変更されていない場合、レビューのバージョン作成時や送信時にテストが再実行されることはありません。テストがまだ実行中の場合や、Swarmが「パス」状態で更新されていない場合は、送信時にもテストが再実行されます。

      • [送信時]では、プリコミットレビューが送信された場合、またはポストコミットレビューが作成された場合に、テストが実行されます。
      • [オンデマンド]の場合、テストが自動的に実行されることはありませんが、レビューページの[テストステータス]ドロップダウンで手動でテストを実行することができます。
    4. テストが失敗した場合にSwarmで承認をブロックするかどうかを、[ブロック]ドロップダウンリストで選択します。
      • [なし]を選択すると、テストが失敗しても承認はブロックされません。
      • [承認]を選択すると、テストが失敗した場合にレビューの承認がブロックされます。
    5. [承認] [承認]ボタンの画像ボタンをクリックして、テストをワークフローに追加します。

    ワークフローでテストを編集するには:

    1. 編集するテストの横にある[編集] [編集]ボタンの画像ボタンをクリックします。
    2. [テスト][日時][ブロック]ドロップダウンリストが表示されます。
    3. 必要に応じて変更します。
    4. [承認] [承認]ボタンの画像ボタンをクリックして、変更内容を確認します。

    ワークフローからテストを削除するには:

      ワークフローから削除するテストの横にある[削除] [削除]ボタンの画像ボタンをクリックします。

      テストはすぐに削除されます。確認は要求されません。テストの削除を完了するには、ワークフローを保存する必要があります。

  11. [保存]をクリックします。

    注意

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