How do I match inspection profiles between IntelliJ Qodana local plugin and Qodana run by my Github action ?

[GaryRoussak]

I have a Java project with CI/CD controlled by Github workflow actions.

When I've finished a set of source changes in IntelliJ, I know how to run my locally installed Qodana plugin. The scan results it gives me are clearly based on the qodana.yaml file that I was asked to use in the root of my project and, rightly or wrongly, this is what it contains:

#-------------------------------------------------------------------------------#
#               Qodana analysis is configured by qodana.yaml file               #
#             https://www.jetbrains.com/help/qodana/qodana-yaml.html            #
#-------------------------------------------------------------------------------#
version: "1.0"

#Specify inspection profile for code analysis
profile:
  name: qodana.starter

#Enable inspections
include:
  - name: CheckDependencyLicenses
#  - name: <SomeEnabledInspectionId>

#Disable inspections
#exclude:
#  - name: <SomeDisabledInspectionId>
#    paths:
#      - <path/where/not/run/inspection>


projectJDK: "8" #(Applied in CI/CD pipeline)

#Execute shell command before Qodana execution (Applied in CI/CD pipeline)
#bootstrap: sh ./prepare-qodana.sh

#Install IDE plugins before Qodana execution (Applied in CI/CD pipeline)
#plugins:
#  - id: <plugin.id> #(plugin id can be found at https://plugins.jetbrains.com)

#Specify Qodana linter for analysis (Applied in CI/CD pipeline)
linter: jetbrains/qodana-jvm:2024.3

exclude:
  - name: All
    paths:
      - build.gradle.kts
      - settings.gradle.kts
      - frStationBuilder/frStationBuilder-wb/frStationBuilder-wb.gradle.kts
      - frStationBuilder/frStationBuilder-ux/frStationBuilder-ux.gradle.kts
      - frStationBuilder/frStationBuilder-rt/frStationBuilder-rt.gradle.kts

It gives me a set of 17 warnings.

Okay - I now push the project to Github, including the same qodana.yaml file. I then run a Github workflow action on my branch to do a Qodana scan. As a result, I get 66 warnings - not the 17 I got locally from the IntelliJ plugin. Once I resolve the 17 errors that the local plugin shows me, the Github Qodana report reduces from 66 errors to 49, almost all of which are "Unresolved reference" to classes in the third-party Java framework which the project relies on (Tridium Niagara).

I totally admit I'm new to Qodana and have valiantly tried to research why this is happening, but I don't understand why the local scan is now showing no warnings whereas the Github Qodana action is showing the unresolved references.

I am presuming this is a configuration issue on my part, but I don't understand how to fix it. Can anyone help ?

Here is my Github action workflow file, in case it helps:

name: Qodana
run-name: frStationBuilder Qodana Scan - ${{ github.event_name }} on branch ${{ github.ref_name }} 🚀

on:
  workflow_dispatch:
  pull_request:
  push:
    branches:
      - master
      - develop

jobs:
  qodana:
    runs-on: [self-hosted, org]
    permissions:
      contents: write
      pull-requests: write
      checks: write
    steps:
      - uses: actions/checkout@v4
        with:
          path: qodana
          ref: ${{ github.event.pull_request.head.sha }}  # to check out the actual pull request commit, not the merge commit
          fetch-depth: 0  # a full history is required for pull request analysis
      - name: Create gradle properties
        working-directory: ./qodana
        run: cp ./.github/qodana/gradle-qodana-template.properties gradle.properties
      - name: 'Qodana Scan'
        working-directory: ./qodana
        run: qodana scan `
          -e _JAVA_OPTIONS=-Xmx8g `
          -v C:/Niagara/Niagara-4.14.0.162/etc/m2/repository:/Niagara/Niagara-4.14.0.162/etc/m2/repository `
          -v C:/Niagara/Niagara-4.12.2.16-Qodana:/Niagara/Niagara-4.12.2.16 `
          -v C:/Users/niagara-agent-001/Niagara4.12/tridium:/Users/niagara-agent-001/Niagara4.12/tridium `
          -e QODANA_TOKEN=${{ secrets.QODANA_TOKEN }} `
          --baseline qodana.sarif.json

[brichbash]

Hello,

Do you use a self-hosted agent?
Also, is there any particular reason why you're running Qodana CLI directly instead of using our action?

Qodana report reduces from 66 errors to 49, almost all of which are "Unresolved reference" to classes in the third-party Java framework which the project relies on (Tridium Niagara).

I am not familiar with the framework, but if IntelliJ provides results different from Qodana and they are more accurate, I'd first start with comparing your IDE and Qodana configuration. You see, when running Qodana from a IntelliJ IDE, it reuses your project configuration that was generated/set up by you when you opened the project in IDEA. All of the project configuration files are stored under .idea in your project root, and Qodana on GitHub can also use the same config files if they are present before the analysis.

Besides, in your current config you're mounting paths to /Niagara/** or /Users/** which are unknown to Qodana. For example, by default the local Maven repository in the Qodana docker image is located in /data/cache/.m2, so your mountings don't affect the analysis at all

[GaryRoussak]

@brichbash

Firstly, very many thanks for taking the time to look at this and giving me a response.

Yes, the Github CI/CD is on a self-hosted build runner VM using Docker.

The reason why we switched to Qodana CLI in that environment is down to an explanation given to me my one of my colleagues: the original script to do the Qodana scan was using a Qodana action (2024.1, I believe), but we were getting errors about it being unsupported. Unfortunately, my colleague doesn't have the actual error to give you, but he does have a copy of the original script he was using, so one option here is for us to bring that script up to date (2025.3), run it again, and see what the results are. If there's still an issue at that point, perhaps we can post that for you to take a look ?

I'm getting the drift of the rest of your explanation about configuration, so it sounds like there may well be some extra work for us to do there as well.

I'm on holiday for a couple of weeks or so now, so I'll look into all of this when I'm back. In the meantime, appreciate your help so far.