Code automatic review method and device and computer program product

Abstract

The invention discloses an automatic code review method and device and a computer program product, and the method comprises the steps: triggering a code submission event according to a received code change; extracting configuration parameters of a corresponding code warehouse according to the code submission event, and selecting a target execution environment according to a routing rule in the configuration parameters; detecting the code change through a static code analysis tool in the target execution environment; and generating a review score according to the detection result. According to the method, a uniform code warehouse management entry is provided, the setting requirements of different types of code warehouses are supported, the resource cost is reduced, the code review time is shortened, and an efficient and extensible solution is provided for automatic review of large-scale and multi-type code warehouses.

Description

Technical Field

[0001] The present invention relates to the technical field of intelligent connected vehicles, and in particular to a method and device for automatic code review, as well as a computer program product, a device, and a computer program product. Background Art

[0002] With the development of the trend of "software-defined vehicles", the number of vehicle software modules and codes has increased significantly. In order to quickly respond to market changes and meet user needs, the agile development mode has gradually been introduced into automotive software development. However, frequent software code deliveries must simultaneously meet increasingly strict quality requirements and safety standards, which pose significant challenges to code product quality, code security compliance, and development efficiency.

[0003] Gerrit, as a web-based code review tool, is widely used in Git version control system projects. With its powerful code review and version control functions, it helps teams improve code quality, enhance collaboration, speed up development, and ensure the security and stability of the code repository. Cppcheck is an open-source static code analysis tool specifically used to check for errors and potential problems in C / C++ code, which helps to detect and solve potential hazards in the code at an early stage and improve code quality and reliability. Jenkins, as an open-source build management tool, provides a plugin for integrating with Gerrit, which can configure the Gerrit server and the code repositories and branches to be detected. By polling Gerrit commit records, it can automatically check out the code, run Cppcheck, and feedback the results to Gerrit for code review scoring, thus realizing an automated code review process.

[0004] Although this method is effective, the current process of performing automated Cppcheck code reviews based on Jenkins and Gerrit plugins still faces the following defects:

[0005] (1) High maintenance cost: Due to Gerrit plugin limitations, it is difficult to efficiently manage the configuration information of multiple code repositories and their branches, resulting in complex and costly maintenance as the number of code repositories grows.

[0006] (2) Lack of flexibility: It is impossible to customize Cppcheck detection parameters for different code repositories, nor can the whitelist and blacklist mechanisms for branches be flexibly set, restricting the ability of personalized configuration.

[0007] (3) Difficulty in balancing efficiency and cost: The code volumes and complexities of each code repository vary greatly, but the current solution can only run Cppcheck tasks using machines of the same specification, failing to optimize resource allocation according to the characteristics of the code repositories, resulting in resource waste or low detection efficiency. Summary of the Invention

[0008] The technical problem to be solved by the embodiments of the present invention is to provide a code automatic review method, device, computer program product, device and computer program product, so as to reduce the management and maintenance costs of code review and achieve a good balance between resource costs and detection efficiency.

[0009] To solve the above technical problem, the present invention provides a code automatic review method, including the following steps:

[0010] Trigger a code submission event according to the received code change;

[0011] Extract the configuration parameters of the corresponding code repository according to the code submission event, and select a target execution environment according to the routing rules in the configuration parameters;

[0012] Detect the code change in the target execution environment through a static code analysis tool;

[0013] Generate a review score according to the detection result.

[0014] Preferably, the step of selecting a target execution environment according to the routing rules in the configuration parameters specifically includes:

[0015] Select the detection machine specified by the routing name according to the routing name in the configuration parameters; or

[0016] Select a detection machine corresponding to the code type of the code repository according to the mapping relationship between the code type and the target execution environment in the configuration parameters, where the code type is dynamically determined by the label of the code repository or the name of the code repository.

[0017] Preferably, the code submission event is a patch set creation event generated by the Gerrit platform, and the code change is the modified content submitted through a code branch.

[0018] Preferably, the step of extracting the configuration parameters of the corresponding code repository according to the code submission event specifically includes:

[0019] Extract the code repository name from the configuration parameters carried by the patch set creation event;

[0020] Judge whether the static code analysis tool is enabled for the code repository according to the code repository name. If the static code analysis tool is enabled, further extract the detection parameters, branch policy and routing rules from the configuration parameters carried by the patch set creation event, and encapsulate the extracted configuration parameters into structured data and send them to the detection project predefined in the Jenkins platform; if the static code analysis tool is not enabled, no detection task is triggered.

