YAML ファイル

デフォルトでは、Qodana はプロジェクトのルートディレクトリに含まれる qodana.yaml ファイルから構成を読み取ります。--config オプションを使用してこのファイル名を上書きできます。カスタム構成ファイルセクションを参照してください。便宜上、このセクションではデフォルトの qodana.yaml 名を使用して参照します。

qodana.yaml で適用された構成は、デフォルトのインスペクションプロファイル設定と Qodana リンターのデフォルト構成を上書きします。これは HTML レポートセクションを使用して構成でき、すべての変更が自動的に適用されます。

qodana.yaml の JSON スキーマは、IDE での補完と基本的な検証を提供する SchemaStore(英語) プロジェクトで公開されています。

このカスタマイズした設定で後続の解析を実行するには、ファイルをプロジェクトのルートディレクトリに保存してください。または、qodana.yaml 設定ファイルを直接編集することもできます。このセクションでは、必要な設定手順について説明します。

カスタムコマンドを実行する

解析中に、Qodana リンターは、JVM、.NET、Golang に関連するリンターがビルドシステムとプロジェクト構造を自動的に把握しようと試みるにもかかわらず、一部のインスペクションがクラス、パッケージ、ファイルを見つけられない、参照を解決できないと報告する場合があります。このような場合、Qodana には少し手サポートが必要です。

サードパーティのパッケージまたはライブラリをインストールする
ビルド環境をセットアップするプログラムを実行する

これらの操作は bootstrap キーを使用して実行されます。

bootstrap: |+
  set -eu
  # For PHP projects that use Laravel:
  #composer require --dev barryvdh/laravel-ide-helper

  # For JavaScript projects that use Node.js:
  #npm install

  # For Python projects
  #pip install -r requirements.txt 

IDE で構文のハイライトと検証を使用できるようにするには、prepare-qodana.sh シェルスクリプトを作成し、プロジェクトのルートディレクトリに保存します。

#! /bin/sh

set -eu

# For PHP projects that use Laravel:
#composer require --dev barryvdh/laravel-ide-helper

# For JavaScript projects that use Node.js:
#npm install

bootstrap キーを使用して、Qodana Docker コンテナーでスクリプトを実行します。

bootstrap: sh ./prepare-qodana.sh

Qodana を root ユーザーとして実行するには、--user=root オプションを呼び出す必要がある場合があります。

プロファイルを設定する

既存の Qodana プロファイルに関する情報は、既存の Qodana プロファイルセクションで入手できます。

profile キーを使用して、Qodana インスペクションプロファイルを設定できます。例:

profile:
    inspections:
        - group: "category:Java/Probable bugs"
          enabled: true

        - inspection: RedundantIf
          enabled: true

利用可能な構成オプションに関する情報は、カスタムプロファイルセクションで参照できます。

パスを分析範囲から除外する

解析ごとにファイルとパスを除外することも、すべてのインスペクションを一括で除外することもできます。インスペクション ID に関する情報は、Inspectopedia(英語)Web サイトでご覧いただけます。

プロジェクト内のすべてのパスを分析範囲から除外するには、paths ノードを省略します。

サンプル

指定されたプロジェクトパスのすべてのインスペクションを除外します。

exclude:
  - name: All
    paths:
      - asm-test/src/main/java/org
      - asm/Visitor.java
      - benchmarks

指定されたプロジェクトパスの ID で指定されたインスペクションを除外します。

exclude:
  - name: Annotator
  - name: AnotherInspectionId
    paths:
      - relative/path
      - another/relative/path
  - name: All
    paths:
      - asm-test/src/main/java/org
      - asm
      - benchmarks
      - tools

特定のインスペクション ID は、HTML レポートのプロファイル設定、またはインスペクションプロファイルを含む .xml ファイルで見つけることができます。

解析範囲にインスペクションを含める

選択したプロファイルに含まれていないインスペクションを使用して、特定のディレクトリのファイルを Qodana に解析するよう指示できます。これは解析ごとに実行できます。プロジェクト内のすべてのパスをインスペクションのスコープに含めるには、paths ノードを省略します。インスペクション ID に関する情報は、Inspectopedia(英語) の Web サイトで入手できます。

