Automation for Jira - 自動化ルールがトリガーされない場合のトラブルシューティング ガイド

要約

Automation for Jira (A4J) アプリで設定されたルールは、イベント (課題の作成、課題の更新、新しいコメントの追加など) によってトリガーされます。ルールが正しく機能していれば、アクションが実行されたかどうかにかかわらず、設定されているイベントをリッスンして、監査ログに新しいエントリが追加されます。ただし、状況によっては、自動化ルールで一部のイベントの「見逃し」や「スキップ」が発生する場合もあります。

この記事では、ルールが想定どおりにトリガーされない最も一般的な理由とその特定方法のリストを示します。

「ルールがトリガーされない」とは

まず、A4J の観点で「ルールがトリガーされない」とはどういう意味なのかを明確にしましょう。

• ここでは、新しい課題が作成されるとトリガーされるように A4J ルールが設定されていると仮定します。

• このルールが設定されたあとに、SCRUM-73 と SCRUM-74 というキーで課題が 2 つ作成されたとします。ルールの監査ログを確認した際に、課題 (下の例では課題キー SCRUM-73) のエントリが表示されていない場合は、この課題でルールがトリガーされなかったことを意味します。

特定のイベントが発生したときに自動化ルールがトリガーされるはずなのに、監査ログにエントリが記録されていない場合は、このナレッジ ベース記事に記載されている根本原因のいずれかが関与している可能性があります。

診断

どの根本原因が関係しているかを特定するには、次の点をチェックします。

• まず、トリガーされなかった自動化ルールが有効になっていることを確認します。下のスクリーンショットのように無効になっている場合は、根本原因 1 が関係しています。

  

• ([ルール詳細] ページで) 自動化ルールの [ルール トリガーを許可] オプションを探します。自動化ルールがトリガーされる頻度が低く、欠落したイベントが他の自動化ルールによって発生している場合は、根本原因 2 が関連します。

• 「課題の作成」イベントでルールがトリガーされるように設定している場合

  • 特定のプロジェクトや特定の課題タイプで作成された課題によってルールがトリガーされない場合は、根本原因 5 が関連している可能性があります。

  • CSV ファイルからインポートされた課題によってルールがトリガーされない場合は、根本原因 6 が関連している可能性があります。

• 影響を受ける自動化ルールの例の監査ログをご確認ください。自動化ルールがトリガーされても、そのルールで一部の課題が断続的にスキップされる場合は (以下の例のように)、根本原因 3 または根本原因 4 が関連している可能性があります。

  

• ⚙ > [アプリを管理] > [アプリを管理] ページから、Jira アプリで A4J が有効になっていることをご確認ください。

  • Jira Data Center のクラスター ノードの場合、各 Jira ノードで A4J が有効になっているかを確認することが重要です。

    これは、このアプリが特定のノードで無効になっている場合があるためです。A4J が少なくとも 1 つのノードで無効になっている場合は、根本原因 3 が関連します。

  • A4J のステータスは次の方法で確認できます。

    • (ロード バランサーをバイパスして) 各ノードに直接ログインし、⚙ > [アプリを管理] > [アプリを管理] ページに移動します。

    • または、各ノードからサポート zip を生成して、application.xml ファイルで「Automation for Jira」を検索します。ノードで A4J が無効になっていると、次のように表示されます。

      1 2 3 4 5 6 7 8 9 10 <plugin> <key>com.codebarrel.addons.automation</key> <name>Automation for Jira</name> <version>8.0.0</version> <vendor>Atlassian</vendor> <status>DISABLED</status> <vendor-url>https://atlassian.com/</vendor-url> <framework-version>2</framework-version> <bundled>User installed</bundled> </plugin>

• Jira クラスターのすべてのノードで A4J が有効になっていても、自動化ルールで一部の課題がランダムにスキップされている場合は、次のステップでスレッド ダンプを生成して自動化スレッドを検索します。少なくとも 1 つのノードのスレッド ダンプでほとんどの A4J スレッドが見つからない場合、このノードは健全ではなく、根本原因 4 が関連します。

• 単に比較する際は、Jira ノードが健全であれば、次のスレッドが見つかるはずです。

  

• スレッ ドダンプを分析する際、A4J スレッドの automation-rule-executor:thread-X がすべて BLOCKED の状態 (以下の例を参照)、または TIMED_WAITING の状態にあることがわかった場合は、根本原因 7 が関連している可能性があります。

  

原因

根本原因 1 - ルールが無効になっている

ルールが無効になっていると、そのルールは設定されたイベントのリスニングを停止し、トリガーされなくなります。

根本原因 2 - ルール トリガーを許可するオプションが無効になっている

初期設定では、新しいルールの [ルール トリガーを許可] オプションが無効になっています。このような場合、ルールがリスニングしているイベントが別の自動化ルールの結果として発生すると、このルールはそのイベントを無視します。

