A static scanning method and system for unmanned driving C++ code under ROS system

Abstract

The present application discloses a static scanning method and system for unmanned driving C++ code under ROS system, which relates to the field of computer software white box testing, including: when the unmanned driving system C++ code is pushed to the Git Lab code repository, the Jenkins Job is automatically triggered to perform the code scanning task through the integration of Git Lab and Jenkins Job. Jenkins Job pulls the latest code from Git Lab to the scanning server, configures the compilation environment of the unmanned driving system, and compiles the C++ code using CMake or Catkin tools. During the compilation process, the compilation information is intercepted by the build wrapper plug-in of Sonar Qube to generate structured data of the code. Then, the Sonar Scanner tool and its configuration parameters are used to scan the compiled C++ code, and the scanning results are uploaded to the Sonar Qube server. The entire scanning process is automatically scheduled through the Pipeline script of Jenkins Job. In view of the low efficiency of static analysis of C++ code of unmanned driving systems existing in the prior art, the analysis efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of white-box testing of computer software, and in particular to a static scanning method and system for unmanned driving C++ code under a ROS system. Background Art

[0002] With the rapid development of technologies such as artificial intelligence, sensors, and computer vision, driverless systems have gradually become a hot research and development hotspot and future trend in the automotive industry. With its high efficiency, safety, and environmental protection, driverless systems are expected to fundamentally change the way people travel and bring far-reaching social and economic benefits. However, as a critical system directly related to life safety and property safety, driverless systems place extremely high demands on software reliability and quality.

[0003] Autonomous driving systems are usually developed in C++, which has complex code logic, tight module coupling, and frequent interactions with hardware. It is very easy to introduce defects and vulnerabilities during the development process. In order to discover and eliminate quality problems in the code as early as possible, static code analysis has become an indispensable part of autonomous driving system development. Static code analysis can automatically scan and check the source code without running the program, quickly locate error patterns, design defects, security vulnerabilities, and performance bottlenecks in the code, thereby greatly improving software quality and development efficiency.

[0004] However, existing static code analysis tools still have many limitations in the development of unmanned driving systems. Unmanned driving systems involve complex concurrent control, real-time scheduling, hardware communication and other characteristics. Existing static analysis tools are difficult to fully understand their semantics, resulting in serious omissions and false positives in the analysis results, and are unable to provide developers with reliable quality feedback. Summary of the invention

[0005] In view of the problem of low efficiency of static analysis of C++ code of unmanned driving system in the prior art, the present application provides a static scanning method and system for unmanned driving C++ code under ROS system. When the user pushes the C++ code of the unmanned driving system to the Git Lab code repository, the integration of Git Lab and Jenkins Job automatically triggers JenkinsJob to perform the code scanning task. Jenkins Job pulls the latest code from Git Lab to the scanning server, configures the compilation environment of the unmanned driving system, and compiles the C++ code using CMake or Catkin tools. During the compilation process, the compilation information is intercepted by the build wrapper plug-in of Sonar Qube to generate structured data of the code. Then use the Sonar Scanner tool and its configuration parameters to scan the compiled C++ code, and upload the scan results to the Sonar Qube server. The entire scanning process is automatically scheduled through the Pipeline script of Jenkins Job, which improves the analysis efficiency.

[0006] Technical solution, the purpose of this application is achieved through the following technical solution.

[0007] One aspect of the present application provides a static scanning method for unmanned driving C++ code under the ROS system, including: S1, a user pushes the C++ code of the unmanned driving system to the Git Lab code repository; S2, based on the integration of Jenkins Job and Git Lab, using the Jenkins Job continuous integration tool to trigger and execute the Jenkins Job for code scanning on the code pushed in step S1; S3, Jenkins Job pulls the latest code pushed in step S1 from the Git Lab code repository to the specified directory of the code scanning server; S4, configuring the compilation environment that the unmanned driving system and each node of the unmanned driving system depend on through a Docker container or a virtual environment on the code scanning server, for compiling the C++ code pulled in step S3 to the specified directory of the code scanning server; S5, configuring the compilation path of the C++ code pulled in step S3 in the specified directory of the code scanning server, and compiling the C++ code using the catkin build compilation tool under the ROS system; S6, configuring the running environment of the Sonar Qube code analysis plug-in build wrapper on the code scanning server; S7, processing the C++ code compiled in step S5 through the build wrapper configured in step S6 to generate a code analysis plug-in for Sonar Scanner scans and analyzes the build-wrapper-dump.json file; S8, configures the code scanning parameters of Sonar Scanner, the code scanning parameters include the project name, the language used, the integration path of the build-wrapper, the authentication token of Sonar Qube, the local path of the C++ source code pulled in step S3 in the directory specified by the scanning server, and the URL of the Sonar Qube service; S9, encapsulates the Sonar Scanner configuration of step S8 through the Pipeline script or Jenkins Jobfile of the Jenkins Job. When step S2 triggers the Jenkins Job, the encapsulated script is called, and the SonarScanner command is executed according to the Sonar Scanner configuration information to perform a static scan on the C++ source code stored in the local directory specified in step S3, and upload the scan result to the Sonar Qube server.

[0008] This application uses Git Lab's web hooks mechanism to trigger the code scanning Job of Jenkins Job, and then integrates Sonar Qube's code scanning tool through Jenkins Job to perform automatic static scanning of the C++ code of the ROS project. The scanning results are fed back to the Sonar Qube page for developers to review and repair. The repaired code is pushed back to GitLab to trigger the automatic scanning process again. Finally, the automatic static scanning and analysis of C++ code based on Git Lab, Jenkins Job, and SonarQube in the ROS project is realized, which improves the code quality and development efficiency of the unmanned driving system.

[0009] Further, in S2, based on the integration of Jenkins Job and Git Lab, the Jenkins Job continuous integration tool is used to trigger and execute the Jenkins Job for code scanning on the code pushed in step S1, including: S21, setting the Git Lab Plugin plugin that communicates with Git Lab in Jenkins Job to establish a two-way communication channel between Jenkins Job and the Git Lab code repository; S22, in the global configuration of Jenkins Job, configuring the connection parameters of the installed Git Lab Plugin plugin; the connection parameters include the URL address of the Git Lab server and the Access Token credentials for communication between Jenkins Job and Git Lab; S23, creating a Jenkins Job in Jenkins Job as the task carrier for performing static scanning of the C++ code of the unmanned driving system. The Jenkins Job includes steps such as code pulling, compilation, scanning, and result uploading; S24, configuring the access credentials of the Git Lab code repository in Jenkins Job to authorize Jenkins Job to pull the C++ code repository of the unmanned driving system in Git Lab; S25, in the build trigger configuration of Jenkins Job, setting the Git Lab web hook trigger URL to associate the execution of Jenkins Job with the change events of the Git Lab code repository; S26, when Git Lab receives the code change event pushed in step S1, Git Lab sends a POST request containing the push information to the Git Lab web hook trigger URL configured in step S25 through the built-in web hook mechanism. The POST request contains metadata such as the changed code repository, branch, and commit ID; S27, the Git Lab web hook trigger URL parses the POST request and extracts the name of the Git Lab code repository and the branch name for executing code scanning; S28, according to the parsed code repository information and branch information, passing the code repository and branch information to Jenkins Job in the form of parameters, and Jenkins Job executes the static scanning task of the C++ code of the unmanned driving system.

[0010] Further, S3, Jenkins Job pulls the latest code pushed in step S1 from the Git Lab code repository to the designated directory of the code scanning server, including: S31, Jenkins Job calls the Git client provided by the Git Lab Plugin plug-in, uses the Git Lab code repository access credentials configured in step S24, and pulls the latest unmanned driving system C++ code pushed in step S1 from the GitLab code repository in a Clone or Pull manner; S32, Jenkins Job creates a designated directory on the code scanning server for storing and compiling the unmanned driving system C++ code, and stores the latest code pulled in step S31 in the designated directory.