サンプル

この例では、インスペクションを含まない empty プロファイルが指定されており、SomeInspectionId インスペクションが tools ディレクトリの分析範囲に明示的に含まれています。その結果、SomeInspectionId インスペクションによって実行されるチェック、tools ディレクトリの内容のみが Qodana の実行に含まれます。

  profile:
  name: empty
include:
  - name: SomeInspectionId
    paths:
    - tools

特定のファイルに対して特定のインスペクションを無効にする

特定のファイルに対してインスペクションを無効にするには、次の構成を含む qodana.yaml ファイルをプロジェクトルートに保存します。

    exclude:
      - name: <inspection-name>
    paths:
      - <path/to/the/file/from/project/root>

クラスの上に noinspection コメントを追加することで、クラスに対してのみインスペクションを抑制することもできます。

    // noinspection <inspection-name>
    export class WorkflowJobSubject {
        private static subject: Observable<GithubEvent<WorkflowJobEvent>> | null =
            null;
    private static GithubWebhookEventSubject: any;

品質ゲートを設定する

品質ゲートを構成するには、いくつかのオプションがあります。

失敗しきい値を追加して、プロジェクト内の問題の合計数を制御できます。これはすべてのリンターによってサポートされています。

failThreshold: <number>

.NET の Qodana コミュニティと C/C++ のための Qodana コミュニティを除くすべてのリンターでは、次の構成を使用できます。

failureConditions:
  severityThresholds:
    any: <number> # Total problems
    critical: <number> # Critical and other severities
    high: <number>
    moderate: <number>
    low: <number>
    info: <number>
  testCoverageThresholds:
    fresh: <number> # Fresh code coverage
    total: <number> # Total code coverage

この構成では、設定制限を 1 つだけ超えるとビルドが失敗します。

severityThresholds:any オプションを使用すると、問題の総数を構成できます。severityThresholds:critical などのオプションを使用すると、問題の重大度ごとに品質ゲートを構成できます。testCoverageThresholds:fresh および testCoverageThresholds:total オプションを使用すると、複数のリンターでサポートされる合計コードカバレッジと新しいコードカバレッジを構成できます。

デフォルトの実行シナリオをオーバーライドする

script:
  name: <script-name>
  parameters:
      <parameter>: <value>

標準の Qodana 動作をオーバーライドできます。これは PHP バージョンの移行の場合に役立ちます。この観点からコードを分析するには、php-migration シナリオを実行してください。

デフォルトでは、Qodana は default シナリオを採用します。これは、通常の Qodana がこの設定と同等に実行されることを意味します。

script:
  name: default

さまざまな構成オプションの例

version: 1.0
failThreshold: 0
profile:
  name: qodana.recommended
include:
  - name: SomeInspectionId
exclude:
  - name: Annotator
  - name: AnotherInspectionId
    paths:
      - relative/path
      - another/relative/path
  - name: All
    paths:
      - asm-test/src/main/java/org
      - benchmarks
      - tools

上の例

SomeInspectionId インスペクションは、プロファイルでは無効になっていますが、すべてのパスに対して明示的に有効になっています
Annotator インスペクションはすべてのパスで無効になります
AnotherInspectionId インスペクションは relative/path および another/relative/path では無効です
これらのパスではインスペクションは実行されません: asm-test/src/main/java/org、benchmarks、tools

リンターを指定する

linter オプションを使用すると、使用するリンターを指定できます。例:

linter: qodana-jvm-android

プロジェクト内のディレクトリを指定する

onlyDirectory オプションを使用して、プロジェクト内の解析対象ディレクトリを指定します。これはプロジェクトルートからの相対パスで指定する必要があります。例:

onlyDirectory: project-a

これは、モノレポプロジェクトを分析するときに役立ちます。

JDK のバージョンを設定する

これらのリンターの JDK バージョンを構成できます。

projectJDK オプションを使用して、JDK バージョンを指定します。例:

projectJDK: 11

または:

projectJDK: 1.8

次の名前を使用して JDK を指定することもできます。

projectJDK: corretto-19

JDK の構成の詳細については、「JDK の設定」セクションを参照してください。

PHP のバージョンを設定する

PHP 用の Qodana リンターを実行する前に、PHP バージョンを構成できます。

php:
  version: "X.x"

健全性チェックを無効にする

デフォルトでは、Qodana では健全性チェックが有効になっています。次のスニペットを使用して無効にできます。

disableSanityInspections: true

ライセンス監査を構成する

Qodana のバージョン 2024.1 以降では、ライセンス監査機能がデフォルトで有効になっています。 CheckDependencyLicenses (英語) インスペクションを除外することで、この機能を無効にできます。

exclude:
  - name: CheckDependencyLicenses

依存関係を無視する

依存関係を無視して、関連する問題をレポートから非表示にします。

dependencyIgnores:
  - name: "enry"

ここで、name は無視する依存関係の名前です。

上の例では、enry 依存関係が分析から完全に除外されています。考えられるライセンス関連の問題は無視されるため、依存関係はレポートにまったく含まれません。これは、レポートでメンションする必要のない内部依存関係をすばやく非表示にできます。

ライセンスを許可または禁止する

事前定義されたライセンス互換性マトリックスをオーバーライドします。

licenseRules:
  - keys:
      - "PROPRIETARY-LICENSE"
      - "MIT"
    prohibited:
      - "BSD-3-CLAUSE-NO-CHANGE"
    allowed:
      - "ISC"

  - keys: [ "Apache-2.0" ]
    prohibited:
      - "MIT"

この構成では、keys はプロジェクトライセンスであり、依存ライセンスの識別子は allowed または prohibited で指定されます。

依存関係ライセンスをオーバーライドする

依存関係ライセンス識別子をオーバーライドします。

dependencyOverrides:
  - name: "jaxb-runtime"
    version: "2.3.1"
    url: "https://github.com/javaee/jaxb-v2"
    licenses:
      - key: "CDDL-1.1"
        url: "https://github.com/javaee/jaxb-v2/blob/master/LICENSE"
      - key: "GPL-2.0-with-classpath-exception"
        url: "https://github.com/javaee/jaxb-v2/blob/master/LICENSE"

ここで、name は依存関係の名前、version は依存関係のバージョン、licenses は再定義された依存関係ライセンスのリストです。

上の例では、CDDL-1.1、クラスパス例外付きの GPL-2.0 を検出し、jaxb-runtime の他のライセンス (2.3.1 のみ) を検出しないように Qodana に「指示」しています。これは、依存関係がデュアルライセンスであり、一部のライセンスを省略したい場合、依存関係ソースからライセンスを正しく検出できない場合に便利です。

カスタム依存関係

現在、Qodana によるライセンス監査は、JPS、Maven、Gradle、npm、yarn、composer プロジェクトでのみ可能です。レポートに記載する必要があるがプロジェクトソースからは検出できない依存関係を含めるには、customDependencies を使用して指定します。

customDependencies:
  - name: ".babelrc JSON Schema (.babelrc-schema.json)"
    version: "JSON schema for Babel 6+ configuration files"
    licenses:
      - key: "Apache-2.0"
        url: "https://github.com/SchemaStore/schemastore/blob/master/LICENSE"

クイックフィックスを構成する

fixesStrategy オプションを使用すると、利用可能なクイックフィックス戦略の中から選択できます。

fixesStrategy: cleanup/apply

汚染分析を構成する

qodana.yaml ファイルにおいて、 PhpVulnerablePathsInspection (英語) インスペクションを解析範囲に含める。

  include:
    - name: PhpVulnerablePathsInspection
  

qodana.yaml ファイルで、JvmTaintAnalysis インスペクションを分析範囲に含めます。

  include:
    - name: JvmTaintAnalysis
  

脆弱性チェッカーを構成する

脆弱性チェッカー機能の使用を開始するには、 VulnerableLibrariesGlobal (英語) インスペクションを有効にしてください。

include:
  - name: VulnerableLibrariesLocal

プラグインの管理

インスペクション中にダウンロードして呼び出すプラグインを指定できます。

plugins:
  - id: <plugin.id>

ここで、<plugin-id> は JetBrains マーケットプレイス(英語)のプラグイン ID を表します。例: Grazie Professional(英語) の場合、プラグイン ID は com.intellij.grazie.pro になります。プラグイン ID を見つけるには、プラグインページで概要タブをクリックし、追加情報セクションに移動します。

プラグインキャッシュは /data/cache/plugins ディレクトリに保存されます。

プラグインに必要なサードパーティソフトウェアをインストールするには、次の方法があります。

bootstrap キーを使用します。
FROM jetbrains/qodana... で始まるカスタム Dockerfile を開発します。GitHub(英語) で利用可能な Qodana Dockerfile の例を使用できます。

不適切な書式インスペクション

IncorrectFormatting (英語) インスペクションは、ファイルに含まれる複数のフォーマットエラーを、個別に表示するのではなく、1 つの問題として統合します。ファイルごとに 1 つの問題がサンプルスニペットとともに表示されるため、問題をより迅速に解決できます。

この機能は、C/C++ 用の Qodana、C/C++ 用の Qodana Community、および .NET 用の Qodana Community を除くすべてのリンターで使用できます。

使用を開始するには、Qodana インスペクションプロファイル構成で IncorrectFormatting (英語) インスペクションを有効にします。例:

include:
  - name: IncorrectFormatting

CMake プリセットを指定する

CMake プリセットを使用して、Qodana を C/C++ リンター用にカスタマイズします。cpp および cmakePreset オプションを使用してプリセットを呼び出します。

cpp:
  cmakePreset: my-qodana-preset

ネイティブモードを構成する

リンターを指定して withinDocker オプションを false に設定することで、ネイティブモードを構成できます。例:

linter: qodana-dotnet
withinDocker: false

ネイティブモードは現在、次の Qodana リンターで利用できます。

リンター名	説明
`qodana-jvm`	JVM 用 Qodana
`qodana-jvm-community`	JVM の Qodana コミュニティ
`qodana-php`	PHP 用の Qodana
`qodana-js`	JS 用 Qodana
`qodana-dotnet`	.NET 用 Qodana
`qodana-go`	Go 用 Qodana
`qodana-python`	Python 用 Qodana
`qodana-python-community`	Python のための Qodana コミュニティ

モノレポで Java および Kotlin プロジェクトを構成する

rootJavaProjects キーを使用すると、分析に含めるプロジェクトを指定できます。例:

rootJavaProjects:
- "./gradleProject"
- "./mavenModule/pom.xml"

デフォルトでは、Qodana はサブディレクトリからプロジェクトを再帰的に収集し、分析のためにインポートします。この変更により、増分分析が可能になり、分析対象プロジェクトと VCS ルートが異なるプロジェクトでも修正が行われます。

2026 年 4 月 16 日

Qodana 2026.1 ヘルプ

YAML ファイル

カスタムコマンドを実行する

プロファイルを設定する

パスを分析範囲から除外する

サンプル

解析範囲にインスペクションを含める

サンプル

特定のファイルに対して特定のインスペクションを無効にする

品質ゲートを設定する

デフォルトの実行シナリオをオーバーライドする

さまざまな構成オプションの例

リンターを指定する

プロジェクト内のディレクトリを指定する

JDK のバージョンを設定する

PHP のバージョンを設定する

健全性チェックを無効にする

ライセンス監査を構成する

依存関係を無視する

ライセンスを許可または禁止する

依存関係ライセンスをオーバーライドする

カスタム依存関係

クイックフィックスを構成する

汚染分析を構成する

脆弱性チェッカーを構成する

プラグインの管理

不適切な書式インスペクション

CMake プリセットを指定する

ネイティブモードを構成する

モノレポで Java および Kotlin プロジェクトを構成する

関連ページ：