[0021] Preferably, the detection parameters include exclusion rules, third-party library paths, and detection options; the branch policy includes a branch blacklist and a branch whitelist defined by regular expressions.

[0022] Preferably, detecting the code change by a static code analysis tool in the target execution environment specifically includes:

[0023] According to the regular expressions of the branch blacklist and whitelist and the name of the submitted code branch, determine whether to ignore this detection; if ignored, terminate the detection process; otherwise, perform the following operations:

[0024] Generate a code checkout path based on the code submission event parameters. If the path does not exist, download the complete code repository. If the path exists, clean the local code and checkout the code change submitted this time;

[0025] Generate command line instructions for the static code analysis tool according to the exclusion rules, library paths, and detection options, and execute them.

[0026] Preferably, the exclusion rules are used to ignore the detection of specified files or directories, the library paths are used to resolve code dependency relationships, and the detection options are used to enable specific detection rules.

[0027] The present invention also provides a code automatic review device, including:

[0028] A trigger module, configured to trigger a code submission event according to the received code change;

[0029] A specifying module, configured to extract configuration parameters of the corresponding code repository according to the code submission event, and select a target execution environment according to the routing rules in the configuration parameters;

[0030] A detection module, configured to detect the code change by a static code analysis tool in the target execution environment;

[0031] A scoring module, configured to generate a review score according to the detection result.

[0032] The present invention also provides a code automatic review device, including:

[0033] One or more processors;

[0034] A memory;

[0035] One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to execute the code automatic review method described above.

[0036] The present invention also provides a computer program product, including computer instructions, which direct a computer device to perform the operations corresponding to the method.

[0037] Implementing the present invention has the following beneficial effects: By constructing a unified code management platform and providing centralized and customizable code repository configuration capabilities, the present invention significantly improves code review efficiency and resource utilization. The present invention supports centralized configuration of multiple types of code repositories, and realizes "one platform, multiple repositories" management through predefined routing rules, branch policies, and detection parameters (exclusion rules, library paths, etc.), simplifying the complexity of operation and maintenance; Dynamically allocate detection tasks to the adapted execution environment (such as high / medium / low configuration machines) based on the code type or routing name, avoiding resource waste or performance bottlenecks, and reducing hardware costs while ensuring detection efficiency; From the code submission trigger event, parameter extraction, branch verification to detection execution and result feedback, a closed loop is formed, and combined with the scoring tag mechanism of the Gerrit platform, seamless connection of "submission → detection → review" is achieved, reducing manual intervention; By monitoring the detection time consumption and resource occupancy, automatically adjust the mapping relationship between the code type and the machine configuration, and continuously optimize the detection efficiency. The present invention provides an efficient and scalable solution for the automated review of large-scale and multiple types of code repositories. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0039] Figure 1 It is a schematic flowchart of a code automatic review method according to Embodiment 1 of the present invention.

[0040] Figure 2 It is a specific flowchart of a code automatic review method according to Embodiment 1 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0041] The following descriptions of the embodiments are made with reference to the drawings to illustrate specific embodiments in which the present invention can be implemented.

[0042] Please refer to Figure 1 As shown, Embodiment 1 of the present invention provides a code automatic review method, including the following steps:

[0043] Trigger a code submission event according to the received code change;

[0044] Extract the configuration parameters of the corresponding code repository according to the code submission event, and select the target execution environment according to the routing rules in the configuration parameters;

[0045] Detect the code change in the target execution environment through a static code analysis tool;

[0046] Generate a review score according to the detection result.

[0047] As can be seen from the above steps, in the embodiment of the present invention, by configuring the code repository routing attributes, different types of code detection tasks are distributed to different types of target execution environments for running, achieving an effective balance between resource costs and detection efficiency.

[0048] Specifically, in the embodiment of the present invention, the code repository is uniformly managed through a code management platform (Code Review Manager). In the initialization stage, the code management platform uniformly inputs all code repositories to be managed. The metadata of each code repository (such as repository name, access path, permission configuration, etc.) is stored in a non-volatile storage device (such as a solid-state drive or a distributed storage system) to ensure data persistence and fast access.

[0049] After that, for each code repository, the user can perform pre-configuration through the Web interface of the code management platform, which is specifically described as follows:

[0050] (1) Enable the static code analysis tool: The user activates the static code detection function for this repository by checking the "Enable Cppcheck" button.