[0011] Furthermore, S4, configuring the compilation environment of the unmanned driving system and each node of the unmanned driving system through a Docker container or a virtual environment on the code scanning server, including: S41, on the code scanning server, obtaining a pre-built Docker base image containing the unmanned driving system and its dependencies through a Docker container image management tool, and using the Docker base image to define the unmanned driving system compilation environment through a Docker file file, and building a Docker container image of the ROS compilation environment; S42, creating and starting an independent ROS compilation environment container through the Docker container image, and The volume mechanism mounts the specified directory storing the C++ code of the unmanned driving system in step S32 to the specified path of the ROS compilation environment container; S43, in the ROS compilation environment container, according to the function package dependencies defined in the package.xml file of the mounted C++ code of the unmanned driving system, configures the compilation and operation of the ROS function package and system dependency library through the function package management tool of the unmanned driving system; S44, on the code scanning server, uses the virtual environment management tool of the same operating system as the Docker base image of step S41 to create a Python virtual environment; sets the same unmanned driving system and dependency library as in the Docker container image of step S41 in the Python virtual environment; S45, by 4. In the Python virtual environment created in step S44, the environment variable ROS_PACKAGE_PATH of the unmanned driving system is set, and the specified directory storing the C++ code of the unmanned driving system in step S32 is added to the package search path of ROS to share access to the codes inside and outside the virtual environment; S46. In the Python virtual environment created in step S44, according to the function package dependencies defined in the package.xml file of the unmanned driving system C++ code added to the ROS package search path in step S45, the ROS function package and system dependency library are compiled and run through the function package management tool of the unmanned driving system; S47. Through the Pipeline script of the continuous integration tool, the configurations of steps S41 to S46 are incorporated into the execution process of the Jenkins Job as the compilation environment that the unmanned driving system and each node of the unmanned driving system depend on.

[0012] Further, S5, configures the compilation path of the C++ code pulled in step S3 in the specified directory of the code scanning server, and compiles the C++ code using the catkin build compilation tool under the ROS system, including: S51, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, stores the specified directory structure of the unmanned driving system C++ code according to step S32, and uses the CMake tool to generate a code compilation build system; wherein the build system includes a compiled source code directory, a target binary directory, and a dependent library directory; S52, sets the compilation options, compilation parameters, and dependent library paths of the unmanned driving system C++ code in the CMake Lists.txt file of the CMake build system generated in step S51, and sets the environment variables and rules for code compilation; S53, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, calls the CMake tool, and builds the Make Lists.txt file configured in step S52. files file and ninja file as compilation intermediate files, and generate a code compilation script; S54, execute the code compilation script generated in step S53 in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, use the compilation tool to compile the unmanned driving system C++ code pulled in step S3, and generate target files and library files; S55, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, use the Catkin compilation tool to replace the CMake compilation method of steps S51 to S54, and manage and compile the function package of the unmanned driving system C++ code by setting the package.xml file and the CMake Lists.txt file; S56, through the Pipeline script of the continuous integration tool, encapsulate the CMake or Catkin compilation process of steps S51 to S55 as an independent stage, incorporate it into the execution process of the Jenkins Job, and decouple it from the ROS compilation environment configuration stage and the code scanning stage of step S4 to achieve parallel execution and scheduling of compilation tasks.

[0013] Further, in step S6, configure the operating environment of the code analysis plugin buildwrapper of Sonar Qube on the code scanning server, including: S61, on the code scanning server, set the build wrapper of Sonar Qube; S62, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, set the execution commands and parameters of buildwrapper in the code compilation and linking phases, and integrate the execution commands and parameters into the CMake or Catkin compilation commands in step S5; S63, in the Jenkins Job Pipeline script in step S47, dynamically generate a build wrapper output directory parameter corresponding to the specified directory storing the C++ code of the unmanned driving system in step S32 according to the workspace where the current Jenkins Job runs, and pass the directory parameter to the build wrapper command set in step S62, so that build wrapper can obtain the compilation information of the code to be scanned in the current Job space each time it executes; S64, on the code scanning server, create a Sonar Qube project corresponding to the current Jenkins Job, set the code checker plugin matching the programming language in step S5 on the configuration page of the project, and set the quality rules and threshold parameters of the plugin, configure the parameters of the build wrapper integrated in step S62, the parameters including the build command and the build output directory, and generate a project-specific authentication token for authentication when the Jenkins Job uploads the code scanning results through the Sonar Scanner; S65, in the Jenkins Job Pipeline script in step S47, encapsulate the installation of the build wrapper in step S61, the integration of the compilation commands in step S62, the dynamic generation of the output directory in step S63, and the creation process of the Sonar Qube project in step S64 into an independent Pipeline phase, and execute it in parallel with the ROS compilation environment configuration phase in step S4 and the code compilation phase in step S5.

[0014] Further, in step S7, process the C++ code compiled in step S5 through the build wrapper configured in step S6 to generate a build-wrapper-dump.json file for Sonar Scanner scanning and analysis, including:

[0015] S71, in the build wrapper execution command set in step S62, the output result of the build-wrapper is specified as the build-wrapper-dump.json file in the build wrapper output directory generated in step S63; S72, when the CMake or Catkin compilation command is executed in step S5, the build wrapper intercepts and monitors the compilation process, collects the abstract syntax tree AST, symbol table, dependency and call relationship of the code files in each stage of the compilation, and writes them in the build-wrapper-dump.json file specified in step S71 in JSON format.

[0016] Further, S8, configure the code scanning parameters of Sonar Scanner, the code scanning parameters include the project name, the language used, the integration path of the build-wrapper, the authentication token of Sonar Qube, the local path of the C++ source code pulled in step S3 in the specified directory of the scanning server, and the URL of the Sonar Qube service, including: S81, in the configuration file sonar-project.properties of SonarScanner, set the unique identifier sonar.project Key and the display name sonar.project Name of the scanned project, the identifier and name are automatically generated based on the Git repository name and the Jenkins Job name; S82, in sonar-project.properties, set the programming language sonar.language of the scanned code to c++, set the directory sonar.sources where the source code file is located to the local path of the code pulled in step S32, and set the sonar.cfamily.build-wrapper-output parameter to the build wrapper output directory path generated in step S63; S83, in sonar-project.properties, set Sonar The access address sonar.host.url of the Qube server and the project authentication token sonar.login generated by the Sonar Qube project configuration page in step S64 are used so that Sonar Scanner can upload the scan results to the Sonar Qube server and project.

[0017] Further, S9, encapsulates the Sonar Scanner configuration of step S8 through the Pipeline script or Jenkins Jobfile of the Jenkins Job. When step S2 triggers the Jenkins Job, the encapsulated script is called, and the Sonar Scanner command is executed according to the SonarScanner configuration information to statically scan the C++ source code stored in the local directory specified in step S3, and upload the scan result to the Sonar Qube server, including: S91, in the Pipeline script or Jenkins Jobfile of the Jenkins Job, encapsulates the Sonar Scanner code scanning parameters configured in step S8 into an independent stage, and sets the project name, language used, build-wrapper command path integrated in step S62, Sonar Qube project authentication token generated in step S64, local path for storing C++ source code in step S32, and access URL configuration information of the Sonar Qube service through environment variables or parameterization in the stage; S92, in the Sonar Scanner stage of the Pipeline script or Jenkins Jobfile, obtains the Sonar Qube service URL and authentication token from the environment variables or credential management of the Jenkins Job, and combines the Sonar For other configuration parameters in the Scanner stage, a Sonar Scanner configuration file sonar-project.properties is generated using the Sonar Qube plug-in of the Jenkins Job. The configuration file contains all the code scanning parameters of step S8. S93, in the Sonar Scanner stage, the Pipeline script or Jenkins Jobfile calls the Sonar Scanner command line tool and passes the sonar-project.properties configuration file generated in step S92 as a parameter to the Sonar Scanner, so that it performs a static scan on the C++ source code in the local directory specified in step S32 according to the preset code scanning parameters. During the scanning process, the Sonar Scanner identifies and loads the build-wrapper-dump generated in step S7.json file to obtain the structured information of code compilation; S94, after the Sonar Scanner scans, it packages the scan results and analysis data into a scan report file, which contains code quantitative data and structured information; Sonar Scanner uploads the scan report file to the Sonar Qube server pointed to by the Sonar Qube service URL configured in step S91 through the HTTP protocol, and uses the Sonar Qube project authentication token configured in step S91 for identity authentication and authorization. .

[0018] Another aspect of the present application also provides a static scanning system for C++ code in an unmanned driving system.

[0019] Compared with the prior art, the advantages of this application are:

[0020] Through the integration of Git Lab and Jenkins Job, an automated trigger mechanism from code push to scanning is implemented. When the user pushes the C++ code of the driverless system to the Git Lab repository, Git Lab automatically notifies the Jenkins Job, which immediately pulls the latest code and performs the scanning task. This automated triggering method eliminates manual intervention, improves the timeliness and completeness of the scan, and enables code analysis to proceed synchronously with the development process.

