recordCoverage: Record code coverage results

• checksAnnotationScope (optional)
  Select the scope of source code annotations in SCM checks. The following different scopes are supported:

  SKIP - Skip annotations

  Do not publish any annotations, just report the coverage report summary.

  MODIFIED_LINES - Publish annotations for modified lines

  Publish only annotations for lines that have been changed (with respect to the reference build). Teams can use these annotations to improve the quality of pull or merge requests.

  ALL_LINES - Publish annotations for all lines

  Publish annotations for existing and new code. There might be a lot of annotations depending on your code coverage.

  • Values: SKIP, MODIFIED_LINES, ALL_LINES
• checksName : String (optional)
  If provided, and publishing checks enabled, the plugin will use this name when publishing results to corresponding SCM hosting platforms. If not, the default name will be used.
• enabledForFailure : boolean (optional)
  This toggle determines if recording of code coverage results should be enabled for failed builds as well. By default, code coverage results are only recorded for stable or unstable builds, but not for failed builds: code coverage results might be inaccurate if the build failed.
• failOnError : boolean (optional)
  This toggle determines if the coverage plugin should fail the step whenever an error occurred during processing of the coverage results. Several errors might occur: file pattern matches no files, source files could not be copied, etc. By default, these errors are logged in a separate view but the build status will not be altered. If you would rather like to fail the step on such errors, please tick this checkbox.
• id : String (optional)
  You can override the default ID (i.e., URL) that is used to publish the coverage results in this job. This ID is used as link to the results, so choose a short and meaningful name. Allowed elements are characters, digits, dashes and underscores (more precisely, the ID must match the regular expression \p{Alnum}[\p{Alnum}-_]*). The chosen ID must be unique in a job, i.e., it must not be already used by other results. If you leave the ID field empty, then the built-in default ID "coverage" will be used to show the results.
• ignoreParsingErrors : boolean (optional)
  This toggle determines if the coverage plugin should ignore parsing errors during processing of the coverage reports or if it should fail fast with an exception. By default, this toggle is disabled and the parsers will fail fast. This helps to identify bugs in the parser or in the coverage tool execution. If you would rather like to ignore parsing errors, please tick this checkbox. Please note that in this case the parser results might be incomplete or even wrong.
• name : String (optional)
  You can override the display name of the coverage results. This name is used in details views, trend captions, hyperlinks, and checks titles. If you leave the name field empty, then the built-in default name "Coverage Results" will be used.
• qualityGates (optional)
  Add one or more quality gates that will be checked right after the build. You can define for each quality gate which metric and baseline will be used to select the value that will be compared with the threshold.
  Array / List of Nested Object
  • threshold : double
    The threshold defines the minimum or maximum value (depends on the metric) of a coverage metric that is required to pass or miss the quality gate.
  • metric
    Select the metric that should be evaluated for this quality gate. The following different metrics are supported:

    MODULE

    Covered and missed modules (given as percentage)

    PACKAGE

    Covered and missed packages; also used for namespaces or directories (given as percentage)

    FILE

    Covered and missed files (given as percentage)

    CLASS

    Covered and missed classes (given as percentage)

    METHOD

    Covered and missed methods (given as percentage)

    LINE

    Line coverage (given as percentage)

    INSTRUCTION

    Instruction coverage (given as percentage)

    BRANCH

    Branch coverage or decision coverage (given as percentage)

    MUTATION

    Mutation coverage (given as percentage)

    TEST_STRENGTH

    Test Strength (given as percentage)

    COMPLEXITY

    Cyclomatic complexity (given as absolute number)

    COMPLEXITY_DENSITY

    Cyclomatic complexity density (given as relation between cyclomatic complexity and lines of code)

    COMPLEXITY_MAXIMUM

    Maximum cyclomatic complexity of all methods (given as absolute number)

    LOC

    Lines of code (given as absolute number)

    TESTS

    Number of tests (given as absolute number)

    • Values: CONTAINER, MODULE, PACKAGE, FILE, CLASS, METHOD, LINE, BRANCH, INSTRUCTION, MUTATION, TEST_STRENGTH, COMPLEXITY, COMPLEXITY_MAXIMUM, COMPLEXITY_DENSITY, LOC, TESTS
  • baseline (optional)
    Select the baseline to be used for the code coverage computation of this quality gate. The following different baselines are supported:

    Overall project - PROJECT

    Coverage of the whole project. This is an absolute value that might not change much from build to build.

    Overall project (difference to reference job) - PROJECT_DELTA

    Difference between the project coverages of the current build and the reference build. Teams can use this delta value to ensure that the overall project coverage will not decrease.

    Modified files - MODIFIED_FILES

    Coverage of the modified files (e.g., within the files that have been touched in a pull or merge request) will focus on new or modified files only.

    Modified files (difference to reference job) - MODIFIED_FILES_DELTA

    Difference between the file coverages of the current build and the reference build. Teams can use this delta value to ensure that the overall coverage of all modified files will not decrease. This also implies that the overall project coverage will not decrease, making this metric stricter than the PROJECT_DELTA metric

    Modified code lines - MODIFIED_LINES

    Coverage of the modified lines (e.g., within the modified lines of a pull or merge request) will focus on new or modified code only.

    Modified code lines (difference to modified files) - MODIFIED_LINES_DELTA

    Difference between the coverages of the modified lines and the modified files of the current build. Teams can use this delta value to ensure that the coverage of pull requests is better than the existing coverage of the modified files.

    • Values: PROJECT, PROJECT_DELTA, MODIFIED_LINES, MODIFIED_LINES_DELTA, MODIFIED_FILES, MODIFIED_FILES_DELTA, INDIRECT
  • criticality (optional)
    When a quality gate has been missed, this property determines whether the result of the associated coverage stage will be marked as unstable or failure. The following two enum values are possible:

    UNSTABLE

    Set the build status to unstable if the quality gate has been missed.

    FAILURE

    Fail the step if the quality gate has been missed.

    • Values: UNSTABLE, FAILURE