[0051] (2) Set the detection parameters:

[0052] Exclude rule: Used to specify files or directories to be ignored during detection (such as third-party libraries, automatically generated code, etc.) to avoid irrelevant code interfering with the analysis results;

[0053] Library path: Used to configure the reference path of the third-party library to assist the static code analysis tool in accurately parsing the code dependency relationship.

[0054] Detection options: Customize the detection rules of Cppcheck (such as enabling specific check items, adjusting the warning level, etc.) to adapt to the code specification requirements of the project.

[0055] (3) Branch strategy:

[0056] Whitelist (branches allowed for detection): Define the target branches to be detected through regular expressions;

[0057] Blacklist (branches to be ignored): Exclude branches that do not need to be detected (such as ignore_branches) through regular expressions.

[0058] (4) Routing rules: Used to specify which type of target execution environment the detection tasks of this code repository should be routed to. It can be specified by the routing name, for example, specifying high - configuration machines, or medium - configuration machines, or low - configuration machines. It can also be specified through a mapping table of code types and machine configurations. Specifically:

[0059] First, divide the code repository into the following four categories:

[0060] APP type: Corresponding to front - end or lightweight application code, such as mobile applications, web interfaces, etc.;

[0061] MID type: Corresponding to middleware or service module code, such as API gateways, message queues, etc.;

[0062] HOST type: Corresponding to core services or high - load code, such as database engines, real - time computing services, etc.;

[0063] OTHER type: Other code that is not clearly classified, such as tool scripts, document generators, etc.

[0064] Developers can set labels (such as APP, HOST) for the code repository through the web interface of the code management platform to directly determine the code type. For example, a code repository with the label HOST will be automatically mapped to high - configuration machines. If no label is set, the code type will be automatically matched through keywords in the repository name:

[0065] Names containing APP, MOBILE → APP type

[0066] Names containing SERVICE, API → MID type

[0067] Names containing HOST, CORE → HOST type

[0068] Other names → OTHER type.

[0069] Then establish a mapping relationship between the code type and the target execution environment (machines with different configurations):

[0070] APP type → low - configuration machines to meet basic detection requirements;

[0071] MID type → medium - configuration machines to ensure the efficiency of medium - complexity tasks;

[0072] HOST type → high - configuration machines to ensure the rapid completion of complex detections;

[0073] OTHER type → low - configuration machine.

[0074] Furthermore, to improve resource utilization efficiency, the mapping relationship between code types and machine configurations is dynamically adjusted according to the actual running performance. For example, if the average detection time of a certain type of code on a low - configuration machine exceeds a threshold (such as 30 minutes), it is automatically upgraded to a higher - configuration machine. If the resource utilization rate of a certain type of code on a high - configuration machine is continuously lower than 20%, it is downgraded to a low - configuration machine. At the same time, according to the adjustment results, tags are automatically added or modified to the code repository. For example, an APP - type repository with frequent timeouts can be marked as the MID type.

[0075] Through the above configuration, the code management platform can dynamically determine whether each code submission triggers detection and precisely control the detection scope and rules, which not only ensures code quality but also avoids unnecessary resource consumption.

[0076] After completing the above initialization and pre - configuration processes, the code automatic review process of the embodiments of the present invention can be executed. Please refer to Figure 2 As shown, the automated review process is triggered through the event mechanism of the Gerrit server. Specifically, when a developer submits a certain code branch to the Gerrit server through the Gerrit client, the Gerrit server generates a Patchset - Created Event.

[0077] It can be understood that code changes generally refer to any modification of the code repository by developers, including adding, deleting, or modifying code, and do not limit the submission form. Submitting a code branch is a specific submission method of code changes, that is, developers submit modifications by creating a branch. In addition, there are also ways such as directly submitting to the main branch. The Patchset - Created Event is a specific event type in the Gerrit platform's code submission events, specifically referring to the action triggered when a code submission generates a patchset, which marks that the code submission has entered the Gerrit review process.

[0078] After the Gerrit server captures the Patchset - Created Event, it executes a pre - written Python script to complete the following operations:

[0079] (1) Capture all relevant parameters of the Patchset - Created Event, including but not limited to:

[0080] Event type (Kind): Metadata identifying the event type (such as "patchset - created");

[0081] Change-URL: The detailed page address of this code change in the Gerrit platform;

[0082] Change-Owner: The developer account that initiated this code change;

