ワークフロー トリガーについて
イベント（例：コミット作成）は特定の開発ツールを JIRA に統合することでトリガーに使用することができるようになります。
Adding triggers to global transitions should be done only by those who fully understand the implications of such a move. It can often result in a work item unexpectedly transitioning to the target status in the global transition. For example, triggering a transition when code is committed on a global transition could result in the work item incorrectly transitioning to 'In Progress' out of a number of statuses, like 'In Review' or 'Done'.
Referencing a Jira work item in a commit, branch, pull request, or review
The table below describes how to reference a Jira work item in a commit, branch, pull request, or review, so that these events will trigger transitions for the work item (provided that you have set up triggers on the transitions).
イベント | 手順説明 |
|---|---|
コミットの作成 | Include the work item key in the commit message. For example, a commit message like this "TIS-1 Initial commit" will automatically transition the TIS-1 work item from 'To Do' to 'In Progress'. |
ブランチの作成 | Include the work item key in the branch name, when you create the branch. For example, if you name your branch "TIS-2-feature", it will automatically transition the TIS-2 work item from 'To Do' to 'In Progress'. |
マージプルリクエストの作成/再オープン/拒否 | Ensure that the pull request includes commits that reference the work item (in their commit messages). For example, if you create a pull request that has "TIS-3" in the title, it will automatically transition the "TIS-3" work item from 'In Progress' to 'In Review'. If you reopen, decline or merge the pull request, it will also transition the "TIS-3" work item accordingly. |
レビューの開始/拒否/廃棄/クローズ | Include the work item key in the review title, when you create the review. For example, if you name your review "TIS-4 New story" and start the review, it will automatically transition the TIS-4 work item from 'In Progress' to 'In Review'. If you reject, abandon or close the review, it will also transition the "TIS-4" work item accordingly. |
開発ツールから Jira へユーザをマッピングする
以下のプロセスでは、開発ツールのユーザをワークフロー トリガー用に、Jira ユーザにマッピングする方法を説明しています。これはすべてのイベントに適用されますが、各開発ツールではマッピングに異なるメール アドレスとユーザ名を使用します（以下のプロセスの説明に続く箇条書きを参照してください）。
プロセス： 開発ツールのイベントを初期化するユーザは、まずメールアドレスでマッチングし、その後ユーザ名でマッチングして Jira にマッピングされます。つまり、
Single Jira user with a matching email address — Transition the work item as the Jira user.
No Jira users with a matching email address — Transition the work item as an anonymous user.
Multiple users with a matching email address in Jira — Try to find a matching username in that group of users. If there is a Jira user with a matching username, transition the work item as the Jira user. If there is no matching username, transition the work item as an anonymous user.
ユーザ マッピングに使用されるメールアドレスとユーザ名
Bitbucket Data Center の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
すべてのプル リクエスト イベント | プル リクエストを操作するユーザーの Bitbucket Data Center メール・アドレスとユーザー名。 |
作成されたコミット | コミットに関連付けられているメール・アドレスと、そのメール・アドレスがマッピングされている Bitbucket Data Center のユーザー名。メール・アドレスがユーザー名にマッピングされていない場合は、コミットにおける作成者の「名前」が使用されます。 |
作成されたブランチ | Bitbucket Data Center にブランチをプッシュした認証済みユーザーの Bitbucket Data Center メール アドレスとユーザー名。 |
Fisheye または Crucible の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
作成されたコミット | コミットと FishEye の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 |
作成されたブランチ | This event is not mapped to a Jira user. This means that the work item will be transitioned as an anonymous user. |
すべてのレビュー イベント | レビューを実施する認証済みユーザの Crucible のメールアドレスとユーザ名 |
Bitbucket Cloud の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
すべてのプル リクエスト イベント | The Bitbucket email address and username of the user who actioned the pull request. Note, the Bitbucket user needs to have made at least one commit (with that email address configured for their profile), otherwise the pull request cannot be mapped to a Jira user. This means that the work item will be transitioned as an anonymous user. |
作成されたコミット | コミットと Bitbucket の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 |
作成されたブランチ | This event is not mapped to a Jira user. This means that the work item will be transitioned as an anonymous user. |
GitHub の場合
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
プル リクエストの作成 / プル リクエストのマージ | GitHub email address and username of the user who actioned the pull request. Note, the GitHub user needs to have made at least one commit (with that email address configured for their profile), otherwise the pull request cannot be mapped to a Jira user. This means that the work item will be transitioned as an anonymous user. |
作成されたコミット | コミットに関連付けられたメール アドレスと、メール アドレスがマッピングされた GitHub のユーザー名。メール アドレスがユーザー名にマッピングされていない場合、コミットの作成者の "名前" が使用されます。 |
作成されたブランチ | This event is not mapped to a Jira user. This means that the work item will be transitioned as an anonymous user. |
イベントのハンドリングとイベントの制限
In most cases, the processing of events from your development tools into automatic work item transitions should be seamless. However, sometimes there may be delays in work item transitioning or work item not transitioning at all, due to how events are handled or event limits.
イベント ハンドリング — イベントの処理方法は、開発ツールが Jira に DVCS コネクタ経由で接続しているかアプリケーション リンクで接続しているかによって異なります。これは、Jira が利用できない場合にイベントが遅延または消失するかどうかに影響する場合があります。
Bitbucket または GitHub の場合
Bitbucket および GitHub からのイベントはDVCS コネクタ経由で Jira で処理されます。DVCS コネクタは、ウェブブック トリガ同期とスケジュール同期の2つの同期方法で Bitbucket および GitHub からのイベントを処理しています。
Webhook-triggered synchronization: The DVCS connector uses webhooks in Bitbucket and GitHub to post data to Jira when an event occurs. This is the standard mechanism for processing events, which means that work items should be automatically transitioned almost immediately after a Bitbucket/GitHub event. Event limit: 10 branches; 100 commits.
スケジュール同期: イベントの上限: 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 が利用できない場合はイベントが消失することを意味しています。
Event limit: 10 branches; 100 commits per synchronization. A further constraint that applies on top of the 10 branches and 100 commits limits is a 100,000 work item changed event limit. For example, if 100 commits each reference more than 1000 work item keys, the work item changed limit would be exceeded. Limited to 6000 events per synchronization.
トリガーと他のワークフロー操作/制約との関連
トランジションが自動で開始される場合、トランジションに設定されているすべての条件、バリデータ、権限が無視されます。
ただし、事後操作はそのまま実行されます。事後操作がユーザーを必要とする場合、匿名ユーザーはそのトランジションを実行できないことに注意する必要があります (上記の「ユーザー マッピング」セクションをご確認ください)。
この内容はお役に立ちましたか?