The following plugin provides functionality available through
Pipeline-compatible steps. Read more about how to integrate steps into your
Pipeline in the
Steps
section of the
Pipeline Syntax
page.
For a list of other such plugins, see the
Pipeline Steps Reference
page.
AbsInt Astrée Plugin for Jenkins
step([$class: 'AstreeBuilder'])
: Astrée Analysis Run
dax_file : String
Absolute path to the DAX file containing the analysis specification and configuration.
Note: In this setting, environment variables can be expanded. Expansion will affect all occurrences of the pattern ${name} where name is a valid environment variable name consisting solely of underscores, digits, and alphabetics from the portable character set and where the first character is not a digit.
Paths and environment variables are evaluated on the machine running Jenkins.
analysis_id : String
ID of an existing, preconfigured analysis on the Astrée server that serves as a revisioning base for the analyses of the current Jenkins project. The analysis, as configured via the supported DAX file, of a build is imported as a new revision into the project with this ID on the server, if such a project exists. The new revision will become a child revision of the last existing revision. If no project with this ID exists on the server, the analysis will become the first revision of a new project with the specified ID.
Note: In this setting, environment variables can be expanded. Expansion will affect all occurrences of the pattern ${name} where name is a valid environment variable name consisting solely of underscores, digits, and alphabetics from the portable character set and where the first character is not a digit.
output_dir : String
Absolute path to the folder into which the Summary Reports are to be generated. If left empty, reports will be generated into the project's Workspace directory and will be accessible from the Jenkins web interface.
Note: In this setting, environment variables can be expanded. Expansion will affect all occurrences of the pattern ${name} where name is a valid environment variable name consisting solely of underscores, digits, and alphabetics from the portable character set and where the first character is not a digit.
skip_analysis : boolean
This switch can be used to deactivate the Astrée analysis build step. This switch provides a more convenient method to temporarily deactivate analysis runs than removing the entire build step and reconfiguring the Astrée analysis run from scratch when later adding the build step again.
genXMLOverview : boolean
genXMLCoverage : boolean
genXMLAlarmsByOccurence : boolean
genXMLAlarmsByCategory : boolean
genXMLAlarmsByFile : boolean
genXMLRulechecks : boolean
dropAnalysis : boolean
When this option is activated, the analysis is not stored on the Astrée server, instead it is automatically deleted after the analysis run of the build step.
This option is very helpful if the analysis run is only specified by a DAX file and it is not intended to archive each analysis run on the server.
Please be aware that using this option in an analysis run only specified by an analysis ID will result in deleting the analysis with that ID on the Astrée server.
This option corresponds to adding a --drop to a command line call to Astrée.
genPreprocessOutput : boolean
failonswitch
This option allow Astrée to fail a build depeneding on the types of detected code defects. The following settings are available:
- Only Errors
... lets Astrée fail a build if an Error (Definite Type A Alarm) is reported.
This is the preferred setting for most use cases. A build is failed if Astrée can formally show the presence of a severe code defect in a (analysis) context.
- Errors and Alarms
... lets Astrée fail a build if an Error or Alarm (Definite Type A Alarm or Potential Alarm of Type B or Type C) is reported.
This is the preferred setting in case the absence of runtime errors in an application is to be formally shown. A build is failed if Astrée reports potential runtime errors.
- Errors, Alarms, and Data-Flow Anomalies
... lets Astrée fail a build if and only if any type of alarm (definite/potential Type A, B, C or D) is reported.
This setting fails builds on any reported potential code defect or anomaly.
Nested Object
failon : String
Was this page helpful?
Please submit your feedback about this page through this
quick form.
Alternatively, if you don't wish to complete the quick form, you can simply
indicate if you found this page helpful?
See existing feedback here.