[0083] Uploader: The account that actually pushed the code (may be different from the owner);

[0084] Project: The code repository identifier to which the code belongs;

[0085] Branch: The target branch of this commit;

[0086] Topic: An optional field used to associate multiple changes (such as multiple modifications to the same function);

[0087] Commit: The unique identifier of this commit (Git Commit Hash);

[0088] Patchset: Identifies the patch version of this commit (e.g., the first commit is Patchset1).

[0089] (2) Package and send parameters:

[0090] The Python script packages the above parameters into the request data (Data) through an http post request and then sends it to the specified interface of the code management platform.

[0091] After receiving the code submission event sent by the Gerrit server, the code management platform extracts the configuration parameters of the corresponding code repository from the code submission event and selects the target execution environment according to the routing rules in the configuration parameters. The specific process is as follows:

[0092] 1. Event handling and condition judgment

[0093] After receiving the event request sent by the Gerrit server through the API, the code management platform first extracts all the above-mentioned relevant parameters from the request data (Data), such as the project (i.e., the code repository identifier). Subsequently, the code management platform queries the configuration parameters of the code repository based on the code repository identifier and judges whether to enable the static code analysis tool:

[0094] (1) Static code analysis tool not enabled:

[0095] If Cppcheck (or other static code analysis tools) is not selected to be enabled during pre-configuration for this code repository, it indicates that Cppcheck detection is not required for this code repository, and the code management platform will directly skip subsequent operations without triggering any detection tasks.

[0096] (2) Static code analysis tools have been enabled:

[0097] If Cppcheck (or other static code analysis tools) has been selected to be enabled during pre-configuration for this code repository, the code management platform will further extract the following configuration parameters:

[0098] Detection parameters: including files / directories to be excluded (Exclude), third-party library paths (Library), and detection options (Options).

[0099] Branch policy: blacklist (branches to be ignored for detection) and whitelist (branches to be detected) defined by regular expressions.

[0100] Routing rules: specify the target execution environment (such as high-end machines or low-end machines) to which the detection task for this code repository should be assigned according to the pre-configured routing name or the mapping relationship between code types and target execution environments.

[0101] 2. Parameter encapsulation and task routing

[0102] The code management platform encapsulates the above configuration parameters (detection parameters, branch policy, routing rules) into structured data and sends it to a dedicated detection project (such as cppcheck-job) predefined in the Jenkins platform.

[0103] It should be noted that since the code volumes and code complexities of each code repository are different, if they are all run on machines of the same type or configuration, high machine resource configuration is likely to cause resource waste and cost increase; low machine resource configuration will take a long time to run Cppcheck, resulting in low detection efficiency. Therefore, in the embodiments of the present invention, according to the scale and complexity of the code repository (for example, large projects require high-performance machines, and small projects can be allocated ordinary machines), the target execution environment is dynamically selected through pre-configured routing rules to avoid resource waste or low efficiency caused by "one-size-fits-all", achieving an effective balance between resource utilization rate and detection efficiency. In addition, the routing rules also support on-demand adjustment (such as adding new machine types, modifying resource allocation policies) to adapt to changes in project scale or upgrades in technical architecture.

[0104] After the Jenkins platform receives the configuration parameters (detection parameters, branch policies, routing rules) sent by the code management platform, it selects the corresponding machine according to the routing rules and passes the parameters to a predefined Python script for execution. This Python script performs the following operations based on the incoming configuration parameters to complete the detection and analysis of code changes:

[0105] (1) Branch policy verification

[0106] Based on the ignore_branches parameter (a pre-configured regular expression for branch black and white lists) and the branch parameter in the Gerrit event, determine whether the current committed branch needs to be detected.

[0107] If the branch is in the blacklist or not in the white list, set ignore_cppcheck = True and skip the detection; otherwise, continue execution.

[0108] (2) Code change checkout and cleanup

[0109] First, encapsulate the Gerrit event parameters (such as the change link Change-URL, code repository name Project, branch name Branch, and patch set number Patchset) into a GerritTriggerEvent object instance gerritenv, and generate the code checkout path checkout_path. checkout_path is the combination of the current workspace and the code repository path.

[0110] Then, pass the encapsulated gerritenv as a parameter to the GerritTriggerCppCheck class to generate an instance of code_cppcheck. The GerritTriggerCppCheck class is a custom Python class specifically used to manage and execute Cppcheck static code analysis tasks. Its constructor receives the gerritenv object and performs the following operations based on the parameters therein:

[0111] Initialize the detection environment: Set the code storage path according to checkout_path.

[0112] Configure the detection parameters: Parse parameters such as Exclude (exclusion rules), Library (library paths), and Check_Options (detection options).

[0113] Bind the Gerrit event context: Associate the current detection task with the specific change on the Gerrit platform for subsequent result feedback.

[0114] Generate a specific detection task instance code_cppcheck by instantiating the GerritTriggerCppCheck class, thus completing the initialization process of the static code analysis task.

[0115] Next, run the cppcheck method of code_cppcheck to determine whether checkout_path exists: If checkout_path does not exist, it means it is the first execution and the code of the entire code repository needs to be downloaded; if the checkout_path exists, first execute git reset–hard&&git clean–fd to clean the files generated during the previous run or the changed files, and then execute git fetch orign${gerrit_refspec}&&git checkoutFETCH_HEAD to check out the code of this commit.

[0116] (3) Execution of static code analysis

[0117] Run the run_check method of GerritTriggerCppCheck. The run_check method receives parameters such as Exclude, Library, Check_Options, and ignore_cppcheck to control the execution logic of static code analysis (cppcheck).

[0118] If ignore_cppcheck = True, skip the detection and return directly. If ignore_cppcheck = False, continue with the detection process, generate a complete cppcheck command line instruction according to the input parameters, and then execute the generated cppcheck instruction to perform static analysis on the code repository.

[0119] It can be seen that during the execution of static code analysis, the black / white list mechanism configured in the code repository is also used to determine whether to ignore the branch corresponding to this code commit. As mentioned above, the Exclude parameter represents the files and directories in the entire code repository that need to be ignored by cppcheck. If the files changed in this commit are in the Exclude parameter, these files will also be ignored during the run.

[0120] After Cppcheck finishes running, the Jenkins platform captures the detection results, including: detection reports, execution status, metadata, etc. The Jenkins platform then encapsulates the above results into JSON format data through an http post request and sends it to the preset API interface of the code management platform.

[0121] After the code management platform receives the API callback, it generates a review score according to the detection result. The specific rules are as follows:

[0122] +1 point (passed): No errors and the number of warnings is below the threshold.

[0123] -1 point (failed): There are errors or the number of warnings exceeds the limit.

[0124] The code management platform submits the scoring result to the corresponding code change page (Change-URL) through Gerrit's REST API.

[0125] Corresponding to the code automatic review method described in the foregoing Embodiment 1 of the present invention, Embodiment 2 of the present invention further provides a code automatic review device, including:

[0126] A trigger module for triggering a code submission event according to the received code change;

[0127] A specifying module for extracting configuration parameters of the corresponding code repository according to the code submission event, and selecting a target execution environment according to the routing rules in the configuration parameters;

[0128] A detection module for detecting the code change through a static code analysis tool in the target execution environment;

[0129] A scoring module for generating a review score according to the detection result.

[0130] Corresponding to the code automatic review method described in the foregoing Embodiment 1 of the present invention, Embodiment 3 of the present invention further provides a code automatic review device, including:

[0131] One or more processors;

[0132] A memory;

[0133] One or more applications, wherein the one or more applications are stored in the memory and are configured to be executed by the one or more processors, and the one or more applications are configured to execute the code automatic review method described in the foregoing Embodiment 1 of the present invention.

[0134] Corresponding to the code automatic review method described in the foregoing Embodiment 1 of the present invention, Embodiment 4 of the present invention further provides a computer program product, including computer instructions, and the computer instructions instruct a computer device to execute the operations corresponding to the code automatic review method described in the foregoing Embodiment 1 of the present invention.

[0135] Preferably, the processor may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or the processor may also be any conventional processor. The processor is the control center of the device, and connects various parts of the device through various interfaces and lines.

[0136] The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function, etc., and the data storage area can store relevant data, etc. In addition, the memory may be a high-speed random access memory, or may also be a non-volatile memory, such as a plug-in hard disk, a SmartMedia Card (SMC), a Secure Digital (SD) card, a Flash Card, etc., or the memory may also be other volatile solid-state storage devices.

[0137] It should be noted that the above device may include, but is not limited to, a processor and a memory, which can be understood by those skilled in the art.

[0138] For the working principle and process of the above embodiments, refer to the description of Embodiment 1 of the present invention above, and details are not described herein again.

