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

トリガー イベント

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

開発ツールBitbucket、GitHub、GitHub EnterprisecrucibleFisheye
イベント
  • プルリクエスト作成
  • プルリクエストのマージ
  • プル リクエストの拒否(Bitbucket のみ)
  • プル リクエストの再オープン(Bitbucket サーバーのみ)
  • 作成されたコミット
  • 作成されたブランチ
  • レビューの開始
  • 承認にサブミット
  • レビューの却下
  • レビューの放棄
  • レビューのクローズ
  • レビューの要約
  • 作成されたコミット
  • 作成されたブランチ

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

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

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

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

tip/resting Created with Sketch.

ワークフローにグローバル トランジションを使用する場合、複数のトランジションが 1 つのステータスに遷移する場合があります。これはユーザが課題で複数のワークフロー オプション (例: 「開始」と「進行中」) を持つことを意味しています。このオプションを非表示にするには、「ユーザからトランジションを非表示にする」条件を、関連するトランジションに追加します。

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

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

イベント手順説明
コミットの作成

コミットメッセージに課題キーを含めます。

たとえば、"TIS-1 最初のコミット" のようなコミットメッセージは、TIS-1 課題を「作業前」から「進行中」に自動的に移行します 。

ブランチの作成

ブランチを作成する際に、ブランチ名に課題キーを含めます。

たとえば、ブランチに "TIS-2-feature" と名前をつけると、TIS-2 課題は「作業前」から「進行中」に自動的に移行します。

マージプルリクエストの作成/再オープン/拒否

プル リクエストに(コミット メッセージで)課題を参照するコミットを含めます。

たとえば、タイトルが "TIS-3" のプル リクエストを作成すると、"TIS-3" 課題は「進行中」から「レビュー」に自動的にトランジションします。プル リクエストを再オープン、却下、またはマージすると、それに応じて "TIS-3" 課題はトランジションします。

レビューの開始/拒否/廃棄/クローズ

レビューを作成するときに、課題キーをレビュータイトルに含めます。

たとえば、レビューに "TIS-4 New story" という名前をつけて、レビューを開始すると、TIS-4 課題は「進行中」から「レビュー」に自動的に遷移します。レビューを拒否、放棄、またはクローズすると、それに応じて "TIS-4" 課題は遷移します。

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

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

  • プロセス: 開発ツールのイベントを初期化するユーザは、まずメールアドレスでマッチングし、その後ユーザ名でマッチングして Jira にマッピングされます。つまり、
    • 1 人の Jira ユーザーのメール アドレスが一致する — その Jira ユーザとして課題をトランジションします。
    • メール アドレスが一致する Jira ユーザーがいない — 匿名ユーザとして課題をトランジションします。
    • メール アドレスが一致する Jira ユーザーが複数いる — そのユーザー グループで一致するユーザー名を検索します。ユーザー名が一致する Jira ユーザーがいる場合、その Jira ユーザとして課題をトランジションします。ユーザー名が一致するユーザーがいない場合、匿名ユーザーとして課題をトランジションします。

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

Bitbucket Server の場合

イベントユーザ マッピングに使用されるメールアドレスとユーザ名
すべてのプル リクエスト イベントプル リクエストを操作するユーザの Bitbucket Server メールアドレスとユーザ名
作成されたコミットコミットと Bitbucket Server の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
作成されたブランチBitbucket Server にブランチをプッシュした認証済みユーザの Bitbucket Server メールアドレスとユーザ名

Fisheye または Crucible の場合

イベントユーザ マッピングに使用されるメールアドレスとユーザ名
作成されたコミットコミットと FishEye の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
作成されたブランチこのイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 
すべてのレビュー イベントレビューを実施する認証済みユーザの Crucible のメールアドレスとユーザ名

Bitbucket Cloud の場合

イベントユーザ マッピングに使用されるメールアドレスとユーザ名
すべてのプル リクエスト イベントプル リクエストを操作するユーザの Bitbucket のメールアドレスとユーザ名注: Bitbucket ユーザ(プロフィールにメールアドレスを設定している)はコミットを少なくとも1つ持っている必要があり、そうでない場合はプル リクエストが Jira ユーザにマッピングできません。これは、課題が匿名ユーザとして遷移されることを意味しています。 
作成されたコミットコミットと Bitbucket の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
作成されたブランチ このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 

GitHub の場合

イベントユーザ マッピングに使用されるメールアドレスとユーザ名
プル リクエストの作成 / プル リクエストのマージプル リクエストを実施したユーザーの GitHub のメール アドレスとユーザ名。注: GitHub のユーザー (対象のメール アドレスをプロフィールに設定したユーザー) は 1 件以上のコミットを実行済みである必要があります。そうでない場合、プル リクエストを Jira ユーザーにマッピングすることができません。この場合、課題は匿名ユーザーとしてトランジションされます。  
作成されたコミットコミットに関連付けられたメール アドレスと、メール アドレスがマッピングされた GitHub のユーザー名。メール アドレスがユーザー名にマッピングされていない場合、コミットの作成者の "名前" が使用されます。
作成されたブランチ  このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。  

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

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

  • イベント ハンドリング — イベントの処理方法は、開発ツールが 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 ServerFisheye または Crucible の場合

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

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

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

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

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