[0021] By using Docker containers or virtual environments to configure the ROS compilation environment on the scanning server and using CMake or Catkin tools to compile C++ code, the simulation and adaptation of the specific compilation environment of the unmanned driving system is achieved. This method overcomes the complex dependencies and compilation process of the unmanned driving system.

[0022] By using the build wrapper plug-in of Sonar Qube to intercept compilation information during the compilation process, structured data such as the code's abstract syntax tree and symbol table are generated. The semantic information of the compilation stage is extracted and used for subsequent scanning, which makes up for the lack of program structure and execution flow information in traditional static analysis, enhances the ability to understand and analyze complex code patterns, and reduces the risk of missed reports and false positives.

[0023] Use the Sonar Scanner tool to perform code scanning, and with its rich configuration parameters, flexibly adapt the quality rules and threshold requirements of the C++ code of the unmanned driving system. Through customizable code metrics and inspection rules, targeted analysis of key quality characteristics in unmanned driving scenarios, such as memory safety, concurrency correctness, exception handling, etc., effectively identify the weak links and potential risks of the system.

[0024] The entire scanning process is automatically orchestrated and scheduled through the Pipeline script of the Jenkins Job. The various steps such as code pulling, compilation environment configuration, compilation and construction, build wrapper integration, and Sonar Scanner scanning are connected in a pipeline manner to form an automated and repeatable scanning workflow. This automated integration method reduces manual operations, improves the standardization of scanning and execution efficiency, and shortens the feedback cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] This specification will be further described in the form of exemplary embodiments, which will be described in detail by the accompanying drawings. These embodiments are not restrictive, and in these embodiments, the same number represents the same structure, wherein:

[0026] Figure 1 This is an exemplary flowchart of a static scanning method for unmanned driving C++ code under a ROS system according to some embodiments of this specification. DETAILED DESCRIPTION

[0027] The method and system provided in the embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0028] Figure 1This is an exemplary flow chart of a static scanning method for unmanned driving C++ code under the ROS system according to some embodiments of the present specification, including: a user pushes the C++ code of the unmanned driving system to the Git Lab code repository; based on the integration of Jenkins Job and Git Lab, a Jenkins Job is used to trigger and execute code scanning on the pushed code using the Jenkins Job continuous integration tool; Jenkins Job pulls the latest pushed code from the Git Lab code repository to a specified directory of the code scanning server; a compilation environment that the unmanned driving system and each node of the unmanned driving system depend on is configured on the code scanning server through a Docker container or a virtual environment, which is used to compile the C++ code pulled to the specified directory of the code scanning server; a compilation path for the pulled C++ code is configured in the specified directory of the code scanning server, and the C++ code is compiled using the catkin build compilation tool under the ROS system; a running environment for the Sonar Qube code analysis plug-in build wrapper is configured on the code scanning server; the compiled C++ code is processed through the configured build wrapper to generate a code analysis plug-in for Sonar Scanner scans and analyzes the build-wrapper-dump.json file; configures the code scanning parameters of SonarScanner, which include the project name, language used, integration path of build-wrapper, authentication token of Sonar Qube, local path of the pulled C++ source code in the specified directory of the scanning server, and URL of the Sonar Qube service; encapsulates the Sonar Scanner configuration through the Pipeline script or JenkinsJobfile of Jenkins Job. When the Jenkins Job is triggered, the encapsulated script is called, and the Sonar Scanner command is executed according to the Sonar Scanner configuration information to perform a static scan on the C++ source code stored in the specified local directory, and upload the scan results to the Sonar Qube server.

[0029] By integrating open source tools such as Git Lab, Jenkins Job, and Sonar Qube, the entire process of unmanned driving system C++ code push to scanning result display is automated.

[0030] First, the user pushes the C++ code of the unmanned driving system to the Git Lab code repository: The user completes the development and testing of the C++ code of the unmanned driving system in the local development environment. The user installs the Git version control tool locally and configures the SSH or HTTP(S) access credentials to the Git Lab server. The user creates a Git local repository corresponding to the Git Lab code repository locally and adds the locally developed C++ code files to the local repository. The user uses the git add command to temporarily store the modified code files, uses the git commit command to submit the code changes, and uses the git push command to push the code changes in the local repository to the specified branch of the Git Lab code repository.

[0031] Jenkins Job is integrated with Git Lab, and a two-way communication channel is established through the Git Lab Plugin: In the Jenkins plugin management page, search and install the "Git Lab Plugin" plugin. After the plugin is installed, Git Lab Plugin establishes a two-way REST API communication channel between Jenkins and Git Lab. Jenkins can access and operate resources such as code repositories, branches, and merge requests on Git Lab through the API interface provided by Git Lab Plugin. Git Lab can also actively push event notifications of code repositories to Jenkins through mechanisms such as web hooks to trigger Jenkins' build tasks.

[0032] In the global configuration of Jenkins Job, configure the connection parameters of the installed Git Lab Plugin; the connection parameters include the URL address of the Git Lab server and the Access Token credentials for Jenkins Job to communicate with Git Lab: In the "Manage Jenkins" page of Jenkins, select "Configure System" to enter the global configuration page.

[0033] In the Git Lab configuration area, set the URL address of the Git Lab server. In the Git Lab configuration area, set the Access Token for Jenkins to communicate with Git Lab. The token can be generated in the "Access Tokens" tab of the "User Settings" page of Git Lab. In the Git Lab configuration area, set the authentication method for Jenkins to access Git Lab. You can choose to use the built-in account of Jenkins or use Git Lab's OAuth authorization.

[0034] Create a Jenkins Job in Jenkins Job as the task carrier for static scanning of C++ code of unmanned driving system. The Jenkins Job includes code pulling, compiling, scanning and result uploading steps: On the main page of Jenkins, click "New Item" to create a new Jenkins Job. Enter the job name, select "FreestyleProject" as the job type, and click "OK" to enter the job configuration page. In the "Source Code Management" tab, select "Git" as the source code management tool, and set the URL address and authentication credentials of the Git Lab code repository. In the "Build Triggers" tab, select "Build when a change is pushed to Git Lab" to set the Git Lab web hook trigger. In the "Build" tab, add a build step to execute Shell or Batch commands, and write script commands for code pulling, compiling, scanning and result uploading.

[0035] In the build trigger configuration of the Jenkins Job, set the Git Lab web hook trigger URL to associate the execution of the Jenkins Job with the change event of the Git Lab code repository: On the configuration page of the Jenkins Job, in the "Build Triggers" tab, check the "Build when a change is pushed to Git Lab" checkbox. Jenkins will automatically generate a web hook trigger URL. On the "Settings" page of the Git Lab code repository, in the "Integrations" tab, add a new web hook. Fill in the web hook trigger URL generated by Jenkins into the web hook configuration of Git Lab and select the event type that triggers the web hook, such as "Push events".

[0036] When Git Lab receives the pushed code change event, Git Lab sends a POST request containing push information to the Git Lab web hook trigger URL configured in step S25 through the built-in web hook mechanism. The POST request contains metadata of the changed code repository, branch, and commit ID: When a user pushes a code change to the Git Lab code repository, Git Lab detects the Push event. Git Lab obtains the web hook trigger URL of the Jenkins Job by searching for the web hook configured in the code repository. Git Lab sends an HTTP POST request to the web hook trigger URL. The request Header contains the event type, and the request Body contains metadata of the code change, such as the repository name, branch name, and Commit ID.

[0037] Git Lab web hook trigger URL parses POST request and extracts Git Lab code repository name and branch name for code scanning: Jenkins' Git Lab Plugin provides a built-in web hook receiver for listening to and processing web hook requests from Git Lab. When Jenkins receives a web hook request from Git Lab, Git Lab Plugin parses the Header and Body of the request to extract information such as event type, code repository name, branch name, etc. Jenkins matches the associated Jenkins Job based on the code repository name and branch name, and triggers the build task of the Job. Jenkins passes the code repository name and branch name to the build task as parameters for use by the script steps in the task.

