ワークフロー トリガーについて

以下のトピックでは、トリガーの仕組みについての詳細を説明しているため、これらをより効率的に使用することができます。

トリガー イベント

イベント（例：コミット作成）は特定の開発ツールを Jira に統合することでトリガーに使用することができるようになります。以下の表では、各開発ツールで有効になるイベントを一覧表示しています。

トリガーとグローバル トランジション

トリガーによる課題の動作への影響を正確に理解している場合を除き、グローバル トランジションにはトリガーを設定しないことをお勧めします。

グローバル トランジションによって、ワークフローの任意のステータスを特定のステータスに遷移できます。これはワークフロー ビューアー/エディターで、グローバル トランジションの遷移先となるステータスを指す黒の「すべて」バッチで表されます。詳細なワークフロー設定の詳細についてご確認ください。

グローバル トランジションにトリガーを設定すると、グローバル トランジションの対象のステータスに予期せず遷移するという問題がよく発生するようになります。例えば、「進行中」ステータスに遷移するグローバル トランジションに「コミットの作成」トリガーを設定する場合を考えます。多くの段階で、課題のライフサイクル（例：初期コード作成、レビュー後のコード変更など）中にコードをコミットすることがあります。これにより、「レビュー中」や「完了」などのステータスから「進行中」に不正に遷移するという問題を引き起こす可能性があります。

コミット、ブランチ、プル リクエスト、レビューで Jira 課題を参照する

以下の表では、コミット、ブランチ、プル リクエスト、レビューで Jira 課題を、これらのイベントが課題への遷移を開始するように、照する方法を説明しています（トランジションにトリガーをセットアップする方法を提供しています）。

開発ツールから Jira へユーザをマッピングする

以下のプロセスでは、開発ツールのユーザをワークフロー トリガー用に、Jira ユーザにマッピングする方法を説明しています。これはすべてのイベントに適用されますが、各開発ツールではマッピングに異なるメール アドレスとユーザ名を使用します（以下のプロセスの説明に続く箇条書きを参照してください）。

• プロセス： 開発ツールのイベントを初期化するユーザは、まずメールアドレスでマッチングし、その後ユーザ名でマッチングして Jira にマッピングされます。つまり、

  • 1 人の Jira ユーザーのメール アドレスが一致する — その Jira ユーザとして課題をトランジションします。

  • メール アドレスが一致する Jira ユーザーがいない — 匿名ユーザとして課題をトランジションします。

  • メール アドレスが一致する Jira ユーザーが複数いる — そのユーザー グループで一致するユーザー名を検索します。ユーザー名が一致する Jira ユーザーがいる場合、その Jira ユーザとして課題をトランジションします。ユーザー名が一致するユーザーがいない場合、匿名ユーザーとして課題をトランジションします。

ユーザ マッピングに使用されるメールアドレスとユーザ名

Bitbucket Data Center の場合

Fisheye または Crucible の場合

Bitbucket Cloud の場合

GitHub の場合

イベントのハンドリングとイベントの制限

多くの場合、開発ツールから自動課題遷移へのイベントの処理はシームレスにする必要があります。しかし、時折、イベントのがハンドリングされたりイベントが制限されたりすることで、課題の遷移が遅延したり、課題が全く遷移しなかったりする場合があります。

• イベント ハンドリング — イベントの処理方法は、開発ツールが Jira に DVCS コネクタ経由で接続しているかアプリケーション リンクで接続しているかによって異なります。これは、Jira が利用できない場合にイベントが遅延または消失するかどうかに影響する場合があります。

Bitbucket または GitHub の場合

Bitbucket および GitHub からのイベントはDVCS コネクタ経由で Jira で処理されます。DVCS コネクタは、ウェブブック トリガ同期とスケジュール同期の2つの同期方法で Bitbucket および GitHub からのイベントを処理しています。

• Webhook のトリガーによる同期: DVCS コネクタは Bitbucket および GitHub の Webhook を使用して、イベントが発生した際に Jira にデータを送信します。これはイベントを処理する標準的な方法で、Bitbucket / GitHub イベントの後、ほぼ即座に課題が自動的にトランジションします。イベントの上限: 10 件のブランチ、100 件のコミット。 

• スケジュール同期: イベントの上限: 600 件のブランチ (同期間隔 (分) x 10)、6000 件のコミット (同期間隔 (分) x 100)
  同期間隔を減らすと、スケジュール同期のイベントの上限を 600 件のブランチと 6000 件のコミット未満にすることができますが、増やすことはできません。
  Bitbucket / GitHub イベントが発生したときに Jira に接続できない場合、イベントは DVCS コネクタによって保存され、次にスケジュールされた同期 (デフォルトでは 60 分ごと) に送られます。これは Webhook トリガーによる同期が失敗した場合のバックアップとなります。

Bitbucket Data Center、Fisheye または Crucible の場合

Bitbucket Data Center と Fisheye/Crucible からのイベントは、アプリケーション リンク経由で処理されます。ただし、イベントの送信を確実に実行するよう保証するのは Bitbucket Data Center と Fisheye/Crucible です。なお、イベントは発生時に一度だけ送信されます。これは、イベントが送信される時に Jira が利用できない場合はイベントが消失することを意味しています。

イベントの上限: 同期ごとに 10 件のブランチ、100 件のコミット。10 件のブランチ、100 件のコミットの上限に追加で適用される制限には、課題変更イベントの制限 100,000 件があります。たとえば、100 件のコミットのそれぞれが 1,000 個を超える課題キーを参照する場合は、課題変更制限を超過します。1 回の同期ではイベント 6,000 件が上限です。

トリガーと他のワークフロー操作/制約との関連

トランジションが自動で開始される場合、トランジションに設定されているすべての条件、バリデータ、権限が無視されます。

ただし、事後操作はそのまま実行されます。事後操作がユーザーを必要とする場合、匿名ユーザーはそのトランジションを実行できないことに注意する必要があります (上記の「ユーザー マッピング」セクションをご確認ください)。