Troubleshooting
This section contains information that can help you troubleshoot common problems.
Path | Description |
---|---|
| Root directory of the project to be analyzed |
| Directory to store the analysis results |
| Directory containing the IDE distribution |
| Directory where the IDE contains configuration |
| Used if a profile was not previously configured either via the CLI or the |
For Maven and Gradle projects, Qodana uses the following directories to access third-party libraries:
Path | Description |
---|---|
| Maven project dependencies |
| Gradle project dependencies |
Mounting these directories saves Qodana from downloading all dependencies again while using these linters:
There are several options for examining Qodana behavior using the /data/results
directory:
The
/data/results/projectStructure/Modules.json
file lists all modules detected by Qodana. It should be identical to the list that you expect to see while opening the project in IDEA. If it is not the case, checkpom.xml
for Maven or thebuild.gradle
file for Gradle configurations.In the
/data/results/
directory, each inspection that detected a possible problem creates its own file namedID.json
, whereID
is the inspection name that can be used inqodana.yaml
for including or excluding inspections. You can find the complete list of inspection IDs in the/data/results/.descriptions.json
file using the/groups/*/inspections/*/shortName
pattern.In
/data/results/log/idea.log
, you can investigate suspicious warnings.
A typical project structure can have a directory structure similar to this:
repo/
.git/
project/
...
Here, the repo/.git
directory contains information that should be accessible by Qodana, and the repo/project
directory contains the project that needs to be inspected by Qodana. All these samples mount the repo/project
directory using the --project-dir
option, while the QODANA_TOKEN
variable refers to the Qodana Cloud project token:
$docker run \ -v repo/:/data/project/ \ -e QODANA_TOKEN="<cloud-project-token>" \ jetbrains/qodana-<linter> \ --project-dir=/data/project/project/
$qodana scan \ -e QODANA_TOKEN="<cloud-project-token>" \ --project-dir=/data/project/project/
name: Qodana
on:
workflow_dispatch:
pull_request:
push:
branches:
- main
- 'releases/*'
jobs:
qodana:
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
checks: write
steps:
- uses: actions/checkout@v3
with:
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: 'Qodana Scan'
uses: JetBrains/qodana-action@v2023.2
with:
args: --project-dir,project
env:
QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}
During inspections, Qodana may report about missing files, packages, modules, or classes. In this case, you need to have your project prepared for code inspection. For example, you can create a script and configure Qodana for running it as shown in the Prepare your project section.
To disable inspections for a specific file, in the project root save the qodana.yaml
file containing this configuration:
exclude:
- name: <inspection-name>
paths:
- <path/to/the/file/from/project/root>
You can also suppress the inspection only for a class by adding the noinspection
comment above the class:
// noinspection <inspection-name>
export class WorkflowJobSubject {
private static subject: Observable<GithubEvent<WorkflowJobEvent>> | null =
null;
private static GithubWebhookEventSubject: any;
Thanks for your feedback!