[0038] Jenkins Job uses the Git client of Git Lab Plugin to pull the latest C++ code from GitLab to the specified directory of the scanning server using the code repository access credentials: In the build step, Jenkins Job establishes a connection with the Git Lab code repository by calling the Git client provided by GitLab Plugin. The Git client of Git Lab Plugin uses the Git Lab code repository access credentials (such as user name and password, SSH key, etc.) set in the Jenkins global configuration to authenticate the Git Lab code repository. Jenkins Job creates a specified directory on the code scanning server for storing and compiling the C++ code of the unmanned driving system, such as " / opt / jenkins / workspace / job-name". Jenkins Job uses the Git client of Git Lab Plugin to pull the latest C++ code of the unmanned driving system from the Git Lab code repository in Clone or Pull mode. If there is no local copy of the code repository in the specified directory, the Git client uses the git clone command to clone the latest version of the code repository into the specified directory. If a local copy of the code repository already exists in the specified directory, the Git client will use the git pull command to merge the latest changes in the code repository into the local copy. When pulling code, the Git client will pull the latest code of the corresponding branch according to the Git Lab code repository name and branch name specified in the build trigger of the Jenkins Job. After the pull is completed, the latest C++ code of the unmanned driving system will be stored in the working directory of the Jenkins Job for subsequent compilation and static code scanning steps.

[0039] Jenkins Job calls the Git client provided by the Git Lab Plugin plug-in and uses the configured GitLab code repository access credentials to pull the latest unmanned driving system C++ code pushed from the Git Lab code repository in the Clone or Pull mode: In the build step, Jenkins Job calls Git commands to interact with the Git Lab code repository through the Git client API provided by the Git Lab Plugin. The Git client uses the Git Lab code repository access credentials set in the Jenkins global configuration to authenticate the Git Lab code repository. Common access credentials include: Username and password: The Git client uses the username and password of the Git Lab account to access the code repository through the HTTP(S) protocol. SSH key: The Git client uses the SSH key associated with the Git Lab account to access the code repository through the SSH protocol. Access Token: The Git client uses the Access Token generated by Git Lab to access the code repository through the HTTP(S) protocol. The Token needs to have read permission on the code repository.

[0040] The Git client constructs Git command line parameters based on the Git Lab code repository name and branch name specified in the build trigger of the Jenkins Job. If the git clone command is used, the Git client passes the URL of the code repository and the branch name to the clone command. If the git pull command is used, the Git client passes the remote name of the code repository (usually origin) and the branch name to the pull command, such as git pull origin branch-name. The Git client executes the constructed Git command to pull the latest unmanned driving system C++ code from the Git Lab code repository. If the gitclone command is used, the Git client creates a new copy of the code repository in the specified directory and checks out the latest code to the working directory. If the git pull command is used, the Git client merges the latest changes in the remote repository into the local copy and updates the code files in the working directory.

[0041] Jenkins Job creates a designated directory on the code scanning server for storing and compiling the C++ code of the unmanned driving system, and stores the latest code pulled in the designated directory: In the build step, Jenkins Job uses Shell or Batch scripts to create a designated directory on the code scanning server dedicated to storing and compiling the C++ code of the unmanned driving system. The path of the designated directory can be set in the configuration of the Jenkins Job, or it can be dynamically generated through environment variables or build parameters. Common directory paths include: subdirectories under the Jenkins workspace, such as {WORKSPACE} / src. Dedicated directories on the code scanning server, such as / opt / jenkins / workspace / job-name. Jenkins Job uses the operating system's file and directory management commands, such as mkdir, cd, etc., through Shell or Batch scripts to create the designated directory and set appropriate permissions. Jenkins Job uses the Git client of the Git Lab Plugin to store the latest C++ code of the unmanned driving system pulled in the created designated directory. When the Git client executes the git clone or git pull command, the Git client copies the files and directory structure of the code repository to the designated directory. After the pull is completed, the latest version of the unmanned driving system C++ code will be stored in the specified directory, and the Jenkins Job can directly access and use the code files in the directory in subsequent build steps.

[0042] On the code scanning server, use the Docker container image management tool to obtain the pre-built Docker base image containing the unmanned driving system and its dependencies, and use the Docker base image to define the unmanned driving system compilation environment through the Docker file file to build the Docker container image of the ROS compilation environment: Install Docker container image management tools such as Docker Engine and Docker Registry on the code scanning server. Obtain the pre-built Docker base image containing the unmanned driving system and its dependencies from the Docker Registry, such as the ros:melodic-ros-base image provided by ROS. Create a new Docker file file, based on the Docker base image, and define the configuration and dependencies of the unmanned driving system compilation environment through the instructions in the Docker file. In the Docker file, use the RUN instruction to install the tools and libraries required to compile the unmanned driving system, such as gcc, g++, cmake, catkin, etc. In the Dockerfile, use the RUN instruction to configure the ROS environment variables, such as source / opt / ros / melodic / setup.bash. Use the docker build command to build a new Docker container image of the ROS compilation environment based on the written Docker file file.

[0043] Create and start an independent ROS compilation environment container through the Docker container image, and mount the specified directory storing the unmanned driving system C++ code to the specified path of the ROS compilation environment container through the DockerVolume mechanism: Use the docker run command to create and start a new Docker container based on the built ROS compilation environment Docker container image.

[0044] In the docker run command, use the -v parameter to mount the specified directory storing the C++ code of the unmanned driving system to the specified path of the container, such as -v / opt / jenkins / workspace / job-name: / catkin_ws / src. After the container is started, the C++ code of the unmanned driving system will be mapped to the specified path in the container through the Docker Volume mechanism for access and use by the ROS compilation environment in the container.

[0045] In the ROS compilation environment container, according to the function package dependencies defined in the package.xml file of the mounted unmanned driving system C++ code, configure the compilation and running of ROS function packages and system dependency libraries through the function package management tool of the unmanned driving system: In the ROS compilation environment container, enter the mounted unmanned driving system C++ code directory, such as cd / catkin_ws / src. Use the catkin_make command to automatically parse and download the required ROS function packages and system dependency libraries according to the function package dependencies defined in the package.xml file. Use the catkin_make command to generate the CMake configuration file and Make file required to compile the unmanned driving system C++ code in the / catkin_ws directory. Use the catkin_make command to compile the C++ code of the unmanned driving system and generate executable files and library files.

[0046] On the code scanning server, use the virtual environment management tool of the same operating system as the Docker base image to create a Python virtual environment: Set up a virtual environment management tool of the same operating system as the Docker base image on the code scanning server, such as Python's virtualenv or conda. Use the virtualenv or conda command to create a new Python virtual environment, such as virtualenv / opt / venv or conda create -n venv python=3.6. Activate the created Python virtual environment, such as source / opt / venv / bin / activate or conda activate venv. Set up the same unmanned driving system and dependent libraries in the Python virtual environment as in the Docker container image: In the activated Python virtual environment, use the pip command to set up the same version of the unmanned driving system and dependent libraries as in the Docker container image, such as pip install catkin-pkg ros dep ros install_generator ws tool rosinstall. Use the ros dep init and ros dep update commands to initialize and update the ROS dependency management database.

[0047] By setting the ROS_PACKAGE_PATH environment variable for the unmanned driving system in the created Python virtual environment, the specified directory storing the C++ code of the unmanned driving system is added to the package search path of ROS to share access to the code inside and outside the virtual environment: In the Python virtual environment, set the ROS_PACKAGE_PATH environment variable and add the specified directory storing the C++ code of the unmanned driving system to the package search path of ROS, such as export ROS_PACKAGE_PATH= / opt / jenkins / workspace / job-name:ROS_PACKAGE_PATH. After setting the ROS_PACKAGE_PATH environment variable, ROS nodes and tools running in the Python virtual environment can directly access and use the C++ code of the unmanned driving system outside the virtual environment. In the created Python virtual environment, according to the package dependencies defined in the package.xml file of the C++ code of the unmanned driving system added to the ROS package search path, compile and run the ROS package and system dependency libraries through the package management tool of the unmanned driving system: In the Python virtual environment, enter the specified directory where the C++ code of the unmanned driving system is stored, such as cd / opt / jenkins / workspace / job-name. Use the catkin_make command to automatically parse and download the required ROS package and system dependency libraries according to the package dependencies defined in the package.xml file. Use the catkin_make command to generate the CMake configuration file and Make file required to compile the C++ code of the unmanned driving system in the current directory. Use the catkin_make command to compile the C++ code of the unmanned driving system and generate executable files and library files. Through the Pipeline script of the continuous integration tool, all configurations are included in the execution process of the Jenkins Job as the compilation environment for the unmanned driving system and its nodes: In the configuration of the Jenkins Job, add a new Pipeline step and write the build script using the Pipeline syntax of Jenkins. In the Pipeline script, use the docker command to build and start the Docker container of the ROS compilation environment, and mount the specified directory storing the C++ code of the unmanned driving system into the container. In the Pipeline script, use the sh command to execute the catkin_make command in the ROS compilation environment container to compile the C++ code of the unmanned driving system.In the Pipeline script, use the virtualenv or conda command to create a Python virtual environment, and set the same driverless system and dependent libraries as the Docker container image in the virtual environment. In the Pipeline script, use the sh command to set the ROS_PACKAGE_PATH environment variable in the Python virtual environment, and execute the catkin_make command to compile the C++ code of the driverless system. Incorporate the Pipeline script into the execution process of the Jenkins Job as a configuration and build step for the compilation environment that the driverless system and its node dependencies depend on.