• scm : String (optional)
  Specify the key of your repository (substring is sufficient) if you are using multiple SCMs in your job. When your job is composed of several SCM checkouts (modules, pipeline libraries, etc.) then Jenkins stores all those repositories in an unsorted way.
• skipPublishingChecks : boolean (optional)
  If this option is unchecked, then the plugin automatically publishes a summary of the coverage report to corresponding SCM hosting platforms. For example, if you are using this feature for a GitHub organization project, the coverage summary will be published to GitHub through the Checks API. If this operation slows down your build, or you don't want to publish the summary to SCM platforms, you can use this option to deactivate this feature.
• skipSymbolicLinks : boolean (optional)
  The coverage plugin will not traverse symbolic links while scanning for report or source code files when this option is enabled.
• sourceCodeEncoding : String (optional)
  In order to correctly show all your covered source code files in the detail views, the plugin must open these files with the correct character encoding (UTF-8, ISO-8859-1, etc.). If you leave this field empty then the default encoding of the platform will be used. This might work but is not recommended.
• sourceCodeRetention (optional)
  Select the strategy that should be used to store the colored source code files. Storing the affected source code files along with the coverage information (which lines have been covered, which not) consumes a lot of space on your hard disk for large projects. So if your server has not enough free space available to store the sources for all builds it might make more sense to store only the coverage results of the last build. In this case, the plugin will automatically discard old results before the new sources will be stored. If you do not need the source files at all you can deactivate the storing of source code files. The following options are supported:

  NEVER

  Never store source code files.

  LAST_BUILD

  Store source code files of the last build, delete older artifacts.

  EVERY_BUILD

  Store source code files for all builds, never delete those files automatically.

  MODIFIED

  Store only changed source code files for all builds, never delete those files automatically.

  • Values: NEVER, LAST_BUILD, EVERY_BUILD, MODIFIED
• sourceDirectories (optional)

  Select additional folders that contain the source code files of the job. Since the plugin also reads the affected source code files, it needs to copy these files from the agent to the controller. If these files are not part of the workspace (or checked out into a subfolder of the workspace), they are not automatically found. So you can add one or more source code directories where the plugin tries to find these files. You can add relative paths in the workspace root, absolute paths, or expressions using the glob or regexp syntaxes that are supported by the Java FileSystem#getPathMatcher implementation. Note that due to security restrictions, additional paths outside the workspace need to be registered in Jenkins system configuration before they can be used here.

  Examples for the syntax and pattern property:

  submodule/src/main/java

  Relative path submodule/src/main/java in the Jenkins workspace.

  glob:**/src/main/java

  A glob that expands to all folders in the Jenkins workspace that contain the sub-path src/main/java.

  regex:sources.*/src/main/java

  A regular expression that matches all folders in the Jenkins workspace that start with sources and end with the text src/main/java.

  C:\work\sources

  Absolute path on the agent that builds the sources. This folder must also be approved by a Jenkins administrator in Jenkins global configuration.

  Array / List of Nested Object
  • path : String
    Select the path to your source code files. This plugin copies source code files to Jenkins' build folder so that these files can be rendered in the user interface together with the plugin results. If these files are referenced with relative paths then they cannot be found by the plugin. In these cases you need to specify one or more relative paths within the workspace where the plugin can locate them. Alternatively, you can also specify absolute paths if the source code files are stored outside the workspace (in a directory on the agent). All absolute paths must be additionally approved by an administrator in Jenkins' global configuration page.
• tools (optional)
  Select one of the supported coverage report formats. Most coverage tools support the output to the Cobertura format, please look into the manual of your coverage tool to see if that format is supported.
  Array / List of Nested Object
  • parser (optional)
    Select the ID of the parser that should read and parse your report files - currently, parsers for Cobertura (id = COBERTURA), JaCoCo (id = JACOCO), and PIT (id = PIT) are supported.
    • Values: COBERTURA, JACOCO, OPENCOVER, PIT, JUNIT
  • pattern : String (optional)
    A pattern is defined by an Ant Fileset ''includes'' setting that specifies the coverage report files to read. Multiple patterns can be separated by space or comma. Note that such a pattern is resolved in Jenkins' workspace, so the paths must be relative only. If no pattern is specified then the default pattern of the coverage tool will be used.