6.1.1. Global Options

These options affect all rules in this aspect.

6.1.1.1. advanced

Options that are normally not required
 

advanced.check_installation_integrity : bool = True

Sets whether the Axivion installation integrity check should be executed at the beginning of each CI execution. You may disable it for performance reasons, but have to enable it prior to sending build logs to Axivion support.
 

advanced.multi_binary : bool = False

If multi_binary is set to true, the corresponding switch is set for the Axivion linker calls and the environment variable CAFECC_STATIC_PART will be set to true for every build step.
 

6.1.1.2. ci_mode

Configure the build and analysis of the project.

A CI build will
  1. clean the workspace (optional, can be disabled)
  2. update your working copy (optional, can be enabled)
  3. build
  4. run the analysis
  5. import data into dashboard database
  6. clean the workspace (optional, can be disabled)
 

ci_mode.clean_after : bool = True

Whether the build system should be used with the clean_target to clean up the directories after the CI.
 

ci_mode.clean_before : bool = True

Whether the build system should be used with the clean_target to clean up the directories before starting the new build.
 

ci_mode.update_workspace : bool = False

When true, VCS updates to the workspace are being done, otherwise the workspace is assumed to be already updated and the option workspace_date can be used to define the date of the workspace.
 

ci_mode.version_name : str = '$(AXIVION_VERSION_NAME=)'

Optional symbolic name of the analyzed version, i.e. something like "Release 1.0" or "Milestone 7", etc. This symbolic name is not used for lookups in the VCS, it is just informational, but can be used to identify a reference version for the local build. The symbolic name is e.g. used in the dashboard UI.
 

ci_mode.workspace_date : bauhaus.analysis.config.Date | None = '$(AXIVION_WORKSPACE_DATE=)'

When specified, taken as the ISO date of the version to analyse (either updating the workspace to that version or leaving it alone, depending on whether the "update_workspace" step is selected). If empty or unset, the current time at analysis start is being taken.
 

6.1.1.3. directory

directory : bauhaus.analysis.config.LayerRelativePath = 'None (value must be set)'

Base directory for all operations. For files within this directory, the IR, RFG, and dashboard will use relative paths. For files outside this directory, absolute paths will be used.

This option should usually be set to the root directory of your source code checkout, so that all source code files are contained within the base directory.

Note that many other options in the configuration system are interpreted relative to this base directory, so changing this option may require adjustments to other options you have already configured.

Environment variable CAFECC_BASEPATH is set to the value of this option. This ensures that for any IR built from within the BuildSystemIntegration, cafeCC is aware of the base path and can store relative paths in the IR. If you build the IR separately from axivion_ci, you have to manually set CAFECC_BASEPATH to this project directory. If you use a build system that does not pass host environment variables to the build steps, you can also use the cafeCC -B command-line option to explicitly pass the base directory to cafeCC, but whenever possible, we recommend to use the environment variable CAFECC_BASEPATH instead.

 

6.1.1.4. ir

ir : bauhaus.analysis.config.ProjectRelativePath | None = None

Name of the Axivion IR file produced by the build. This file is then analysed. For an invocation of axivion_ci, this option is required if at least one analysis rule that requires the IR is selected.
 

6.1.1.5. local_mode

Configure the build and analysis of the project locally, compare to remote reference version.

A local build will
  1. download the reference version from dashboard
  2. clean the workspace (optional, can be enabled)
  3. build
  4. run the analysis
  5. import data into local database
  6. clean the workspace (optional, can be enabled)
 

local_mode.clean_after : bool = False

Whether the build system should be used with the clean_target to clean up the directories after the CI.
 

local_mode.clean_before : bool = '$(AXIVION_CLEAN_BUILD=false)'

Whether the build system should be used with the clean_target to clean up the directories before starting the new build.
 

local_mode.reference_version

The reference version to download from the dashboard.
 

local_mode.reference_version.reference_date : bauhaus.analysis.config.Date | None = '$(AXIVION_REFERENCE_DATE=)'

The reference analysis version to download from the dashboard as ISO timestamp. If empty or unset, the latest version of the project matching version_name_filter is taken.
 

local_mode.reference_version.version_name_filter : bauhaus.analysis.config.GlobPattern = '$(AXIVION_VERSION_NAME_FILTER=*)'

If reference_date is not configured, the latest version of the project matching the version_name_filter globbing pattern is used as reference version.

Configuring reference_date to be unspecified and version_name_filter to "*" will result in the latest version in the database being used as reference version.

 

6.1.1.6. name

name : str | None = None

The name of the project. If unset, this will default to the basename of the resolved directory.

 

6.1.1.7. rfg

rfg : bauhaus.analysis.config.ProjectRelativePath | None = None

Name of the Axivion RFG file used for higher-level analyses. If this option is not specified, the RFG will automatically be created from the IR if necessary.

Note that specifying this option suppresses the automatic creation of the RFG: if this option is specified, the RFG must be created by one of the build steps (BuildSystemIntegration) and will not be created by Architecture-Dependencies.

This option is intended to be used for analyses where no IR exists (e.g. C# with AxivionC#Frontend) and should normally not be used for C/C++ analysis.

If you wish to save the automatically created RFG, use the option /Analysis/AnalysisControl/SaveRFG/rfg_file instead.