[0048] In the created ROS compilation environment container or Python virtual environment, use the CMake tool to generate a build system for code compilation according to the specified directory structure for storing the C++ code of the unmanned driving system: In the ROS compilation environment container or Python virtual environment, enter the specified directory for storing the C++ code of the unmanned driving system, such as cd / catkin_ws / src. Create a new build directory in the code directory to store the build files and compilation products generated by CMake, such as mkdir / catkin_ws / build. Create a new CMake Lists.txt file in the code directory to configure the compilation options, compilation parameters, and dependent library paths of the C++ code of the unmanned driving system. In the CMake Lists.txt file, use the cmake_minimum_required command to specify the minimum version requirement of CMake, such as cmake_minimum_required (VERSION3.10). In the CMake Lists.txt file, use the project command to set the project name and programming language, such as project (auto_driving_system C CXX). In the CMake Lists.txt file, use the set command to set compilation options and compilation parameters, such as set (CMAKE_CXX_STANDARD 14) and set (CMAKE_BUILD_TYPE Release). In the CMakeLists.txt file, use the include_directories command to set the header file search path, such as include_directories ( / usr / local / include). In the CMake Lists.txt file, use the link_directories command to set the library file search path, such as link_directories ( / usr / local / lib). In the CMake Lists.txt file, use the add_executable command to add the executable file target to be compiled, such as add_executable (auto_driving_node src / main.cpp). In the CMake Lists.txt file, use the target_link_libraries command to link the required library files for the executable file target, such as target_link_libraries (auto_driving_node pthread).

[0049] In the created ROS compilation environment container or Python virtual environment, call the CMake tool to build Make files and ninja files as compilation intermediate files according to the configured CMake Lists.txt file, and generate code compilation scripts: In the ROS compilation environment container or Python virtual environment, enter the previously created build directory, such as cd / catkin_ws / build. Use the cmake command to specify the code directory path where the CMake Lists.txt file is located to generate compilation intermediate files and compilation scripts, such as cmake .. / src. The CMake tool automatically generates Make files and ninja files, as well as other compilation intermediate files, according to the configuration in the CMake Lists.txt file. The CMake tool generates a compilation script named Make file to drive the code compilation process. By executing the generated code compilation script in the created ROS compilation environment container or Python virtual environment, use the compilation tool to compile the pulled unmanned driving system C++ code and generate target files and library files: In the build directory of the ROS compilation environment container or Python virtual environment, execute the make command to start the code compilation process, such as make -j4. The compilation tool will automatically call the g++ compiler based on the generated Make file to compile the source files in the C++ code of the unmanned driving system. During the compilation process, the compilation tool will generate target files and library files based on the compilation options and compilation parameters set in the CMake Lists.txt file. The target files and library files generated by the compilation will be stored in the build directory and can be called and linked by other programs or nodes.

[0050] In the created ROS compilation environment container or Python virtual environment, use the Catkin compilation tool to replace the above CMake compilation method, and manage and compile the function package of the unmanned driving system C++ code by setting the package.xml file and CMake Lists.txt file: In the ROS compilation environment container or Python virtual environment, enter the specified directory where the unmanned driving system C++ code is stored, such as cd / catkin_ws / src. Create a new package.xml file in the code directory to describe the function package information and dependencies of the unmanned driving system C++ code.

[0051] In the package.xml file, use <name>The tag sets the function package name, such as <name> auto_driving_pkg< / name> In the package.xml file, use <version>The tag sets the feature package version number, such as <version> 1.0.0< / version> In the package.xml file, use <description>The tag provides a brief description of the package, such as <description> Package for autonomous driving system< / description> In the package.xml file, use <maintainer>and <author>The tag sets the maintainer and author information of the feature package. In the package.xml file, use<build tool_depend> Tags set compilation tool dependencies, such as<buildtool_depend> catkin< / build tool_depend> .

[0052] In the package.xml file, use<build_depend> and<run_depend> The tag sets the compile-time and runtime dependencies of the feature package, such as<build_depend> roscpp< / build_depend> and<run_depend> std_msgs< / run_depend> . Create a new CMake Lists.txt file in the code directory to configure the compilation options, compilation parameters, and targets of the C++ code of the unmanned driving system. In the CMake Lists.txt file, use the catkin_package command to declare the function package, set the compile-time dependency, runtime dependency, and exported header file path, such as catkin_package (CATKIN_DEPENDS roscpp std_msgs).

[0053] In the CMake Lists.txt file, use the add_executable command to add the executable file target that needs to be compiled, such as add_executable (auto_driving_node src / main.cpp). In the CMake Lists.txt file, use the target_link_libraries command to link the required library files for the executable file target, such as target_link_libraries (auto_driving_node {catkin_LIBRARIES}). Use the catkin_make command to compile the function package of the unmanned driving system C++ code in the / catkin_ws directory to generate target files and library files, such as catkin_make -DCMAKE_BUILD_TYPE=Release.

[0054] Through the Pipeline script of the continuous integration tool, the CMake or Catkin compilation process is encapsulated as an independent stage, incorporated into the execution process of the Jenkins Job, and decoupled from the ROS compilation environment configuration stage and the code scanning stage to achieve parallel execution and scheduling of compilation tasks: In the Pipeline script of Jenkins, use the stage command to define a new compilation stage, such as stage('Compile') { ...}. In the compilation stage, use the docker command to start the ROS compilation environment container or use the sh command to activate the Python virtual environment. In the compilation stage, use the sh command to execute the CMake or Catkin compilation command, such as sh 'cmake .. / src && make -j4' or sh 'catkin_make -DCMAKE_BUILD_TYPE=Release'. In the Pipeline script, the compilation stage, the ROS compilation environment configuration stage, and the code scanning stage are placed in different stages to achieve parallel execution and scheduling of compilation tasks. In the configuration of the Jenkins Job, apply the Pipeline script to the execution process of the Job to trigger the automatic compilation and construction of the C++ code of the unmanned driving system.

[0055] On the code scanning server, set up Sonar Qube's build wrapper: On the code scanning server, download the build wrapper package that matches the server's operating system and architecture from the Sonar Qube official website. Unzip the downloaded build wrapper package to a specified directory, such as / opt / sonar / build-wrapper. Add the executable file path of the build wrapper program to the system's PATH environment variable so that the build wrapper command can be called from any location. On the code scanning server, set up the compiler and linker that match the C++ code programming language of the unmanned driving system, such as g++ and ld.

[0056] In the created ROS compilation environment container or Python virtual environment, set the execution commands and parameters of the build wrapper in the code compilation and linking stages, and integrate the execution commands and parameters into the CMake or Catkin compilation command: In the ROS compilation environment container or Python virtual environment, enter the specified directory where the C++ code of the unmanned driving system is stored, such as cd / catkin_ws / src. In the CMake Lists.txt file or package.xml file, use the set command to set the execution command and parameters of the build wrapper, such as set (BUILD_WRAPPER_EXECUTABLE / opt / sonar / build-wrapper / build-wrapper-linux-x86-64). In the CMake Lists.txt file or package.xml file, use the set command to set the output directory parameters of the build wrapper, such as set (BUILD_WRAPPER_OUTPUT_DIRECTORY / catkin_ws / build / bw_output).

[0057] In the CMake Lists.txt file or package.xml file, modify the CMake or Catkin compilation command and add the build wrapper execution command and parameters to the front of the compilation command, such as set (CMAKE_CXX_COMPILER_LAUNCHER {BUILD_WRAPPER_EXECUTABLE}). In the CMake Lists.txt file or package.xml file, pass the build wrapper output directory parameter to the Sonar Qube code analysis plugin, such as set (SonarQub CFAMILY_BUILD_WRAPPER_OUTPUT {BUILD_WRAPPER_OUTPUT_DIRECTORY}).

