2.3. 基本的な YAML ルールを作成する
このセクションでは、基本的な MTA YAML ルールを作成する方法を説明します。これは、すでに MTA がインストールされていることを前提としています。インストール手順は、MTA CLI ガイド を参照してください。
2.3.1. 基本的な YAML ルールのテンプレートを作成する リンクのコピーリンクがクリップボードにコピーされました!
MTA YAML ベースのルールの基本構造は、以下のとおりです。
when(condition) message(message) tag(tags)
when(condition)
message(message)
tag(tags)
手順
以下のように、
/home/<USER>/
ディレクトリーに YAML ルールの基本構文を含むファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.2. ルールのカテゴリー リンクのコピーリンクがクリップボードにコピーされました!
-
mandatory
: 移行を成功させるには、この問題を解決する必要があります。変更を行わないと、生成されるアプリケーションは正常にビルドまたは実行されません。例としては、ターゲットプラットフォームでサポートされていない独自の API の置き換えが挙げられます。 -
optional
: 問題を解決しない場合、アプリケーションは正常に動作するはずですが、最適な結果にはならない可能性があります。移行時に変更を行わない場合は、移行が完了したらすぐにスケジュールに含めることを推奨します。 -
potential
: 移行プロセス中に問題を調べる必要がありますが、移行を成功させるために問題の解決が必須かどうかを判断するのに十分な情報がありません。このような問題の例としては、ターゲットプラットフォームに直接互換性のある型がない場合に、サードパーティー独自の型を移行する場合が挙げられます。
2.3.3. ルールアクション リンクのコピーリンクがクリップボードにコピーされました!
ルールには次の種類のアクションを使用できます。
- message
- tag
各ルールには、これらのいずれかまたは両方が含まれます。
メッセージアクション
メッセージアクションがルールに一致すると、問題が作成されます。プロバイダーがエクスポートするカスタムデータをメッセージで使用できます。
- ruleID: test-rule when: <CONDITION> message: Test rule matched. Please resolve this migration issue.
- ruleID: test-rule
when:
<CONDITION>
message: Test rule matched. Please resolve this migration issue.
オプションで、問題に関する関連情報や簡単な修正を提供する外部 URL へのハイパーリンクをメッセージに含めることができます。
links: - url: "konveyor.io" title: "Short title for the link"
links:
- url: "konveyor.io"
title: "Short title for the link"
メッセージは、ルールのカスタム変数を通じて挿入される、一致に関する情報を含めるテンプレートにすることもできます。
2.3.4. ルール条件 リンクのコピーリンクがクリップボードにコピーされました!
各ルールには、MTA が特定のアクションを実行するために満たす必要のある条件を指定する when
ブロックがあります。
when
ブロックには 1 つの条件が含まれますが、その条件の下に複数の条件をネストできます。
when: <condition> <nested-condition>
when:
<condition>
<nested-condition>
MTA は次のタイプの条件をサポートします。
-
provider
-
and
-
or
2.3.5. タグアクション リンクのコピーリンクがクリップボードにコピーされました!
タグアクションは、一致が見つかった場合にアプリケーション用に 1 つ以上のタグを生成するようにアナライザーに指示します。tag
フィールドの各文字列は、タグのコンマ区切りリストにできます。オプションで、タグにカテゴリーを割り当てることができます。
tag: - "tag1,tag2,tag3" - "Category=tag4,tag5"
tag:
- "tag1,tag2,tag3"
- "Category=tag4,tag5"
例:
タグは、文字列または key=val
ペアにすることができ、キーは MTA のタグカテゴリーとして処理されます。このドキュメントでは、タグアクションを持つルールは「タグ付けルール」と呼ばれます。
タグアクションのみを含むルールの場合、問題は作成されません。
2.3.6. メッセージアクション リンクのコピーリンクがクリップボードにコピーされました!
メッセージアクションは、ルールが一致したときに指定のメッセージを付けて問題を生成する場合に使用されます。次に例を示します。
# When a match is found, the analyzer generates incidents with the same message. message: "helpful message about the violation"
# When a match is found, the analyzer generates incidents with the same message.
message: "helpful message about the violation"
メッセージは、ルールのカスタム変数を通じて挿入される、一致に関する情報を含めるテンプレートにすることもできます。
2.3.7. ハイパーリンク リンクのコピーリンクがクリップボードにコピーされました!
発見された問題に関する関連情報を提供するために、message
または tag
アクションとともにハイパーリンクを指定できます。
2.3.8. プロバイダーの条件 リンクのコピーリンクがクリップボードにコピーされました!
アナライザーエンジンは、providers を使用して多言語ソースコードの分析を可能にします。技術のソースコードはプロバイダーによって分析されます。
プロバイダーは、ソースコードを使用して機能的に何ができるかを公開します。
プロバイダー条件は、アナライザーに特定のプロバイダーとその機能の 1 つを使用するように指示します。一般的には、<provider_name>.<capability>
パターンに従います。
when: <provider_name>.<capability> <input_fields>
when:
<provider_name>.<capability>
<input_fields>
アナライザーは現在、次の provider
条件をサポートしています。
-
builtin
-
java
-
Go
-
dotnet
CLI で複数のアプリケーションを分析するときに 1 つのレポートを提供するためのサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
プロバイダールールの条件 | プロバイダー名 |
---|---|
完全にサポートされ、製品に含まれているプロバイダー | Java |
製品内ですでにルールが定義されているプロバイダー | .NET |
分析にカスタムルールセットを必要とするプロバイダー |
|
プロバイダーに応じて、条件のフィールド (例: 前の例のパターンとロケーション) が変わります。
一部のプロバイダーには dependency_ capability があります。dependency_capability では、プロバイダーが特定のアプリケーションの依存関係のリストを生成します。
dependency_condition を使用してこのリストを検索し、特定の依存関係 (バージョン範囲を含む) がアプリケーションに存在するかどうかを確認できます。
たとえば、Java アプリケーションに特定の依存関係があるかどうかを確認するには、java.dependency
条件を作成します。
when: java.dependency: name: junit.junit upperbound: 4.12.2 lowerbound: 4.4.0
when:
java.dependency:
name: junit.junit
upperbound: 4.12.2
lowerbound: 4.4.0
Analyzer は現在、次のプロバイダーをサポートしています。
-
builtin
-
java
-
Go
-
generic
次の表は、すべてのプロバイダーとその機能をまとめたものです。
プロバイダー名 | ケイパビリティー | 説明 |
---|---|---|
| referenced | 詳細な検索のために、オプションのコード位置を使用してパターンの参照を検索します。 |
dependency | アプリケーションに特定の依存関係があるかどうかを確認します。 | |
| xml | xpath クエリーを使用して XML ファイルを検索します。 |
|
| |
filecontent | 正規表現パターンを使用して通常のファイル内のコンテンツを検索します。 | |
file | 指定されたパターンに一致する名前を持つファイルを検索します。 | |
hasTags | タグ付けルールを使用してアプリケーションのタグが作成されているかどうかを確認します。 | |
| referenced | パターンへの参照を検索します。 |
dependency | アプリケーションに特定の依存関係があるかどうかを確認します。 |
前の表の例に従って、条件フィールドを含まない条件の最初の部分を作成できます。
例
referenced
ケイパビリティーを使用する java
プロバイダー条件を作成します。
when: java.referenced: <fields>
when:
java.referenced:
<fields>
provider と capability に応じて、条件内の <fields>
は異なります。
次の表は、利用可能なプロバイダー、そのケイパビリティー、およびそのすべてのフィールドをまとめたものです。
プロバイダー | 機能 | Fields | 必須 | 説明 |
---|---|---|---|---|
java | referenced | pattern | はい | 正規表現パターン |
location | いいえ | ソースコードの場所 (Java のロケーション を参照) | ||
annotated | いいえ | アノテーションを検査するための追加クエリー (アノテーション検査 を参照)。 | ||
dependency | name | はい | 依存関係の名前 | |
nameregex | いいえ | 名前に一致する正規表現パターン。 | ||
upperbound | いいえ | バージョンが同等以下であるものに一致 | ||
lowerbound | いいえ | バージョンが同等以上であるものに一致 | ||
builtin | xml | xpath | はい | XPath クエリー |
namespaces | いいえ | クエリーの範囲を名前空間に絞るためのマップ | ||
filepaths | いいえ | 検索範囲を絞るためのオプションのファイルリスト | ||
json | xpath | はい | XPath クエリー | |
filepaths | いいえ | 検索範囲を絞るためのオプションのファイルリスト | ||
filecontent | pattern | はい | コンテンツに一致する正規表現パターン | |
filePattern | いいえ | このパターンに一致する名前のファイルのみを検索する | ||
file hasTags | pattern | はい | このパターンに一致する名前のファイルを検索する | |
hasTags | 文字列タグのインラインリストです。タグアクション を参照 | |||
Go | referenced | pattern | はい | 正規表現パターン。 |
dependency | name | はい | 依存関係の名前 | |
nameregex | いいえ | 名前に一致する正規表現パターン。 | ||
upperbound | いいえ | バージョンが同等以下であるものに一致 | ||
lowerbound | いいえ | バージョンが同等以上であるものに一致 |
例
たとえば、先ほど作成した Java
条件の例を完了するには、パッケージの参照を検索します。
when: java.referenced: location: PACKAGE pattern: org.jboss*
when:
java.referenced:
location: PACKAGE
pattern: org.jboss*
2.3.8.1. Builtin プロバイダー リンクのコピーリンクがクリップボードにコピーされました!
builtin
は、エンジンによって生成されたさまざまなファイルと内部メタデータを分析できる内部プロバイダーです。このプロバイダーには次のケイパビリティーがあります。
-
file
-
filecontent
-
xml
-
json
-
hasTags
file
file
ケイパビリティーを使用すると、プロバイダーは指定されたパターンに一致するソースコード内のファイルを検索できます。
when: builtin.file: pattern: "<regex_to_match_filenames>"
when:
builtin.file:
pattern: "<regex_to_match_filenames>"
filecontent
プロバイダーは、filecontent
ケイパビリティーを使用して、指定されたパターンに一致するコンテンツを検索します。
when: builtin.filecontent: filePattern: "<regex_to_match_filenames_to_scope_search>" pattern: "<regex_to_match_content_in_the_matching_files>"
when:
builtin.filecontent:
filePattern: "<regex_to_match_filenames_to_scope_search>"
pattern: "<regex_to_match_content_in_the_matching_files>"
xml
xml
ケイパビリティーを使用すると、プロバイダーは指定された XML ファイルのリストに対して XPath 式のクエリーを実行できます。このケイパビリティーでは、xpath
と filepaths
という 2 つの入力パラメーターを使用できます。
json
json
ケイパビリティーを使用すると、プロバイダーは提供された JSON ファイルのリストに対して XPath 式のクエリーを実行できます。現在、json
は XPath のみを入力として受け取り、コードベース内のすべての JSON ファイルに対して検索を実行します。
when: builtin.json: xpath: "<xpath_expressions>"
when:
builtin.json:
xpath: "<xpath_expressions>"
- 1
xpath
は、有効な XPath 式である必要があります。
hasTags
プロバイダーは、hasTags
ケイパビリティーを使用してアプリケーションタグを照会します。内部データ構造をクエリーして、アプリケーションに指定されたタグがあるかどうかを確認します。
when: # when more than one tag is given, a logical AND is implied hasTags: - "tag1" - "tag2"
when:
# when more than one tag is given, a logical AND is implied
hasTags:
- "tag1"
- "tag2"
- 1
- 複数のタグが指定されている場合は、論理積が暗黙的に指定されます。
2.3.8.2. Java プロバイダー リンクのコピーリンクがクリップボードにコピーされました!
java
プロバイダーは、Java ソースコードを分析します。
このプロバイダーには次のケイパビリティーがあります。
-
referenced
-
dependency
referenced
referenced
ケイパビリティーを使用して、プロバイダーはソースコード内の参照を見つけます。この機能には、pattern
、location
、annotated
という 3 つの入力パラメーターを使用できます。
when: java.referenced: pattern: "<pattern>" location: "<location>" annotated: "<annotated>"
when:
java.referenced:
pattern: "<pattern>"
location: "<location>"
annotated: "<annotated>"
- 1
- 一致する正規表現パターン。
- 2
- パターンを照合する必要がある正確な場所を指定します (例:
IMPORT
)。 - 3
- クエリーを使用して、Java コード内の名前や値などの特定のアノテーションとその要素をチェックします。たとえば、次のクエリーはメソッド内の
Bean
(url = “http://www.example.com”) アノテーションと一致します。annotated: pattern: org.framework.Bean elements: - name: url value: "http://www.example.com"
annotated: pattern: org.framework.Bean elements: - name: url value: "http://www.example.com"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.8.3. Java の場所 リンクのコピーリンクがクリップボードにコピーされました!
Java
プロバイダーを使用すると、特定のソースコードの場所に検索範囲を絞り込むことができます。
- IMPORT: IMPORT を使用すると、クラスのインポートの検索が可能になります。FQN やアステリスクを使用して検索対象を広げます。
java.referenced: pattern: org.apache.lucene.search* location: IMPORT
java.referenced:
pattern: org.apache.lucene.search*
location: IMPORT
以下の各インポートと一致します。
import org.apache.lucene.search.Query; import org.apache.lucene.search.Sort; import org.apache.lucene.search.SortField;
import org.apache.lucene.search.Query;
import org.apache.lucene.search.Sort;
import org.apache.lucene.search.SortField;
結果の範囲が広いため、ドットの後ではなくパッケージの直後に配置することを推奨します。
- PACKAGE: PACKAGE の場所は、インポートとして使用されている場合でも、コード内で完全修飾名の一部として使用されている場合でも、パッケージが使用されているすべての箇所に一致します。
java.referenced: pattern: org.apache.lucene.search* location: PACKAGE
java.referenced:
pattern: org.apache.lucene.search*
location: PACKAGE
インポートと完全修飾の使用法の両方に一致します。
import org.apache.lucene.search.*;
import org.apache.lucene.search.*;
public class Test { private org.apache.lucene.search.Query query; }
public class Test {
private org.apache.lucene.search.Query query;
}
より適切な結果を得るには、パッケージ区切りドット (.
) の直後に (*
) を使用します。
- CONSTRUCTOR_CALL および METHOD_CALL: それぞれコンストラクターとメソッドを照会します。パターンの可能性は非常に多様であり、特定の戻り値の型、引数などと一致させることも可能です。
たとえば、java.lang.String
を拡張し、単一のパラメーターを受け入れる型の List
を返す、org.konveyor.MyClass
で宣言された “method” という名前のメソッドを検索するとします。
java.referenced: location: METHOD pattern: 'org.konveyor.Myclass.method(*) java.util.List<? extends java.lang.String>'
java.referenced:
location: METHOD
pattern: 'org.konveyor.Myclass.method(*) java.util.List<? extends java.lang.String>'
このようなパターンの可能性に関する情報は、公式の Java ドキュメント の createPattern(String, int, int, int)
セクションに記載されています。このドキュメントには、このようなパターンに関する情報がすべて含まれます。
現在、完全修飾静的メソッドの一致ではエラーが発生しやすくなります。
- TYPE: どこにでも出現する一般的なタイプに一致します。
- INHERITANCE: 特定の型から継承するクラスと一致します。
- ANNOTATION: アノテーションと一致します。
- IMPLEMENTS_TYPE: 指定された型を実装する任意の型と一致します。
- ENUM_CONSTANT: 列挙定数と一致します。
- RETURN_TYPE: メソッドによって返される型と一致します。
- VARIABLE_DECLARATION: 変数として宣言されている型と一致します。
- FIELD (宣言): フィールド宣言に含まれる型と一致します。これは、フィールド上で行われるアノテーションマッチと組み合わせることができます (アノテーション検査 を参照)。
- METHOD: 指定されたメソッド宣言と一致します。アノテーションマッチと組み合わせることができます (アノテーション検査 を参照)。
- CLASS (宣言): 指定されたメソッド宣言と一致します。アノテーションマッチと組み合わせることができます (アノテーション検査 を参照)。
次の場所がサポートされています。
-
CONSTRUCTOR_CALL
-
TYPE
-
INHERITANCE
-
METHOD_CALL
-
ANNOTATION
-
IMPLEMENTS_TYPE
-
ENUM_CONSTANT
-
RETURN_TYPE
-
IMPORT
-
VARIABLE_DECLARATION
-
FIELD
-
METHOD
dependency
dependency
ケイパビリティーを使用して、プロバイダーは特定のアプリケーションの依存関係を見つけます。MTA は、アプリケーションの依存関係のリストを生成します。このケイパビリティーを使用してリストをクエリーし、依存関係バージョンの指定された範囲内でアプリケーションに特定の依存関係が存在するかどうかを確認できます。
when: java.dependency: name: "<dependency_name>" upperbound: "<version_string>" lowerbound: "<version_string>"
when:
java.dependency:
name: "<dependency_name>"
upperbound: "<version_string>"
lowerbound: "<version_string>"
2.3.8.4. アノテーション検査 リンクのコピーリンクがクリップボードにコピーされました!
特定のアノテーションとその要素と一致するクエリーを追加できます。次に例を示します。
これは、次の Java コードの runApplication
メソッドと一致します。
annotated
YAML 要素の構成は次のとおりです。
annotated: pattern: a Java regex to match the fully qualified name of the annotation (optional) elements: an array of elements to match within the annotation (optional) - name: the exact name of the element to match against value: a Java regex to match the value of the element
annotated:
pattern: a Java regex to match the fully qualified name of the annotation (optional)
elements: an array of elements to match within the annotation (optional)
- name: the exact name of the element to match against
value: a Java regex to match the value of the element
アノテーションを付けるシンボルを指定せずに、アノテーションを特定の要素と一致させることも可能です。次の例も、前の例と同じコード内の @Bean
アノテーションと一致します。
pattern
で指定される唯一の要素は、アノテーションです。
2.3.8.5. Go プロバイダー リンクのコピーリンクがクリップボードにコピーされました!
go
プロバイダーは、Go ソースコードを分析します。このプロバイダーのケイパビリティーは、referenced
と dependency
です。
referenced
referenced
ケイパビリティーを使用して、プロバイダーはソースコード内の参照を見つけます。
when: go.referenced: "<regex_to_find_reference>"
when:
go.referenced: "<regex_to_find_reference>"
dependency
dependency
ケイパビリティーを使用して、プロバイダーはアプリケーションの依存関係を見つけます。
when: go.dependency: name: "<dependency_name>" upperbound: "<version_string>" lowerbound: "<version_string>"
when:
go.dependency:
name: "<dependency_name>"
upperbound: "<version_string>"
lowerbound: "<version_string>"
2.3.8.6. Dotnet プロバイダー リンクのコピーリンクがクリップボードにコピーされました!
dotnet
プロバイダーは、.NET および C# ソースコードを分析するために使用される外部プロバイダーです。現在、このプロバイダーは referenced
ケイパビリティーをサポートしています。
referenced
referenced
ケイパビリティーを使用して、プロバイダーはソースコード内の参照を見つけます。
when: dotnet.referenced: pattern: "<pattern>" namespace: "<namespace>"
when:
dotnet.referenced:
pattern: "<pattern>"
namespace: "<namespace>"
2.3.9. 条件パターン リンクのコピーリンクがクリップボードにコピーされました!
Java プロバイダーによって使用される言語サーバーは、Eclipse の JDTLS です。内部的には、Eclipse Java Development Toolkit を使用します。このツールキットには、JDTLS はプロジェクト内のコードを検索するユーティリティーが含まれます。
java.referenced
条件の pattern
要素では、これらのユーティリティーを使用してアプリケーションコードを検索できます。詳細は、Class SearchPattern を参照してください。このクラスには createPattern(String, int, int, int)
のこれらのパターンを構築するための情報がすべて含まれます。
例
javax.xml
パッケージ内のあらゆるクラスを検索します。java.referenced: pattern: javax.xml*
java.referenced: pattern: javax.xml*
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告前の例のように、パッケージと照合する場合、アスタリスクはドットの後に指定しないようにしてください。たとえば、*
pattern: javax.xml*
ではなく、*pattern: javax.xml.*
です。java.lang.String
を返すメソッド宣言を検索します。java.referenced: location: METHOD pattern: '* java.lang.String'
java.referenced: location: METHOD pattern: '* java.lang.String'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow org.konveyor.MyClass
で宣言されており、java.lang.String
を拡張する型のList
を返す、名前が “method” のメソッドを検索します。java.referenced: location: METHOD pattern: 'org.konveyor.Myclass.method(*) java.util.List<? extends java.lang.String>'
java.referenced: location: METHOD pattern: 'org.konveyor.Myclass.method(*) java.util.List<? extends java.lang.String>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow java.util.List
を実装するクラスを検索します。java.referenced: location: IMPLEMENTS_TYPE pattern: java.util.List
java.referenced: location: IMPLEMENTS_TYPE pattern: java.util.List
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.10. カスタム変数 リンクのコピーリンクがクリップボードにコピーされました!
プロバイダー条件には、カスタム変数を関連付けることができます。カスタム変数を使用すると、ソースコード内の一致する行から関連情報を取得できます。これらの変数の値には、ソースコード内で一致するデータが挿入されます。これらの値を使用して、ルールのアクションで詳細なテンプレートメッセージを生成できます (メッセージアクション を参照)。これらは、customVariables
フィールドのルールに追加できます。
2.3.11. 論理条件 リンクのコピーリンクがクリップボードにコピーされました!
アナライザーには、and
と or
の 2 つの基本的な論理条件があります。これらを使用して、他の条件の結果を集計し、より複雑なクエリーを作成できます。
2.3.11.1. AND 条件 リンクのコピーリンクがクリップボードにコピーされました!
and
条件は、条件の配列の結果に対して論理 AND 演算を実行します。
and
条件は、その子条件が すべて 一致する場合に一致します。例:
when: and: - <condition1> - <condition2>
when:
and:
- <condition1>
- <condition2>
例
2.3.11.1.1. ネストされた条件 リンクのコピーリンクがクリップボードにコピーされました!
条件は、他の条件内でネストすることもできます。
- 例
2.3.11.2. OR 条件 リンクのコピーリンクがクリップボードにコピーされました!
or
条件は、条件の配列の結果に対して論理 OR 演算を実行します。
or
条件は、その子条件の いずれか が一致する場合に一致します。例:
when: or: - <condition1> - <condition2>
when:
or:
- <condition1>
- <condition2>
例
2.3.11.3. 条件連鎖の変数 リンクのコピーリンクがクリップボードにコピーされました!
and
および or
条件では、1 つの条件の出力を、別の条件を絞り込む際の入力として使用できます。これを 条件の連鎖 と呼びます。
例
上記の例では、builtin.file
条件の出力は poms
として保存されます。
+
[...] as: poms [...]
[...]
as: poms
[...]
builtin.file
の変数は、from
を記述して、provider_ condition
ブロックの mustache templates を使用することで、builtin.xml
で使用できます。
このようにして、この特定の条件は、名前 poms
に設定された変数がどのように使用されるかを認識します。
+
[...] from: poms [...]
[...]
from: poms
[...]
次に、provider 条件への入力のいずれかで変数を mustached テンプレートとして設定して使用できます。
+
[...] filepaths: "{{poms.filepaths}}" [...]
[...]
filepaths: "{{poms.filepaths}}"
[...]
条件の値を連鎖としてのみ使用する場合は、ignore: true
を設定できます。
この設定によって、エンジンはこの条件を使わずにルール違反の有無を判断するように指示が出されます。
+
[...] ignore: true [...]
[...]
ignore: true
[...]
2.3.11.3.1. Java プロバイダーでの連鎖 リンクのコピーリンクがクリップボードにコピーされました!
Java
プロバイダーでは、filepaths
変数は大文字にする必要があります。例:
2.3.12. ルールセット リンクのコピーリンクがクリップボードにコピーされました!
ルールセットは、一連のルールで形成されます。MTA では、ルールファイルが必ずルールセットに属する必要はありません。しかし、ルールセットを使用することで、共通の目標を達成する複数のルールをグループ化し、そのルールをルールエンジンに渡すことができます。
ルールセットを作成するには、1 つ以上の YAML ルールをディレクトリーに配置し、そのディレクトリールートに ruleset.yaml
ファイルを作成します。--rules
オプションを使用してこのディレクトリーを MTA CLI への入力として渡すと、このディレクトリー内のすべてのルールは、ruleset.yaml
ファイルで定義されたルールセットの一部として扱われます。
ruleset.yaml
ファイルには、ルールセットのメタデータが保存されます。
name: "Name of the ruleset" description: "Description of the ruleset" labels: # - key=val
name: "Name of the ruleset"
description: "Description of the ruleset"
labels: #
- key=val
アプリケーション分析を実行するには、次のように入力します。
mta-cli analyze --input=<application_to_analyze> --output=<output_dir> --rules=<custom_rule_dir> --enable-default-rulesets=false
$ mta-cli analyze --input=<application_to_analyze> --output=<output_dir> --rules=<custom_rule_dir> --enable-default-rulesets=false
-
<application_to_analyze>
はアプリケーションの名前に置き換えます。 -
<output_dir>
は任意のディレクトリーに置き換えます。 -
<custom_rule_dir>
はカスタムルールセットファイルに置き換えます。
開始時に、mta-cli ツールは分析に必要なアプリケーションの種類とプロバイダーを決定します。次に、必要な依存関係とツールを持つコンテナー内でプロバイダーを起動します。最後に、プロバイダーがアナライザーを使用して一連のルールセットを実行し、ソースコードを分析します。
2.3.13. 基本的な YAML ルールセットのテンプレートを作成する リンクのコピーリンクがクリップボードにコピーされました!
複数の同じようなルールをグループ化する場合は、それらのファイルをディレクトリーに配置し、そのディレクトリーのルートに ruleset.yaml
ファイルを作成することで、それらのルールセットを作成できます。このディレクトリーを、--rules
オプションを使用して MTA CLI への入力として渡すと、MTA はディレクトリー内のすべてのファイルを ruleset.yaml
ファイルで定義されたルールセットに属するものとして処理します。
手順
--rules
オプションを使用してディレクトリー全体を渡す場合は、ruleset.yaml
ファイルのテンプレートを作成します。name: <RULESET_NAME> description: <RULESET_DESCRIPTION> labels: - key=val
name: <RULESET_NAME>
1 description: <RULESET_DESCRIPTION> labels:
2 - key=val
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.14. YAML ルールを作成する リンクのコピーリンクがクリップボードにコピーされました!
各ルールファイルには、1 つ以上の YAML ルールが含まれます。すべてのルールはメタデータ、条件、アクションで構成されています。
手順
when
条件を作成します。YAML ルールの
when
条件には、provider
、and
、or
を指定できます。provider
条件を作成するプロバイダー条件は、特定の言語プロバイダーの検索クエリーを定義し、プロバイダーの特定のケイパビリティーを呼び出すために使用されます。
条件の一般的な形式は
<provider_name>.<capability>
です。条件には、検索の詳細を指定するための内部フィールドもあります。provider
条件とその内部フィールドを作成する方法は、使用するプロバイダーと呼び出すケイパビリティーによって異なります。以下の表は、利用可能なプロバイダーとそのケイパビリティーを示しています。作成するルールの目的に合ったプロバイダーとケイパビリティーを選択してください。条件のこの部分には、条件のフィールドはまだ含まれていません。
Expand プロバイダー 機能 説明 java
referenced
詳細な検索の場合は、オプションのコード位置を指定して、アノテーションを含むパターンの参照を検索します。
dependency
アプリケーションに指定された依存関係があるか確認します。
builtin
xml
XPath クエリーを使用して XML ファイルを検索します。
json
JSONPath クエリーを使用して JSON ファイルを検索します。
filecontent
RegEx パターンを使用して、通常のファイル内のコンテンツを検索します。
file
指定されたパターンに一致する名前を持つファイルを検索します。
hasTags
タグ付けルールを通じてアプリケーション用にタグが作成されているか確認します。
Go
referenced
パターンの参照を検索します。
dependency
アプリケーションに指定された依存関係があるか確認します。
以下の例は、
referenced
ケイパビリティーを使用するjava
プロバイダー条件を示しています。例:
when: java.referenced:
when: java.referenced:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
適切なフィールドを
provider
条件に追加します。以下の表は、利用可能なプロバイダー、そのケイパビリティー、フィールドをすべて示しています。選択したプロバイダーとケイパビリティーに属するフィールドを選択してください。一部のフィールドは必須であることに注意してください。
Expand プロバイダー 機能 フィールド 必須 ? 説明 java
referenced
pattern
はい
RegEx パターン
location
いいえ
ソースコードの場所。サポートされているすべての検索場所のリストは、以下を参照してください。
annotated
いいえ
アノテーションとその要素 (名前と値)
dependency
name
はい
依存関係の名前
nameregex
いいえ
名前と一致する RegEx
upperbound
いいえ
一致するバージョン番号の下限
lowerbound
いいえ
一致するバージョン番号の上限
builtin
xml
xpath
はい
XPath クエリー
namespace
いいえ
クエリーの範囲を名前空間に絞るためのマップ
filepaths
いいえ
検索範囲を絞るためのオプションのファイルリスト
json
xpath
はい
XPath クエリー
filepaths
いいえ
検索範囲を絞るためのオプションのファイルリスト
filecontent
pattern
はい
コンテンツ内で一致する RegEx パターン
filePattern
いいえ
このパターンに一致する名前を持つファイル内のみを検索します。
file
pattern
はい
このパターンに一致する名前を持つファイルを検索します。
hasTags
文字列タグのインラインリストです。タグ形式の詳細は、ルールアクション の タグアクション を参照してください。
Go
referenced
pattern
はい
RegEx パターン
dependency
name
はい
依存関係の名前
nameregex
いいえ
名前と一致する RegEx
upperbound
いいえ
一致するバージョン番号の下限
lowerbound
いいえ
一致するバージョン番号の上限
次の検索場所を使用して、
java
検索の範囲を絞ることができます。- CONSTRUCTOR_CALL
- TYPE
- INHERITANCE
- METHOD_CALL
- ANNOTATION
- IMPLEMENTS_TYPE
- ENUM_CONSTANT
- RETURN_TYPE
- IMPORT
VARIABLE_DECLARATION
以下の例は、パッケージの参照を検索するルールの
when
条件を示しています。例:
when: java.referenced: location: PACKAGE pattern: org.jboss*
when: java.referenced: location: PACKAGE pattern: org.jboss*
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
AND
またはOR
条件を作成します。and
条件は、その子条件が すべて 一致する場合に一致します。次のように、and
条件を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow or
条件は、その子条件の いずれか が一致する場合に一致します。次のように、or
条件を作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.15. カスタム YAML ルールを使用して分析を実行する リンクのコピーリンクがクリップボードにコピーされました!
分析を実行するには、CLI で --rules
オプションを使用します。
手順
単一のルールファイル (
/home/<USER>/rule.yaml
) 内のルールを使用するには、次のコマンドを実行します。mta-cli analyze --input /home/<USER>/data/ --output /home/<USER>/output/ --rules /home/<USER>/rule.yaml
mta-cli analyze --input /home/<USER>/data/ --output /home/<USER>/output/ --rules /home/<USER>/rule.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ここでは、以下のようになります。
-
/home/<USER>/data/
- ソースコードまたはバイナリーのディレクトリー。 -
/home/<USER>/output/
- レポート (HTML および YAML) のディレクトリー
-
-
複数のルールファイルを使用するには、それらのルールファイルをディレクトリーに配置し、
ruleset.yaml
ファイルを追加する必要があります。その後、ディレクトリーは ルールセット として扱われ、--rules
オプションに入力として渡すことができます。
CLI で --target
または --source
オプションを使用する場合、エンジンはそのターゲットのラベルに一致するルールのみを選択することに注意してください。そのため、ルールにターゲットラベルまたはソースラベルが追加されていることを確認する必要があります。詳細は、予約済みラベル を参照してください。