他の自動化ルールによるこのルールのトリガーを許可するには、[ルール詳細] ページでこのオプションにチェックを入れる必要があります。

このシナリオとその解決状況に関する詳細については、ナレッジベース記事「Jira の自動化 - トリガーが別のルールから発生した場合にルールがトリガーされない」をご参照ください。

根本原因 3 - Jira Data Center クラスターの 1 つのノードで A4J アプリが無効になっている

Data Center 環境で Jira ノードのクラスターを使用している場合やノードが正常に起動しなかった場合は、その特定のノードで A4J アプリが無効になっている可能性があります。

この場合、次のようになります。

• そのノードで課題が作成/更新されるたびに、この課題によって発生したイベントは A4J に無視されます。該当のイベントはそのノードで無効になっているためです。

• よく見られる症状では、ほとんどの課題で自動化ルールがトリガーされても、課題がスキップされます。

このシナリオとその解決状況に関する詳細については、ナレッジベース記事「Jira の自動化 - アプリが無効化されているために一部の Jira 課題でルールがトリガーされない」をご参照ください。

根本原因 4 - A4J スレッドが Jira Data Center クラスターの 1 つのノードで実行されていない

Data Center 環境で Jira ノードのクラスターを使用している場合、A4J がすべてのノードで有効になっているのに、何らかの理由で、起動時にそれ自体のスレッドの初期化に失敗することがあります。A4J がそれ自体のスレッドの初期化に失敗する理由は不明ですが、まれなケースとして起こる可能性があります。

この場合、次のようになります。

• そのノードで課題が作成/更新されるたびに、この課題によって発生したイベントは A4J に無視されます。該当のイベントはそのノードで無効になっているためです。

• よく見られる症状では、ほとんどの課題で自動化ルールがトリガーされても、課題がスキップされます。

このシナリオとその解決状況に関する詳細については、ナレッジベース記事「Jira の自動化 - スレッドが不足しているために一部の Jira 課題でルールがトリガーされない」をご参照ください。

根本原因 5 - 「課題の作成」イベントでルールがトリガーされるはずだが、ワークフローで間違ったイベントが発生する

新しい課題の作成時にトリガーされるルールは、Jira アプリによって発生する「課題の作成」イベントに依存します。初期設定では、どのワークフローも「課題の作成」イベントで開始されるように設定されます。そのため、このイベントに依存する機能 (Jira 通知、自動化ルールなど) をトリガーできます。

ワークフローの作成トランジションの事後操作が別のタイプのイベントを発生させるように編集された場合、このイベントに依存する自動化ルールはトリガーされなくなります。

ワークフローが課題作成時に正しいイベントを発生させているかどうかを確認する方法は次のとおりです。

1. ルールがトリガーされると予想していた、作成された課題のタイプに関連するワークフローに移動します。

2. [作成] トランジション > [事後操作] リンクの順にクリックします。

3. 事後操作で発生するイベントをチェックして、次のいずれかであることをご確認ください。

4. ID 1 のイベント開始 (「課題の作成」イベント)

   

5. または「課題の作成」イベントを明示的に発生

   

根本原因 6 - ルールは「課題の作成」イベントでトリガーされるべきだが、課題が CSV インポートから作成された

Jira ですぐに使える CSV インポートには次の 2 タイプがあります。

1. 一括作成 ([課題] > [CSV からの課題のインポート] ページからアクセス可能)

2. CSV の外部システム インポート (⚙ > [システム] > [外部システム インポート] > [CSV] ページからアクセス可能)

1 番目のタイプのインポートは、課題を作成プロジェクト権限とプロジェクトの一括変更グローバル権限が付与されたユーザーが利用できますが、2 番目のタイプのインポートは Jira システム管理者ユーザーのみが使用できます。

注意すべき重要な点は、このインポートで課題が作成されたときに、2 番目のタイプのインポートでは「課題の作成」イベントがトリガーされないということです。その結果、トリガーされるこのイベントに依存する Jira (またはサードパーティのアドオン) 機能はトリガーされません。該当する機能には以下が含まれます。

• Jira のネイティブ Webhook

• Jira の自動化の「課題の作成」トリガー

• 「課題の作成」イベントに基づくメール通知

この挙動は、機能リクエストで追跡されます。「課題の作成」または「課題の更新」イベントは、CSV 外部システム インポートを使用して課題をインポートしてもトラップされません。

トリガーされなかった自動化ルールが「課題の作成」イベントで設定されている場合、および課題が CSV 外部システム インポートを使用して作成された場合は、この挙動は想定どおりであり、この根本原因が関連しています。インポートされた課題に対してルールが確実にトリガーされるように、一括作成 CSV インポートを代用する必要があります。

根本原因 7 -サードパーティのアドオンが原因で、すべてのA4J実行スレッドが停滞している