[0058] In the Jenkins Job Pipeline script, according to the workspace where the current Jenkins Job is running, a build wrapper output directory parameter corresponding to the specified directory storing the C++ code of the unmanned driving system is dynamically generated, and the directory parameter is passed to the set build wrapper command, so that the build wrapper obtains the compilation information of the code to be scanned in the current Job space each time it is executed: In the Pipeline script of the Jenkins Job, the env command is used to obtain the workspace path of the current Job, such as def workspace = env.WORKSPACE. In the Pipeline script, a string concatenation operation is used to generate a unique build wrapper output directory path according to the workspace path of the current Job and the specified directory storing the C++ code of the unmanned driving system, such as def bw Output Dir ="{workspace} / bw_output". In the Pipeline script, the with Env command is used to set the generated build wrapper output directory path as an environment variable, such as with Env (["BUILD WRAPPER OUTPUT DIRECTORY={bw OutputDir}”]) { ...}. In the Pipeline script, pass the set build wrapper output directory environment variable to the CMake or Catkin compilation command to enable the build wrapper to generate code compilation information during the compilation and linking stages, such as sh 'cmake -DBUILD WRAPPER OUTPUT DIRECTORY={BUILD WRAPPER OUTPUT_DIRECTORY}.. / src && make'.

[0059] On the code scanning server, create a Sonar Qube project corresponding to the current Jenkins Job, set the code checker plug-in that matches the programming language in the project configuration page, set the plug-in's quality rules and threshold parameters, configure the parameters of the integrated build wrapper, including the build command and build output directory, and generate a project-specific authentication token for Jenkins Job to authenticate when uploading code scanning results through Sonar Scanner: On the Sonar Qube server, log in to the Sonar Qube web interface using an administrator account. In the Sonar Qube project management page, click the "Create Project" button to create a new project. In the project creation page, set the project name, keywords, and visibility, such as "Autonomous Driving System", "auto-driving", and "Private". In the project configuration page, select the code checker plug-in that matches the C++ code programming language of the unmanned driving system, such as "Sonar C Family". In the project configuration page, set the quality rules and threshold parameters of the code checker plug-in, such as the severity and quantity thresholds of "Bugs", "Vulnerabilities", and "Code Smells". In the project configuration page, set the build wrapper's build command and build output directory parameters. The build command should be consistent with the CMake or Catkin compilation command used in the Jenkins Job, and the build output directory should be consistent with the buildwrapper output directory dynamically generated in the Pipeline script. In the project configuration page, generate a project-specific authentication token for authentication when JenkinsJob uploads code scanning results through Sonar Scanner.

[0060] In the Jenkins Job Pipeline script, the build wrapper installation, compilation command integration, output directory dynamic generation, and Sonar Qube project creation process are encapsulated into an independent Pipeline stage, which is executed in parallel with the ROS compilation environment configuration stage and the code compilation stage: In the Pipeline script of the Jenkins Job, use the stage command to define a new code scanning preparation stage, such as stage('Scan Preparation') { ...}. In the code scanning preparation stage, use the sh command to download and install the build wrapper package, and add its executable file path to the PATH environment variable. In the code scanning preparation stage, use the with Env command to set the output directory environment variable of the build wrapper and pass it to the compilation command of CMake or Catkin. In the code scanning preparation stage, use the withCredentials command to obtain the authentication information of the Sonar Qube server, such as the URL address of Sonar Qube and the project-specific authentication token. In the code scanning preparation stage, use the sh command to call Sonar Scanner to perform static code scanning and quality analysis on the C++ code of the unmanned driving system according to the configuration parameters of the Sonar Qube project. In the Pipeline script, the code scanning preparation phase is executed in parallel with the ROS compilation environment configuration phase and the code compilation phase to improve the execution efficiency of the CI / CD pipeline.

[0061] In the build wrapper execution command, specify the output of build-wrapper as the build-wrapper-dump.json file in the generated build wrapper output directory: In the CMake Lists.txt file or package.xml file, use the set command to set the output directory parameter of the build wrapper, such as set (BUILD_WRAPPER_OUTPUT_DIRECTORY / catkin_ws / build / bw_output). In the CMake Lists.txt file or package.xml file, modify the build wrapper execution command to include the --out-dir option and specify the output directory as the value of the BUILD_WRAPPER_OUTPUT_DIRECTORY variable, such as set (BUILD_WRAPPER_COMMAND{BUILD_WRAPPER_EXECUTABLE} --out-dir {BUILD_WRAPPER_OUTPUT_DIRECTORY}). In the CMake Lists.txt file or package.xml file, add the modified build wrapper execution command to the front of the CMake or Catkin compilation command, such as set (CMAKE_CXX_COMPILER_LAUNCHER {BUILD_WRAPPER_COMMAND}).

[0062] When executing CMake or Catkin compilation commands, the build wrapper intercepts and monitors the compilation process, collects the abstract syntax tree AST, symbol table, dependency and call relationship of the code files at each stage of the compilation, and writes them in the specified build-wrapper-dump.json file in JSON format: When executing CMake or Catkin compilation commands, the buildwrapper automatically intercepts the calls of the compiler and linker, and monitors the compilation process. In the preprocessing stage of compilation, the build wrapper parses the header file dependency of the code file, generates the abstract syntax tree AST of the code file, extracts the symbol information defined and used in the code file, and builds the symbol table of the code file. In the compilation stage of compilation, the build wrapper analyzes the function call relationship and module dependency of the code file, and generates the call graph and dependency graph of the code file. In the linking stage of compilation, the build wrapper collects the input file and output file information of the linker, and generates the binary dependency of the code file. The build wrapper will write the collected AST, symbol table, call relationship and dependency information of the code files into the specified build-wrapper-dump.json file in JSON format. Each code file corresponds to a JSON object, and each JSON object contains properties such as the path, AST, symbol table, call relationship and dependency of the code file.

[0063] Configure Sonar Scanner's code scanning parameters: In the Jenkins Job's workspace or the Sonar Qube project's configuration directory, create a file named sonar-project.properties to configure SonarScanner's code scanning parameters. In the sonar-project.properties file, use the sonar.project Key parameter to set the unique identifier of the scanned project. The identifier is automatically generated based on the Git repository name and the Jenkins Job name, such as sonar.project Key=auto-driving:master. In the sonar-project.properties file, use the sonar.project Name parameter to set the display name of the scanned project. The name is automatically generated based on the Git repository name and the Jenkins Job name, such as sonar.project Name=Autonomous Driving System (master). In the sonar-project.properties file, use the sonar.language parameter to set the programming language of the scanned code. For the C++ code of the unmanned driving system, set it to sonar.language=c++. In the sonar-project.properties file, use the sonar.sources parameter to set the directory where the source code file is located and specify it as the local path for pulling the code, such as sonar.sources= / catkin_ws / src.

[0064] In the sonar-project.properties file, use the sonar.cfamily.build-wrapper-output parameter to set the output directory path of the build wrapper, specifying it as the previously generated build wrapper output directory, such as sonar.cfamily.build-wrapper-output= / catkin_ws / build / bw_output. In the sonar-project.properties file, use the sonar.host.url parameter to set the access address of the Sonar Qube server. In the sonar-project.properties file, use the sonar.login parameter to set the project authentication token generated by the Sonar Qube project configuration page, such as sonar.login=a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6.

[0065] In the Pipeline script of Jenkins Job, encapsulate the configuration and execution process of Sonar Scanner into an independent stage, such as stage('Code Scan') { ...}, and place it after the code compilation stage for execution: In the CodeScan stage, use the with Sonar Qube Env command to inject the access address and authentication token configuration information of the Sonar Qube server into the Jenkins environment variables. In the Code Scan stage, use the sh command to call SonarScanner and pass the path of the sonar-project.properties file as a parameter, such as sh" / opt / sonar-scanner / bin / sonar-scanner -Dproject.settings=sonar-project.properties". SonarScanner reads the configuration parameters in the sonar-project.properties file and performs static code scanning and quality analysis on the C++ code of the unmanned driving system based on the code information in the build-wrapper-dump.json file. Sonar Scanner uploads the scan results to the Sonar Qube server and displays code quality metrics and problem reports in the dashboard of the Sonar Qube project.

[0066] In the Pipeline script or Jenkins Jobfile of Jenkins Job, encapsulate the configured Sonar Scanner code scanning parameters into an independent stage, and set the configuration information required by Sonar Scanner through environment variables or parameterization in the stage: In the Pipeline script or Jenkins Jobfile of Jenkins Job, encapsulate the configured Sonar Scanner code scanning parameters into an independent stage, and set the configuration information required by Sonar Scanner through environment variables or parameterization in the stage. In the SonarScanner stage of the Pipeline script or Jenkins Jobfile, obtain the Sonar Qube service URL and authentication token from the environment variables or credential management of Jenkins Job, and combine with other configuration parameters of the Sonar Scanner stage, use the Sonar Qube plug-in of Jenkins Job to generate a Sonar Scanner configuration file sonar-project.properties, and in the "Sonar Qube Scan" stage, use the with Sonar Qube Env command to inject the Sonar Qube service URL and authentication token configuration information into the environment variables of Jenkins.

[0067] In the with Sonar Qube Env block, use the sh command to call the Sonar Qube plugin of Jenkins, generate the sonar-project.properties file according to the configuration parameters of the Sonar Scanner stage, and in the Sonar Scanner stage, call the Sonar Scanner command line tool and pass the generated sonar-project.properties configuration file as a parameter to Sonar Scanner, so that it can perform static scanning on the C++ source code in the specified local directory according to the preset code scanning parameters. In the with Sonar Qube Env block, use the sh command to call the Sonar Scanner command line tool and pass the path of the sonar-project.properties file as a parameter to Sonar Scanner. Sonar Scanner reads the configuration parameters in the sonar-project.properties file and performs static scanning and quality analysis on the C++ code according to the configured C++ source code directory and build wrapper output directory. During the scanning process, Sonar Scanner automatically identifies and loads the build-wrapper-dump.json file generated by the build wrapper to obtain structured information of code compilation, such as dependencies, symbol tables, and call graphs of code files.

[0068] After the Sonar Scanner scans, it packages the scan results and analysis data into a scan report file and uploads the scan report file to the Sonar Qube server via the HTTP protocol: After the Sonar Scanner completes the code scan and quality analysis, it generates a scan report file containing code metrics data and problem reports. The report file format is usually XML or JSON. Sonar Scanner temporarily stores the scan report file in the temporary directory of the Jenkins workspace, such as {env.WORKSPACE} / target / sonar / report. Sonar Scanner uploads the scan report file to the API interface of the Sonar Qube server through an HTTP POST request. In the header of the HTTP request, Sonar Scanner uses the SONAR_AUTH_TOKEN environment variable injected by Jenkins as the authentication token to authenticate and authorize the upload request. If the authentication token is valid, the Sonar Qube server accepts the uploaded scan report file and stores it in the Sonar Qube database, associating it with the corresponding project.

[0069] After receiving the scan report file, the Sonar Qube server processes and analyzes the scan results and displays the code quality metrics and problem reports in the Sonar Qube project dashboard: The Sonar Qube server parses the code metric data and problem reports in the scan report file and imports them into the Sonar Qube database. The Sonar Qube server evaluates and scores the scan results according to the preset quality rules and thresholds, and generates project health and maintainability indicators. The Sonar Qube server displays code quality metrics and problem reports in the form of charts and tables on the project dashboard page, such as the number of lines of code, complexity, duplication rate, defect density, and technical debt. The project team can visit the Sonar Qube project dashboard page to understand the current status and changing trends of code quality, and refactor and optimize the code based on problem reports and improvement suggestions.< / author> < / maintainer> < / description> < / version> < / name>

Claims

1. A static scanning method for unmanned driving C++ code under ROS system, comprising: S1, the user pushes the C++ code of the autonomous driving system to the Git Lab code repository; S2, based on the integration of Jenkins Job and Git Lab, uses the Jenkins Job continuous integration tool to trigger and perform code scanning on the code pushed in step S1; S3, Jenkins Job pulls the latest code pushed in step S1 from the Git Lab code repository to the specified directory of the code scanning server; S4, configuring the compilation environment that the unmanned driving system and each node of the unmanned driving system depend on through a Docker container or a virtual environment on the code scanning server, which is used to compile the C++ code pulled to the specified directory of the code scanning server in step S3; S5, configuring the compilation path of the C++ code pulled in step S3 in the specified directory of the code scanning server, and compiling the C++ code using the catkin build compilation tool under the ROS system; S6, configure the running environment of the Sonar Qube code analysis plug-in build wrapper on the code scanning server; S7, processing the C++ code compiled in step S5 through the build wrapper configured in step S6 to generate a build-wrapper-dump.json file for Sonar Scanner scanning and analysis; S8, configure the code scanning parameters of Sonar Scanner, which include the project name, the language used, the integration path of the build-wrapper, the authentication token of Sonar Qube, the local path of the C++ source code pulled in step S3 in the specified directory of the scanning server, and the URL of the Sonar Qube service; S9, encapsulate the Sonar Scanner configuration of step S8 through the Pipeline script or JenkinsJobfile of the Jenkins Job. When step S2 triggers the Jenkins Job, the encapsulated script is called, and the Sonar Scanner command is executed according to the Sonar Scanner configuration information to perform a static scan on the C++ source code stored in the local directory specified in step S3, and upload the scan results to the Sonar Qube server.

2. The static scanning method for unmanned driving C++ code under ROS system according to claim 1, characterized in that: S2, based on the integration of Jenkins Job and Git Lab, uses the Jenkins Job continuous integration tool to trigger and perform code scanning on the code pushed in step S1, including: S21, set up the Git Lab Plugin plug-in for intercommunication with Git Lab in Jenkins Job to establish a two-way communication channel between Jenkins Job and Git Lab code repository; S22. In the global configuration of Jenkins Job, configure the connection parameters of the installed Git Lab Plugin. The connection parameters include the URL address of the Git Lab server and the Access Token credentials for Jenkins Job to communicate with Git Lab. S23, creating a Jenkins Job in Jenkins Job as a task carrier for executing static scanning of C++ code of the unmanned driving system. The Jenkins Job includes code pulling, compiling, scanning and result uploading steps; S24, configure the access credentials of the Git Lab code repository in the Jenkins Job, and authorize the Jenkins Job to pull the driverless system C++ code repository in GitLab; S25, in the build trigger configuration of Jenkins Job, set the Git Lab web hook trigger URL to associate the execution of Jenkins Job with the change event of Git Lab code repository; S26, when Git Lab receives the code change event pushed in step S1, Git Lab sends a POST request containing push information to the Git Lab web hook trigger URL configured in step S25 through the built-in web hook mechanism. The POST request contains metadata of the changed code repository, branch, and commit ID. S27, Git Lab web hook trigger URL parses the POST request and extracts the Git Lab code repository name and branch name for code scanning. S28, based on the parsed code repository information and branch information, passes the code repository and branch information to the Jenkins Job in the form of parameters, and the Jenkins Job performs a static scanning task of the C++ code of the unmanned driving system.

3. The static scanning method for unmanned driving C++ code under ROS system according to claim 2 is characterized in that: S3, Jenkins Job pulls the latest code pushed in step S1 from the Git Lab code repository to the specified directory of the code scanning server, including: S31, Jenkins Job calls the Git client provided by the Git Lab Plugin plug-in, uses the Git Lab code repository access credentials configured in step S24, and pulls the latest unmanned driving system C++ code pushed in step S1 from the Git Lab code repository in a Clone or Pull manner; S32, Jenkins Job creates a designated directory on the code scanning server for storing and compiling the C++ code of the unmanned driving system, and stores the latest code pulled in step S31 in the designated directory.

4. The static scanning method for unmanned driving C++ code under ROS system according to claim 3 is characterized in that: S4, configure the compilation environment that the unmanned driving system and each node of the unmanned driving system depend on through the Docker container or virtual environment on the code scanning server, including: S41, on the code scanning server, obtain a pre-built Docker base image containing the unmanned driving system and its dependencies through a Docker container image management tool, and use the Docker base image to define the unmanned driving system compilation environment through a Docker file file to build a Docker container image of the ROS compilation environment; S42, creating and starting an independent ROS compilation environment container through the Docker container image, and mounting the specified directory storing the C++ code of the unmanned driving system in step S32 to the specified path of the ROS compilation environment container through the DockerVolume mechanism; S43, in the ROS compilation environment container, according to the function package dependency defined in the package.xml file of the mounted unmanned driving system C++ code, configure, compile and run the ROS function package and system dependency library through the function package management tool of the unmanned driving system; S44, on the code scanning server, using a virtual environment management tool of the same operating system as the Docker base image of step S41, to create a Python virtual environment; setting the same unmanned driving system and dependent libraries as those in the Docker container image of step S41 in the Python virtual environment; S45, by setting the environment variable ROS_PACKAGE_PATH of the unmanned driving system in the Python virtual environment created in step S44, adding the specified directory storing the C++ code of the unmanned driving system in step S32 to the package search path of ROS, so as to achieve shared access to the codes inside and outside the virtual environment; S46, in the Python virtual environment created in step S44, according to the function package dependencies defined in the package.xml file of the unmanned driving system C++ code added to the ROS package search path in step S45, compile and run the ROS function package and system dependency library through the function package management tool of the unmanned driving system; S47, through the Pipeline script of the continuous integration tool, incorporate the configuration of step S41 to step S46 into the execution process of JenkinsJob as the compilation environment that the unmanned driving system and each node of the unmanned driving system rely on.

5. The static scanning method for unmanned driving C++ code under ROS system according to claim 4 is characterized in that: S5, configure the compilation path of the C++ code pulled in step S3 in the specified directory of the code scanning server, and use the catkin build compilation tool under the ROS system to compile the C++ code, including: S51, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, according to the specified directory structure storing the C++ code of the unmanned driving system in step S32, use the CMake tool to generate a build system for code compilation; wherein the build system includes a compilation source code directory, a target binary directory, and a dependent library directory; S52, setting the compilation options, compilation parameters and dependent library paths of the unmanned driving system C++ code in the CMake Lists.txt file of the CMake build system generated in step S51, and setting the environment variables and rules for code compilation; S53, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, calling the CMake tool, building the Make files and the ninja file as compilation intermediate files according to the CMake Lists.txt file configured in step S52, and generating a code compilation script; S54, executing the code compilation script generated in step S53 in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, and using the compilation tool to compile the unmanned driving system C++ code pulled in step S3 to generate target files and library files; S55, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, using the Catkin compilation tool to replace the CMake compilation method of steps S51 to S54, and managing and compiling the function package of the C++ code of the unmanned driving system by setting the package.xml file and the CMake Lists.txt file; S56, through the Pipeline script of the continuous integration tool, encapsulate the CMake or Catkin compilation process from step S51 to step S55 as an independent stage, incorporate it into the execution process of the Jenkins Job, and decouple it from the ROS compilation environment configuration stage and the code scanning stage of step S4 to achieve parallel execution and scheduling of compilation tasks.

6. The static scanning method for unmanned driving C++ code under ROS system according to claim 5 is characterized in that: S6, configure the running environment of the Sonar Qube code analysis plug-in build wrapper on the code scanning server, including: S61, on the code scanning server, set up the Sonar Qube build wrapper; S62, in the ROS compilation environment container created in step S42 or the Python virtual environment created in step S44, setting the execution commands and parameters of the build wrapper in the code compilation and linking stages, and integrating the execution commands and parameters into the CMake or Catkin compilation command in step S5; S63, in the Jenkins Job Pipeline script of step S47, dynamically generate a buildwrapper output directory parameter corresponding to the specified directory storing the C++ code of the unmanned driving system in step S32 according to the workspace where the current Jenkins Job is running, and pass the directory parameter to the build wrapper command set in step S62, so that the build wrapper obtains the compilation information of the code to be scanned in the current Job space each time it is executed; S64, on the code scanning server, create a Sonar Qube project corresponding to the current Jenkins Job, set a code checker plug-in that matches the programming language of step S5 in the project's configuration page, set the quality rules and threshold parameters of the plug-in, configure the parameters of the build wrapper integrated with step S62, the parameters include the build command and the build output directory, and generate a project-specific authentication token for identity authentication when the Jenkins Job uploads the code scanning results through Sonar Scanner; S65, in the Jenkins Job Pipeline script of step S47, the build wrapper installation of step S61, the compilation command integration of step S62, the dynamic generation of the output directory of step S63, and the Sonar Qube project creation process of step S64 are encapsulated as an independent Pipeline stage, which is executed in parallel with the ROS compilation environment configuration stage of step S4 and the code compilation stage of step S5.

7. The static scanning method for unmanned driving C++ code under ROS system according to claim 6 is characterized in that: S7, the C++ code compiled in step S5 is processed by the build wrapper configured in step S6 to generate a build-wrapper-dump.json file for Sonar Scanner scanning and analysis, including: S71, in the build wrapper execution command set in step S62, specifying the output result of the build-wrapper as the build-wrapper-dump.json file in the build wrapper output directory generated in step S63; S72, when executing the CMake or Catkin compilation command in step S5, the build wrapper intercepts and monitors the compilation process, collects the abstract syntax tree AST, symbol table, dependency and call relationship of the code files in each stage of the compilation, and writes them in JSON format to the build-wrapper-dump.json file specified in step S71.

8. The static scanning method for unmanned driving C++ code under ROS system according to claim 7, characterized in that: S8, configure the code scanning parameters of Sonar Scanner. The code scanning parameters include the project name, the language used, the integration path of the build-wrapper, the authentication token of Sonar Qube, the local path of the C++ source code pulled in step S3 in the specified directory of the scanning server, and the URL of the Sonar Qube service, including: S81, in the Sonar Scanner configuration file sonar-project.properties, set the unique identifier sonar.project Key and display name sonar.project Name of the scanned project. The identifier and name are automatically generated based on the Git repository name and Jenkins Job name; S82, in sonar-project.properties, set the scanning code programming language sonar.language to c++, set the source code file directory sonar.sources to the local path of the code pulled in step S32, and set the sonar.cfamily.build-wrapper-output parameter to the build wrapper output directory path generated in step S63; S83, in sonar-project.properties, set the access address sonar.host.url of the Sonar Qube server and the project authentication token sonar.login generated on the Sonar Qube project configuration page in step S64, so that Sonar Scanner can upload the scan results to the Sonar Qube server and project.

9. The static scanning method for unmanned driving C++ code under ROS system according to claim 8, characterized in that: S9, encapsulate the Sonar Scanner configuration of step S8 through the Pipeline script or JenkinsJobfile of the Jenkins Job, and when step S2 triggers the Jenkins Job, call the encapsulated script, execute the Sonar Scanner command according to the Sonar Scanner configuration information, perform a static scan on the C++ source code stored in the local directory specified in step S3, and upload the scan result to the Sonar Qube server, including: S91, in the Pipeline script or Jenkins Jobfile of the Jenkins Job, encapsulate the SonarScanner code scanning parameters configured in step S8 into an independent stage, in which the project name, the language used, the build-wrapper command path integrated in step S62, the Sonar Qube project authentication token generated in step S64, the local path for storing the C++ source code in step S32, and the access URL configuration information of the Sonar Qube service required by the Sonar Scanner are set through environment variables or parameterization; S92, in the Sonar Scanner stage of the Pipeline script or the Jenkins Jobfile, by obtaining the Sonar Qube service URL and the authentication token from the environment variables or the credential management of the Jenkins Job, and combining with other configuration parameters of the Sonar Scanner stage, using the Sonar Qube plug-in of the Jenkins Job to generate a Sonar Scanner configuration file sonar-project.properties, the configuration file includes all the code scanning parameters of step S8; S93, in the Sonar Scanner stage, the Pipeline script or Jenkins Jobfile calls the Sonar Scanner command line tool, and passes the sonar-project.properties configuration file generated in step S92 as a parameter to Sonar Scanner, so that it performs a static scan on the C++ source code in the local directory specified in step S32 according to the preset code scanning parameters. During the scanning process, Sonar Scanner identifies and loads the build-wrapper-dump.json file generated in step S7 to obtain structured information of code compilation; S94, after the Sonar Scanner scans, it packages the scan results and analysis data into a scan report file, which contains code quantification data and structural information; Sonar Scanner uploads the scan report file to the Sonar Qube server pointed to by the Sonar Qube service URL configured in step S91 through the HTTP protocol, and uses the Sonar Qube project authentication token configured in step S91 for identity authentication and authorization.

10. A static scanning system for C++ code in an unmanned driving system, characterized in that: include: At least one processing unit PE; used to execute instructions to implement the static scanning method for unmanned driving C++ code under the ROS system as described in any one of claims 1 to 9.

Images