Native mode
By default, Qodana runs its linters using Docker based on Linux images. In specific cases, you have to deal with private packages or run Qodana on the operating systems that provide incomplete support for Docker.
To overcome this, Qodana supports the native mode for the Qodana for .NET linter. In this case, Qodana reuses its execution environment, which lets you execute Qodana in exactly the same environment as you use for building the projects, use the correct operating system, have access to all repository credentials, and resolve dependencies.
note
The native mode is incompatible with Docker containers of Qodana, which means that you run the Qodana for .NET linter either as a Docker container or in a native mode.
Make sure that you have a proper version of the .NET SDK and all required dependencies installed on your machine.
Build the project before inspecting it using Qodana. You can do it by using the bootstrap key of the qodana.yaml file.
The project building and artifact packaging stages should occur before Qodana or simultaneously with it. Because running Qodana may affect the project state and its files, we recommend that you avoid reusing the same directory in your build pipelines any further.
You can also provide Qodana with a pre-built project, or specify the build steps in your CI/CD pipeline. In this case, in your repository create the empty qodana.yaml file to eliminate warnings related to project building.
In your operating system, save the QODANA_TOKEN environment variable containing the Qodana Cloud project token.
Install Qodana CLI on the machine where you plan to run Qodana locally.
Starting from the version 2023.3 of Qodana, the sanity inspection will report in case the qodana.yaml file containing the bootstrap key is missing in your project directory. The bootstrap key should contain instructions for building the project. If you do not wish to build the project, disable this inspection using the --disable-sanity option, add this inspection to a baseline, or create the qodana.yaml file that will contain the ide: QDNET configuration.
We recommend running the native mode on the same machine where you build a project because this can guarantee that Qodana has access to private NuGet feeds.
note
The native mode is incompatible with several Docker image-related options like
-l, --linter,-e, --env, and-v, --volume.
You can enable the native mode ba saving this configuration in the qodana.yaml file:
ide: QDNETThis configuration tells Qodana to download and employ the required JetBrains IDE binary file while running.
Below are the examples showing how you can run Qodana in the native mode:
Make sure that the
QODANA_TOKENvariable is defined in the environment and refers to a proper project token. If necessary, you can define it:$QODANA_TOKEN=<cloud-project-token>If you have already enabled the native mode using the
qodana.yamlfile, use this command:$qodana scanYou can also run Qodana without configuring the
qodana.yamlfile:$qodana scan \ --ide QDNET
If you have already enabled the native mode using the qodana.yaml file, you can use a basic configuration sample from the GitHub Actions section.
To run Qodana without configuring the qodana.yaml file, in your GitHub repository navigate to a workflow configuration file and specify the --ide,QDNET option:
name: Qodana
on:
workflow_dispatch:
pull_request:
push:
branches:
- master
- '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@v2024.1
with:
args: --ide,QDNET
env:
QODANA_TOKEN: ${{ secrets.QODANA_TOKEN }}Thanks for your feedback!