[0139] As can be seen from the above description, compared with the prior art, the beneficial effects of the present invention are as follows: By constructing a unified code management platform, the present invention provides centralized and customizable code repository configuration capabilities, significantly improving code review efficiency and resource utilization. The present invention supports centralized configuration of multiple types of code repositories, and realizes the management of "one platform, multiple repositories" through predefined routing rules, branch policies, and detection parameters (exclusion rules, library paths, etc.), simplifying the complexity of operation and maintenance; dynamically allocates detection tasks to the appropriate execution environment (such as high / medium / low configuration machines) based on the code type or routing name, avoiding resource waste or performance bottlenecks, and reducing hardware costs while ensuring detection efficiency; forms a closed loop from code submission trigger events, parameter extraction, branch verification to detection execution and result feedback, and combines with the scoring label mechanism of the Gerrit platform to achieve seamless connection of "submission → detection → review", reducing manual intervention; automatically adjusts the mapping relationship between code types and machine configurations by monitoring detection time consumption and resource occupancy, continuously optimizing detection efficiency. The present invention provides an efficient and scalable solution for the automated review of large-scale and multiple types of code repositories.

[0140] The foregoing disclosure is only for the preferred embodiments of the present invention, and of course it cannot be used to limit the scope of the rights of the present invention. Therefore, equivalent changes made according to the claims of the present invention still fall within the scope covered by the present invention.

Claims

1. A method for automatic code review, characterized in that It includes the following steps: Trigger a code submission event according to the received code change; Extract the configuration parameters of the corresponding code repository according to the code submission event, and select a target execution environment according to the routing rules in the configuration parameters; Detect the code change in the target execution environment through a static code analysis tool; Generate a review score according to the detection result.

2. The method according to claim 1, wherein The selection of the target execution environment according to the routing rules in the configuration parameters specifically includes: Select the detection machine specified by the routing name according to the routing name in the configuration parameters; or Select a detection machine corresponding to the code type of the code repository according to the mapping relationship between the code type and the target execution environment in the configuration parameters, where the code type is dynamically determined by the label of the code repository or the code repository name.

3. The method according to claim 1, characterized in that The code submission event is a patch set creation event generated by the Gerrit platform, and the code change is the modified content submitted through a code branch.

4. The method according to claim 3, characterized in that The extraction of the configuration parameters of the corresponding code repository according to the code submission event specifically includes: Extract the code repository name from the configuration parameters carried by the patch set creation event; Judge whether the static code analysis tool is enabled for the code repository according to the code repository name. If the static code analysis tool is enabled, further extract the detection parameters, branch policy and routing rules from the configuration parameters carried by the patch set creation event, and encapsulate the extracted configuration parameters into structured data and send them to the predefined detection project in the Jenkins platform; if the static code analysis tool is not enabled, no detection task is triggered.

5. The method according to claim 4, wherein The detection parameters include exclusion rules, third-party library paths and detection options; the branch policy includes a branch blacklist and a branch whitelist defined by regular expressions.

6. The method according to claim 5, characterized in that, The detection of the code change in the target execution environment through a static code analysis tool specifically includes: Judge whether to ignore the current detection according to the branch black and white list regular expressions and the submitted code branch name. If it is ignored, terminate the detection process; otherwise, perform the following operations: Generate a code checkout path based on the code submission event parameters. If the path does not exist, download the complete code repository. If the path exists, clean the local code and checkout the code change submitted this time; Generate and execute the command line instructions of the static code analysis tool according to the exclusion rules, library path and detection options.

7. The method according to claim 6, characterized in that, The exclusion rules are used to ignore the detection of specified files or directories, the library path is used to resolve code dependencies, and the detection options are used to enable specific detection rules.

8. An automatic code review device, characterized in that, It includes: A trigger module for triggering a code submission event according to the received code change; A specifying module for extracting the configuration parameters of the corresponding code repository according to the code submission event and selecting a target execution environment according to the routing rules in the configuration parameters; A detection module for detecting the code change in the target execution environment through a static code analysis tool; A scoring module for generating a review score according to the detection result.

9. An automatic code review device, characterized in that, It includes: One or more processors; A memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, and the one or more applications are configured to perform the code automatic review method according to any one of claims 1 to 7.

10. A computer program product, characterized in that, Including computer instructions, the computer instructions instructing the computer device to perform the operations corresponding to the method according to any one of claims 1 to 7.

Images