A4J 実行スレッド automation-rule-executor:thread-X は、A4J キューに累積されるイベントを処理します。サードパーティのアドオンが原因で、これらすべてのスレッドが「BLOCKED」または「TIMED_WAITING」の状態になり、実行を停止する場合があります。

この根本原因が関連しているかどうかを確認するには、ナレッジベース記事「Automation for Jira - The automation executor threads are stuck because of the usage of a 3rd party add-on」をご確認ください。

根本原因 8 - 「フィールド値の変更時」トリガーで構成されたルールが、「Field Security Plugin for Jira」アドオンが原因でトリガーされない

ナレッジベース記事「Automation For Jira - Some automation rules using the "Field value changed" trigger are not triggered」で説明されているように、サードパーティ製アドオンの Field Security Plugin for Jira が原因となり、監視しているフィールドが更新されたときに、フィールド値の変更時トリガーを使用する自動化ルールがトリガーされない場合があります。 この根本原因が関連しているかどうかを確認するには、リンク先のナレッジベース記事をご確認ください。

根本原因 9 - 「複数の課題イベント」トリガーで構成されたルールが、イベントが別のルールによって公開された場合、トリガーされない

この根本原因が関連しているかどうかを確認するには、次の点をご確認ください。

• 影響を受けるルールのタイプは、複数の課題イベントトリガーで構成されたルールだけです。

• 影響を受けるルールは、トリガーを許可オプションがチェックされた状態で設定済みです (他のルールでもこれらのルールをトリガーできます)。

• これらのルールをトリガーするイベントは、他の自動化ルールによって公開されたものです。

• イベントを公開しているルールでは、イベントを公開アクションで、新規スタイル「IssueEventBundle」を公開するオプションがチェックされていません。

上記のすべての点が確認されれば、この根本原因が関連していて、JIRAAUTOSERVER-910 というバグに直面しています。イベントが別のルールから発生した場合、イベントをリッスンしているルールはトリガーされません

この問題を解決するには、新規スタイル「IssueEventBundle」を公開するオプションでイベントを公開アクションをチェックしてください。

根本原因 10 - 同じイベントによって複数のルールがトリガーされ、そのうちの 1 つが完了するまでに 5 分以上かかる

同じイベントによって複数のルールがトリガーされた場合、Automation For Jira は各ルールを 1 つずつ順番にループしてイベントを処理します。イベントを処理しているルールの 1 つが完了するまでに 5 分以上かかると、次のことが起こります。

• イベントがキャッシュからクリアされる (これは、Automation For Jira が 5 分以上アクセスされていないイベントをキャッシュから自動的にクリアするためです)

• Jira ログに以下の例外が記録される

• イベントを処理するためのルールがまだいくつか残っていても、Automation For Jira がループを終了する

• 最終的に、一部のルールがイベントで見逃され、トリガーされない

この動作はバグとして特定され、JIRAAUTOSERVER-946 で報告されています。自動化ルールは、他の自動化ルールが完了するまでに 5 分以上かかっていると、一部のイベントをスキップする場合があります

この根本原因が該当するかを確認するには

• ある自動化ルールで見逃されたイベントが、別の自動化ルールによって処理され、完了までに 5 分以上かかっているかどうかを確認する (自動化ルールの実行時間は、監査ログの「Duration」列で確認できます)

• Jira アプリケーション ログに上記の例外があるかどうかを確認する

残念ながら、次の方法以外に、このバグの理想的で簡単な回避策はありません。

• 他のルールで見逃されたイベントの処理に 5 分以上かかっているルールを特定する

• 次に、このルールを無効にするか、5 分以内で完了できるように最適化する

根本原因 11 - ルールが「複数の課題イベント」トリガーを使用して設定されており、間違ったイベントが選択されている

ルールが「複数の課題イベント」トリガーを使用して設定されている場合は、トリガーされる適切なイベントを選択することが重要です。たとえば、このルールが、課題を更新したときに発生するイベントに反応するように構成されていて、課題が新しいステータスに移行したときにルールがトリガーされることを想定している場合、そのトランジションによって想定されるイベントは、ルールが構成されているイベントと同じである必要があります。

この根本原因が該当するかを確認する方法

• ルール構成に移動し「複数の課題イベント」トリガーが設定されているイベントを確認する

• このルールをトリガーできなかった Jira 課題で使用されたワークフローに移動し、この Jira 課題に使用したトランジションを確認し、このトランジションで構成された事後操作のリストを確認する

• このトランジションによって発生するイベントを確認する

• トランジションによって発生したイベントが、ルールが監視しているイベントと一致しない場合は、この根本原因が関係する

• そのような場合は、両方のイベントが一致するようにワークフローのトランジションまたは自動化ルールのトリガーを編集する

ソリューション

解決策は、上記の各根本原因の下に記載されています。