SVN continuous integrated access control method and system based on Jenkins

Abstract

The invention discloses a Jenkins-based SVN continuous integrated access control method and system, and the method comprises the steps: triggering a pre-submission hook script when an SVN-based client carries out incremental code submission; obtaining a catalogue of each trigger assembly line which needs to trigger quality access control inspection, and determining whether each Jenkins assembly line is triggered or not; when it is determined that a certain assembly line is triggered, incremental code related information is transmitted to all execution machines of the assembly line, and the assembly line is remotely triggered based on a server side of the SVN; each execution machine based on the assembly line pulls the code of the baseline version from the SVN, and checks the code; and after the SVN server triggers the assembly line, polling the assembly line execution result until the assembly line execution result is obtained, and determining whether to submit the incremental code to the SVN code library or not according to the assembly line execution result. The system has the outstanding advantages of no need of manual maintenance, automatic closed-loop control, high reliability, high practicability, high efficiency, good real-time performance and the like.

Description

Technical Field

[0001] The present invention relates to the technical field of software development and operation and maintenance monitoring, and in particular to a Jenkins-based SVN continuous integration access control method and system. Background Art

[0002] Continuous integration emphasizes automatic building and testing. Based on the test results, it determines whether the new code and the original code can be correctly integrated together. Through continuous problem feedback and improvement, it promotes software quality control and improvement.

[0003] Compilation is the primary standard requirement for code integration. It ensures that the code is syntactically and semantically correct and can be correctly converted into executable files. Compilation errors usually mean that there are problems in the code that need to be fixed. Static code scanning is a technology that does not rely on compilation to analyze source code. It is used to discover potential defects, code standard violations, complexity issues, and security vulnerabilities. cppcheck is an open source static code scanning tool used to detect potential problems in C and C++ code. It can find some common programming errors, potential bugs, code style issues, and security risks. Online code review can identify code errors, defects, potential security issues, promote communication and discussion, and improve code readability and code quality. ReviewBoard is an open source, extensible, web-based code review tool that is intuitive and easy to use, and can be automated through the RBTool command line tool.

[0004] Continuous integration pipelines using the SVN version control system for version management typically require periodic pipeline triggering or post-commit triggering. Periodic triggering may require secondary determination to determine which commit caused a problem among multiple commits, as well as the increased cost of remediation when multiple commits accumulate. The post-commit triggering method also has flaws in the interception process, requiring manual maintenance for closed-loop control, rather than automated closed-loop control.

[0005] CN112379969A provides a continuous integration delivery method and related equipment based on containerized applications, the method comprising: defining a first file in the root directory of a code project, the first file being used to describe the dependency relationship between a continuous integration process and related tools to execute the continuous integration process; and triggering and starting the continuous integration process defined in the first file, wherein the triggering and starting of the continuous integration process is integrated into a module visual interface. This patent defines a first file in the root directory of a code project to describe the dependency relationship. The configuration file exists in the code library, allowing R&D personnel to modify it at will. There is a risk that the submission specification process will not be strictly enforced, so the reliability of this patent solution is not strong; in addition, the triggering and starting of this patent needs to be operated in the interface, so it is not very practical and inefficient.

[0006] CN113126961A discloses a pipeline processing method, device and storage medium, the method comprising: determining at least one target pipeline template, generating a pipeline task according to the at least one target pipeline template; receiving a trigger request, triggering the pipeline task according to the trigger request, generating a pipeline business corresponding to the pipeline task and a task Pod corresponding to the pipeline business; running the pipeline business based on the task Pod to obtain a completed pipeline business. This patent is mainly based on running the pipeline business based on the task Pod, but the submission trigger mentioned in it is still to directly pull the code after submitting the code. Therefore, the patent solution has the problem that the aforementioned closed-loop control requires manual maintenance and cannot achieve automatic closed-loop control.

[0007] CN109828886A discloses a CI / CD monitoring method and system in a container cloud environment, wherein the system includes: a monitoring component Agent and a data acquisition and processing center. The CI / CD monitoring system provided by this patent is a full-link monitoring system for continuous integration and continuous delivery based on a container cloud platform environment. For each monitoring source, there is an independent monitoring component Agent that interacts with the monitoring source for data; for each monitoring information block_message, there is a unique ID, and block_messages generated by different components share a tracking chain list. This patent differs significantly from the content of the present invention, and this patent uses an agent method to monitor and alarm the pipeline, which has poor real-time performance and makes it difficult to perform more analysis and alarms on abnormal execution. Summary of the Invention

[0008] In order to solve the shortcomings of the existing technology, such as the need for manual maintenance, the inability to achieve automatic closed-loop control, low reliability, low practicality, low efficiency, and poor real-time performance, the present invention provides an SVN continuous integration access control method based on Jenkins:

[0009] The present invention adopts the following technical solutions.

[0010] On one hand, the present invention discloses a Jenkins-based SVN continuous integration access control method, comprising:

[0011] When the client of the version control system submits incremental code, a pre-submit hook script is triggered; the pre-submit hook script obtains information related to the incremental code;

[0012] Get the configuration file in the pre-submit hook script, obtain the directory of each triggered pipeline that needs to trigger the quality gate check, and determine whether to trigger each Jenkins pipeline;

[0013] When a Jenkins pipeline is triggered, the incremental code information is transmitted to each execution machine of the pipeline, and the pipeline is remotely triggered based on the server of the version control system;

[0014] Each execution machine based on the pipeline pulls the baseline version of the code from the version control system and checks the code;

[0015] After the version control system server triggers the pipeline, it polls the pipeline execution results of Jenkins until the pipeline execution results are obtained. Based on the pipeline execution results, it determines whether to submit the incremental code to the version control system code library; the pipeline execution results include success, termination and failure.

[0016] More preferably,

[0017] The incremental code related information is obtained based on the svnlook command, including:

[0018] Use the changed-t subcommand to generate a list of changed files;

[0019] Use the cat subcommand to obtain the newly added or changed code files;

[0020] Use the diff subcommand to obtain the code difference record file;

[0021] Use the log -t subcommand to obtain the log information file.

[0022] More preferably,

[0023] If you need to create different pipelines for different trigger pipeline directories, configure multiple sets of trigger pipeline directories in the configuration file of the pre-submit hook script.

[0024] More preferably,

[0025] The determination of whether to trigger pipeline execution is to compare the subdirectories in the changed file list with the subdirectories in each triggered pipeline directory;

[0026] If the same subdirectory does not exist, exit the pre-submit hook script and submit the code;

[0027] If the same subdirectory exists, it is determined that the corresponding Jenkins pipeline needs to be triggered.

[0028] More preferably,

[0029] The execution machines include a compilation execution machine, a static incremental code access control execution machine and an online code review access control execution machine.

[0030] More preferably,

[0031] The code is checked based on the incremental code related information;

[0032] The checks include compilation access control checks, static incremental code access control checks, and online code review access control checks.

[0033] More preferably,

[0034] The compilation access control check includes:

[0035] Get the baseline version of the code;

[0036] In the baseline version code, replace the newly added / changed code files recorded in the change file list with the latest code files to obtain the code to be checked;

[0037] Compile the code to be checked based on the compilation script path, compilation script file name, and compilation output name configured in the YAML configuration file;

[0038] Archive compilation outputs to the warehouse management system.

[0039] More preferably,

[0040] The static incremental code access control check includes:

[0041] Obtain and scan the baseline version of the code and the code to be reviewed;

[0042] Defect duplication is detected based on the line number change information recorded in the code difference record file, defect issues in the incremental code are obtained, and an incremental static code scanning report is generated;

[0043] The static code scanning report includes the scanning rule name corresponding to the defect, the line number where the defect is located, and the defect description.

[0044] More preferably,

[0045] The online code review access checks include:

[0046] Get the .svn directory and submit it to the reviewboard platform;

[0047] Run the rbt command on the reviewboard platform to submit the difference record file and log information file to the reviewboard platform;

[0048] Poll the API interface of the reviewboard platform until you get the review form.

[0049] More preferably,

[0050] The method for determining whether to submit incremental code to the version control system code base based on the pipeline execution results is as follows:

[0051] When the pipeline execution is successful, the incremental code is submitted to the version control system code base;

[0052] When pipeline execution is aborted, the incremental code is not submitted to the version control system code base, and the pipeline abort is fed back to the client;

[0053] When a pipeline execution failure is detected, the incremental code is not submitted to the version control system code base, and the failed execution step is fed back to the client.

[0054] Another aspect of the present invention discloses a Jenkins-based SVN continuous integration access control system, which includes a hook script trigger module, a pipeline trigger determination module, a pipeline remote trigger module, a code inspection module, and an incremental code submission module:

[0055] The hook script trigger module triggers the pre-submit hook script when the client of the version control system submits the incremental code; the pre-submit hook script obtains the incremental code related information;

[0056] The pipeline trigger determination module obtains the configuration file in the pre-submit hook script, obtains the directory of each triggered pipeline that needs to trigger the quality access control check, and determines whether to trigger each Jenkins pipeline;

[0057] The pipeline remote trigger module transmits the incremental code related information to each execution machine of the pipeline when determining to trigger a Jenkins pipeline, and remotely triggers the pipeline based on the server of the version control system;

[0058] The code checking module pulls the baseline version of the code from the version control system based on each execution machine of the pipeline and checks the code;

[0059] The incremental code submission module, after the version control system server triggers the pipeline, polls the pipeline execution results of Jenkins until the pipeline execution results are obtained, and determines whether to submit the incremental code to the version control system code library based on the pipeline execution results; the pipeline execution results include success, termination and failure.

[0060] More preferably,

[0061] The system of the present invention also includes a pipeline expansion module:

[0062] In the pipeline extension module, the following configuration is required to connect other code bases to the pipeline:

[0063] Copy the pre-commit hook script of the version control system server, the configuration file in the pre-commit hook script, the pipeline Jenkins script, and its YAML file for the code base that needs to be connected to the pipeline;

[0064] Configure the Reviewboard platform. Configuration items include the version control system code repository address, Reviewboard platform user account, and authentication token.

[0065] The beneficial effects of the present invention are as follows:

[0066] The present invention proposes a Jenkins-based SVN continuous integration access control method, which can automatically trigger the Jenkins pipeline and perform access control during the incremental change submission process;

[0067] The SVN continuous integration access control method and system implemented by the present invention have the ability to automatically intercept software code defects before code submission, the ability to close the loop of problems that must be fixed before code submission can be made, the ability to trigger different pipelines for different directories, the versatility to facilitate access and expansion, and the ability to display reports on the execution process.

[0068] In addition, the present invention also has the following beneficial effects:

[0069] (1) The working mechanism should be streamlined, automated and standardized;

[0070] (2) Code defects can be automatically intercepted in a timely manner, and only after they are fixed can a code submission be completed, thus avoiding the increase in repair costs after the problems accumulate;

[0071] (3) Use consistent compilation and static checking execution engines to unify the compilation environment and scanning tools;

[0072] (4) It has the ability to conduct online automatic review, with clear change information and record of review opinions;

[0073] (5) The construction of email notification service solves the problem that code version management cannot be notified by directly configuring email addresses on the intranet, and the notification content is more detailed and specific;

[0074] (6) The pipeline setting template can be directly copied and connected through the YAML configuration of the Jenkins script, which is easy to extend to different code bases. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] Figure 1 A flow chart of a method for controlling access codes during incremental change submission; DETAILED DESCRIPTION

[0076] To make the objectives, technical solutions, and advantages of the present invention more clear, the technical solutions of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. The embodiments described in this application are only part of the embodiments of the present invention, not all of them. Based on the spirit of the present invention, other embodiments obtained by ordinary technicians in this field without making creative efforts are all within the scope of protection of the present invention.

[0077] This application discloses a Jenkins-based SVN continuous integration access control method, such as Figure 1 As shown, including:

[0078] When the client of the version control system SVN submits incremental code, the pre-commit hook script pre-commit is triggered; the pre-commit hook script obtains the incremental code related information;

[0079] The incremental code related information is obtained based on the svnlook command, including:

[0080] Use the changed-t subcommand to generate a list of changed files;

[0081] Use the cat subcommand to obtain the newly added or changed code files;

[0082] Use the diff subcommand to obtain the code difference record file;

[0083] Use the log -t subcommand to obtain the log information file.

[0084] Get the configuration file in the pre-submit hook script, obtain the directory of each triggered pipeline that needs to trigger the quality gate check, and determine whether to trigger each Jenkins pipeline;

[0085] If you need to create different pipelines for different trigger pipeline directories, configure multiple sets of trigger pipeline directories in the configuration file of the pre-submit hook script.

[0086] The different Jenkins pipeline steps include compilation access control check, static incremental code access control check and online code review access control check.

[0087] The determination of whether to trigger pipeline execution is to compare the subdirectories in the changed file list with the subdirectories in each triggered pipeline directory;

[0088] If the same subdirectory does not exist, exit the pre-submit hook script and submit the code;

[0089] If the same subdirectory exists, it is determined that the corresponding Jenkins pipeline needs to be triggered.

[0090] When it is determined to trigger a Jenkins pipeline, the incremental code related information is transmitted to each execution machine of the pipeline, and the pipeline is remotely triggered based on the server of the version control system SVN; the remote triggering of the Jenkins pipeline is implemented based on the Jenkins remote triggering interface API.

[0091] The execution machines include a compilation execution machine, a static incremental code access control execution machine and an online code review access control execution machine.

[0092] Each execution machine based on the pipeline pulls the baseline version of the code from the version control system SVN and checks the code; the code is checked based on the information related to the incremental code;

[0093] The code is checked based on the incremental code related information;

[0094] The checks include compilation access control checks, static incremental code access control checks, and online code review access control checks.

[0095] The compilation access control check includes:

[0096] Get the baseline version of the code;

[0097] In the baseline version code, replace the newly added / changed code files recorded in the change file list with the latest code files to obtain the code to be checked;

[0098] Compile the code to be checked based on the compilation script path, compilation script file name, and compilation output name configured in the YAML configuration file;

[0099] If the compilation fails, this pipeline step fails; otherwise, this pipeline step succeeds and the compiled output is archived to the warehouse management system.

[0100] The static incremental code access control check includes:

[0101] Obtain and scan the baseline version of the code and the code to be reviewed;

[0102] Defect duplication is detected based on the line number change information recorded in the code difference record file, defect issues in the incremental code are obtained, and an incremental static code scanning report is generated;

[0103] The duplication of defect problems based on the line number change information record recorded in the code difference record file refers to changing the line number based on the line number change information record recorded in the code difference record file so that the line number is the same and then duplication of defect problems is determined;

[0104] The duplicate defect detection is used to filter out issues in historical code, and only retain issues newly introduced by the code changes submitted this time;

[0105] If the incremental static code scan report shows that no issues were found, the pipeline step succeeds; if the incremental static code scan report shows that issues were found, the pipeline step fails.

[0106] The static code scanning report includes the scanning rule name corresponding to the defect, the line number where the defect is located, and the defect description.

[0107] The online code review access checks include:

[0108] Get the .svn directory and submit it to the reviewboard platform;

[0109] Run the rbt command on the reviewboard platform to submit the difference record file and log information file to the reviewboard platform;

[0110] Poll the API interface of the reviewboard platform until you get the review form.

[0111] If there are no issues in the review form, the pipeline step succeeds, otherwise the pipeline step fails.

[0112] After the version control system SVN server triggers the pipeline, it polls the pipeline execution results of Jenkins until the pipeline execution results are obtained. Based on the pipeline execution results, it determines whether to submit the incremental code to the version control system SVN code library; the pipeline execution results include success, termination and failure.

[0113] The method for determining whether to submit incremental code to the SVN code base of the version control system based on the pipeline execution results is as follows:

[0114] When the pipeline execution is successful, the incremental code is submitted to the SVN code base of the version control system;

[0115] When pipeline execution is aborted, the incremental code is not submitted to the SVN code repository of the version control system, and the pipeline abort is fed back to the client;

[0116] When a pipeline execution failure is detected, the incremental code is not submitted to the SVN code repository of the version control system, and the failed execution step is fed back to the client.

[0117] Example

[0118] Step 1: Submit incremental code using the Tortoise SVN client on Windows or the Subversion (SVN) client on Linux. This submission triggers the SVN server's pre-commit hook script, also known as the pre-commit hook script. The pre-commit hook script obtains information related to the incremental code submission, which is recorded as incremental code related information. The incremental code related information includes: using the changed-t subcommand of the svnlook command to generate a list of changed files (changed.txt), where each line contains one code file, with newly added files beginning with "A" and changed files beginning with "U"; using the cat subcommand of the svnlook command to obtain newly added or changed code files; using the diff subcommand of the svnlook command to obtain a code difference record file (diff file), specifically, a data file representing the differences between the current text and the last submitted text; and using the log-t subcommand of the svnlook command to obtain log information for the incremental code submission and store it in the log file log.txt. The incremental code refers to the modifications made to any project since the last submission. The log information refers to the submission history recorded in the version control system SVN.

[0119] Step 2: Check the incremental code commit log specifications and trigger pipeline directories. The SVN pre-commit hook script configuration file configures the trigger pipeline directories that trigger the quality control check. If you need to create different pipelines for different trigger pipeline directories, you can pre-configure multiple sets of trigger pipeline directories in the SVN hook script configuration file. The changed file list (changed.txt) described in Step 1 is compared with the trigger pipeline directories in the SVN hook script configuration file to determine whether to trigger pipeline execution. If no identical directories exist after the comparison, the script exits successfully and the code is automatically submitted successfully. If identical directories exist after the comparison, the Jenkins pipeline is automatically triggered remotely. If code from different directories is submitted simultaneously, the client will be informed that simultaneous submission of code from different directories is not allowed. The submitted code triggers different pipelines based on the directory it belongs to.

[0120] In step 2, it also includes checking whether the log file obtained by the pre-submit hook script complies with the log specification. If the submitted log does not comply with the log specification, the feedback client notifies the submitter; the log specification is the log specification; the log specification may include the setting of the timestamp, the setting of the log level, etc.

[0121] The timestamp is used to record the time when the log is generated and can be set as: year-month-day hour:minute:second;

[0122] The log level is used to indicate the importance and urgency of the log, and can be set to: DEBUG, INFO, WARN, etc. Among them, DEBUG-level logs are used to record detailed debugging information, such as variable value changes and function calls during program execution; INFO-level logs highlight the application's running process at a coarse-grained level; WARN-level logs are used to record some problems or non-error conditions that may affect the normal operation of the system.

[0123] Those skilled in the art should understand that the log specification is a series of standards and requirements for log recording, formatting, storage, and management to ensure the validity and readability of logs during software development. Those skilled in the art may modify the specification based on actual conditions.

[0124] Step 3: Package the incremental code information obtained in Step 1 into a submission package. This submission package is then transferred to each Jenkins pipeline execution machine using the scp secure copy command. These execution machines are the ones performing the compilation access control check, static incremental code access control check, and online code review in Step 4. These three types of check execution machines are deployed separately from the Jenkins server, isolating the different access control check environments. This facilitates deployment isolation and reduces the execution pressure on the Jenkins server. The pipeline is then triggered using the Jenkins remote trigger API. This triggering of the pipeline using the Jenkins remote trigger API utilizes the remote trigger API provided by Jenkins to remotely trigger pipeline execution on Jenkins by sending an HTTP request. Specifically, triggering the pipeline using the Jenkins remote trigger API involves passing the submission package name and the SVN repository directory to trigger the pipeline build via a parameterized API. Those skilled in the art will appreciate that parameterized APIs allow for the passing of additional information during invocation. In the present invention, this parameterized API is the first API, which is the Jenkins remote trigger interface. After the Jenkins pipeline is triggered, Jenkins enters step 4.

[0125] Step 4: Jenkins pulls the baseline code from SVN through the various code acquisition steps in the pipeline. Simultaneously, the execution machines in each pipeline step parse the commit package and, based on the files within the parsed commit package, perform compilation checks, Cppcheck static incremental code checks, and Reviewboard online review checks. The pipeline is configured and executed through a combination of Jenkins scripts and various Jenkins YAML configuration files. Specifically, the Jenkins script defines steps such as...; the Jenkins YAML configuration file contains pre-configured parameter settings, and each YAML configuration file uniquely corresponds to a pipeline. Specifically, each code repository corresponds to a pipeline, meaning each code repository has a YAML configuration file. Each pipeline step is configured, primarily including the SVN code repository address, the compilation script path and file name, the compilation output name, the code repository access username and password configured using credentials, the pipeline execution machines for each stage, whether each stage is enabled, the operating system type, and the execution parameters for the execution machine. The compilation script records the steps required in the compilation process to ensure that the source code can be correctly converted into an executable file or library file. Those skilled in the art should know that the code library has a compilation script and those skilled in the art do not need to build it. The credential method is a method in which the code library can be accessed only by providing credentials such as a user name and password. Whether it is enabled, that is, whether the check step is available or skipped. If the compilation stage enable configuration is 0, it means that the compilation stage is skipped. If it is 1, a compilation check is performed. If different pipelines need to be created, those skilled in the art should be able to adjust the configuration of the checks required for different pipelines according to actual conditions. The operating system types include Windows and Linux.

[0126] The compilation access control check method is as follows: the access control check step is executed on the compilation execution machine, specifically obtaining the baseline version code pulled from SVN, replacing the new and changed code files recorded in changed.txt in the submission information package with the latest code files, and compiling and executing according to the compilation script path, compilation script file name and compilation output name obtained from the Jenkins YAML configuration file, and archiving the compilation output to the component warehouse management system artifactory.

[0127] The incremental static code access control check method is: obtain the baseline code of the code base, perform a baseline code scan on the baseline code of the code base based on the code files listed in changed.txt, and then scan the new code again after replacing the latest code according to the submitted information package, and use the line number change information record generated by the diff file to judge the duplication of defects to filter historical problems; after filtering historical problems, generate an incremental static code scanning report. The above scan is performed by the cppcheck scanning command. The scanning command uses the scanning parameters in the yaml configuration file of jenkins, and can set a rule whitelist for the scanning rules. It can determine which rules to scan based on actual business needs. The line numbers generated by the diff command represent the positions of different lines in the new and old code files. The duplicate defect problem detection refers to the fact that the line numbers of the unchanged code segments of the new code and the baseline code may be different, so the problems cannot be detected directly. Instead, the line number change information record is required to change the line number before the duplicate defect problem is detected. The main purpose of the duplicate defect detection is to filter out the problems of the historical code and only retain the problems newly introduced by the code changes submitted this time. Specifically, the duplicate defect problem detection means that the system or tool will analyze the code submitted this time, identify the possible problems therein, and compare these problems with the problems in the historical code to determine which problems are newly introduced by this submission and which already exist in the historical code, filter the problems of the historical code, and only retain the problems newly introduced by the code changes submitted this time. Those skilled in the art should know how to select a system or tool to analyze the problems of the code submitted this time, which will not be repeated here. The scanning parameters must be parameters supported by cppcheck, such as "-j 4" for parallel execution of 4 threads and "--platformunix64" for the target system platform of the program corresponding to the code library to be the unix64 system. The scanning rules refer to the detection logic built into Cppcheck, which is used to identify specific patterns or risks in the code. Those skilled in the art should know how to obtain the scanning rules. Specifically, the scanning rules include judgment rules such as memory leak rules that scan for memory leak defects, uninitialized variable rules that scan for uninitialized variables, and so on. The incremental static code scanning report is a list of defect issues, including the name of the scanning rule corresponding to the defect, the line number where the defect is located, the defect level, and the defect description. The defect level and defect description are automatically generated by a system or tool selected by those skilled in the art.

[0128] The online code review method is as follows:

[0129] After obtaining information about the code repository in the .svn directory, the submitter obtains an authentication token from the ReviewBoard code review platform. Those skilled in the art will understand that the authentication token is the submitter's credential for identity verification and data requests on the ReviewBoard platform. Specifically, when a submitter logs in to the ReviewBoard platform, the server generates an authentication token and returns it to the submitter. Submitters can then use the authentication token to verify their identity when requesting data, eliminating the need to enter a username and password.

[0130] Use a script to process the diff file, and align the paths of the changed files, new files, and deleted files in the file with the code repository path configured on the reviewboard platform. This ensures that there is no overlap between the code repository path on the reviewboard platform and the path of the diff file, and ensures the uniformity of the path format. Then use the authentication token to execute the rbt command on the reviewboard platform, and submit the diff file, log.txt and other information to the reviewboard platform to generate a review form. Since the execution of the rbt submission command requires an environment directory with a .svn directory, the submitter needs to submit the .svn directory to the reviewboard platform in advance; the API interface of the reviewboard platform is recorded as the second API interface, and the link to the second API interface is polled until the review form is obtained. After the review, the pipeline obtains the review status and review form through the second API interface. The review form includes the number of review defects, defect content and other results.

[0131] Those skilled in the art will know that the .svn directory is automatically generated when checking out code from an SVN repository. The .svn directory is a hidden directory used to store version control related information. The version control related information includes metadata, working copy information, etc.

[0132] The metadata is used to record basic information of version control, such as version number, status, etc.

[0133] The working copy information is used to record the status of the local working copy, including which files have been modified and which files need to be updated.

[0134] The information about the code base code includes the version number, submission log, author, timestamp, and locking status of the files in the current directory.

[0135] The pipeline executes in a blocking, serial manner. If an intermediate step fails, the entire pipeline fails. Upon completion, the submitter is notified of the results and other information via email. This blocking, serial execution means that if there is no data to complete a pipeline step, the pipeline will remain stuck at that step until data is available to complete the step.

[0136] After executing each of the above steps, the execution pipeline name, pipeline number, execution status, number of defects, and cppcheck report link are recorded. The recorded contents are stored in a MySQL database for pipeline execution data statistics. A web service based on the Python Tornado framework is established to perform data statistics and report display. Accessing the web link retrieves data from the MySQL database, performs various data aggregation and analysis, and then displays data reports. The data aggregation and analysis includes the number of executions for each pipeline, the number of successes and failures at each stage, the number of defects at each stage, and the average execution time for each stage. Clicking on the number will further drill down to display the detailed information and report of each execution. For example, if the displayed data report shows 3 successes, clicking on the number 3 will display the detailed information and report of each successful execution, including the pipeline number, execution start time, number of defects found, and execution time. The report, i.e., the content of the report generated by cppcheck, can be viewed by clicking on the link of the cppcheck report for each stage in the data report. The average time consumption of a certain stage is the sum of the time consumption of all pipelines in this stage divided by the number of pipelines executing this stage.

[0137] Step 5: After the SVN server triggers the Jenkins pipeline, it begins polling the Jenkins pipeline status. Upon receiving a Success result, the server exits polling mode with the exit 0 code, indicating successful pipeline execution and successful submission of the code to the SVN repository. The client then receives a successful submission. Upon receiving an Aborted result, the server exits polling mode with the exit 1 code, indicating that the pipeline is considered aborted, the code is not submitted to the repository, and pipeline abort information is fed back to the client. Upon receiving a Failed result, the server exits polling mode with the exit 1 code, indicating pipeline execution failure, the code is not submitted to the repository, and pipeline failure information is fed back to the client. The client is the SVN client installed on the local server where the code submitter submits code. Feedback of pipeline abort information to the client indicates that pipeline execution has been aborted. Feedback of pipeline failure information to the client indicates that the failed step has been further determined upon detection of a failure, and information about the failed step is fed back to the client. The information of the failed steps of the pipeline is set as follows:

[0138] Compilation failure feedback is "Build fail"; static code scanning failure feedback is "Cppcheck fail"; online review failure feedback is "Review fail".

[0139] After implementing all the above steps into standard scripts, you can then access various code bases on this basis. This step describes the extended access. Since this system uses a universal script and is equipped with a corresponding configuration file, it is convenient to expand to more code bases.

[0140] Specifically, expanding the pipeline requires copying and configuring the SVN server hook script. This hook script is the pre-commit hook script described in Step 1, and the configuration is the SVN hook script configuration file described in Step 2. Copying the pipeline's Jenkins script and configuring the Jenkins script's YAML file is the same as the one described in Step 4, and the Jenkins script's YAML file is the same as the Jenkins YAML configuration file described in Step 4. Furthermore, configuring the Reviewboard platform primarily supports the online code review process in Step 4. Configuration items primarily include the repository's SVN address, user account, token, and permissions. To connect to this system, you first need to connect the Jenkins platform to your company's domain account. Users must register for a Reviewboard platform account and change the SVN client timeout from the default to no timeout to prevent client timeouts, which can prevent code from being submitted even if the pipeline successfully completes. After completing configuration and debugging, the new codebase is successfully connected to the pipeline.

[0141] This application also discloses a Jenkins SVN continuous integration access control system based on the Jenkins SVN continuous integration access control method, including a hook script trigger module, a pipeline trigger determination module, a pipeline remote trigger module, a code inspection module, and an incremental code submission module:

[0142] The hook script trigger module triggers the pre-submit hook script when the incremental code is submitted by the client of the version control system SVN; the pre-submit hook script obtains the incremental code related information;

[0143] The pipeline trigger determination module obtains the configuration file in the pre-submit hook script, obtains the directory of each triggered pipeline that needs to trigger the quality access control check, and determines whether to trigger each Jenkins pipeline;

[0144] The pipeline remote trigger module transmits the incremental code related information to each execution machine of the pipeline when determining to trigger a certain Jenkins pipeline, and remotely triggers the pipeline based on the server of the version control system SVN;

[0145] The code checking module pulls the baseline version of the code from the version control system SVN based on each execution machine of the pipeline and checks the code;

[0146] The incremental code submission module, after the version control system SVN server triggers the pipeline, polls the pipeline execution results of Jenkins until the pipeline execution results are obtained, and determines whether to submit the incremental code to the version control system SVN code library based on the pipeline execution results; the pipeline execution results include success, termination and failure.

[0147] The system of the present invention further includes a pipeline extension module, in which the SVN continuous integration access control system based on Jenkins proposed by the present invention is extended to a new code base, that is, the new code base is connected to the SVN continuous integration access control system based on Jenkins proposed by the present invention;

[0148] To connect other code bases to the pipeline, you need to configure the following:

[0149] Copy the pre-commit hook script of the version control system SVN server, the configuration file in the pre-commit hook script, the pipeline Jenkins script, and its YAML file for the code base that needs to be connected to the pipeline;

[0150] Configure the Reviewboard platform. Configuration items include the version control system SVN code repository address, Reviewboard platform user account, and authentication token.

[0151] Specifically, expanding the pipeline requires copying and configuring the SVN server hook script. This hook script is the pre-commit hook script described in the hook script trigger module, and the configuration is the SVN hook script configuration file described in the pipeline trigger determination module. The pipeline's Jenkins script must also be copied and configured with the Jenkins script's YAML file. The Jenkins script is the script described in the code review module, and the Jenkins script's YAML file is the Jenkins YAML configuration file described in the code review module. Furthermore, the Reviewboard platform configuration is configured to support the online code review portion of the code review module. Configuration items primarily include the repository's SVN address, user account, token, and permission information. To connect to this system, the Jenkins platform must first be connected to the company's domain account. Users must register for a Reviewboard platform account and change the SVN client timeout from the default to no timeout to prevent client timeouts, which can prevent code from being submitted even if the pipeline successfully completes. After completing configuration and debugging, the new code repository is successfully connected to the pipeline.

[0152] The present disclosure may be a system, method and / or computer program product. The computer program product may include a computer-readable storage medium carrying computer-readable program instructions for causing a processor to implement various aspects of the present disclosure.

[0153] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or a raised structure in a groove on which instructions are stored, and any suitable combination thereof. As used herein, a computer-readable storage medium is not to be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through an electrical wire.

[0154] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in the computer-readable storage medium in each computing / processing device.

[0155] The computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, and conventional procedural programming languages such as "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as an independent software package, partially on a user's computer, partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., utilizing an Internet service provider to connect via the Internet). In some embodiments, an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be personalized by utilizing the state information of the computer-readable program instructions. The electronic circuit may execute the computer-readable program instructions, thereby realizing various aspects of the present disclosure.

[0156] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered by the scope of protection of the claims of the present invention.

Claims

1. A Jenkins-based SVN continuous integration access control method, characterized in that: include: When the client of the version control system makes incremental code submission, the pre-commit hook script is triggered; The pre-submit hook script obtains information related to the incremental code; Get the configuration file in the pre-submit hook script, obtain the directory of each triggered pipeline that needs to trigger the quality gate check, and determine whether to trigger each Jenkins pipeline; When a Jenkins pipeline is triggered, the incremental code information is transmitted to each execution machine of the pipeline, and the pipeline is remotely triggered based on the server of the version control system; Each execution machine based on the pipeline pulls the baseline version of the code from the version control system and checks the code; After the version control system server triggers the pipeline, it polls the pipeline execution results of Jenkins until it obtains the pipeline execution results. Based on the pipeline execution results, it determines whether to submit the incremental code to the version control system code base; The pipeline execution results include success, termination and failure.

2. The SVN continuous integration access control method according to claim 1, characterized in that: The incremental code related information is obtained based on the svnlook command, including: Use the changed-t subcommand to generate a list of changed files; Use the cat subcommand to obtain the newly added or changed code files; Use the diff subcommand to obtain the code difference record file; Use the log -t subcommand to obtain the log information file.

3. The SVN continuous integration access control method according to claim 1, characterized in that: If you need to create different pipelines for different trigger pipeline directories, configure multiple sets of trigger pipeline directories in the configuration file of the pre-submit hook script.

4. The SVN continuous integration access control method according to claim 1, 2 or 3, characterized in that: The determination of whether to trigger pipeline execution is to compare the subdirectories in the changed file list with the subdirectories in each triggered pipeline directory; If the same subdirectory does not exist, exit the pre-submit hook script and submit the code; If the same subdirectory exists, it is determined that the corresponding Jenkins pipeline needs to be triggered.

5. The SVN continuous integration access control method according to claim 1, characterized in that: The execution machines include a compilation execution machine, a static incremental code access control execution machine and an online code review access control execution machine.

6. The SVN continuous integration access control method according to claim 1 or 5, characterized in that: The code is checked based on the incremental code related information; The checks include compilation access control checks, static incremental code access control checks, and online code review access control checks.

7. The SVN continuous integration access control method according to claim 6, characterized in that: The compilation access control check includes: Get the baseline version of the code; In the baseline version code, replace the newly added / changed code files recorded in the change file list with the latest code files to obtain the code to be checked; Compile the code to be checked based on the compilation script path, compilation script file name, and compilation output name configured in the YAML configuration file; Archive compilation output to the warehouse management system.

8. The SVN continuous integration access control method according to claim 2, 6 or 7, characterized in that: The static incremental code access control check includes: Obtain and scan the baseline version of the code and the code to be reviewed; Defect duplication is detected based on the line number change information recorded in the code difference record file, defect issues in the incremental code are obtained, and an incremental static code scanning report is generated; The static code scanning report includes the scanning rule name corresponding to the defect, the line number where the defect is located, and the defect description.

9. The SVN continuous integration access control method according to claim 2 or 6, characterized in that: The online code review access checks include: Get the .svn directory and submit it to the reviewboard platform; Run the rbt command on the reviewboard platform to submit the difference record file and log information file to the reviewboard platform; Poll the API interface of the reviewboard platform until you get the review form.

10. The SVN continuous integration access control method according to claim 1, characterized in that: The method for determining whether to submit incremental code to the version control system code base based on the pipeline execution results is as follows: When the pipeline execution is successful, the incremental code is submitted to the version control system code base; When pipeline execution is aborted, the incremental code is not submitted to the version control system code base, and the pipeline abort is fed back to the client; When a pipeline execution failure is detected, the incremental code is not submitted to the version control system code base, and the failed execution step is fed back to the client.

11. An SVN continuous integration access control system using the SVN continuous integration access control method according to any one of claims 1 to 10, characterized in that: Including hook script trigger module, pipeline trigger determination module, pipeline remote trigger module, code inspection module and incremental code submission module: The hook script triggering module triggers the pre-submit hook script when the client of the version control system submits incremental code; The pre-submit hook script obtains information related to the incremental code; The pipeline trigger determination module obtains the configuration file in the pre-submit hook script, obtains the directory of each triggered pipeline that needs to trigger the quality access control check, and determines whether to trigger each Jenkins pipeline; The pipeline remote trigger module transmits the incremental code related information to each execution machine of the pipeline when determining to trigger a Jenkins pipeline, and remotely triggers the pipeline based on the server of the version control system; The code checking module pulls the baseline version of the code from the version control system based on each execution machine of the pipeline and checks the code; The incremental code submission module, after the version control system server triggers the pipeline, polls the pipeline execution result of Jenkins until the pipeline execution result is obtained, and determines whether to submit the incremental code to the version control system code library based on the pipeline execution result.

12. The SVN continuous integration access control system according to claim 11, characterized in that: Also includes pipeline extension modules: In the pipeline extension module, the following configuration is required to connect other code bases to the pipeline: Copy the pre-commit hook script of the version control system server, the configuration file in the pre-commit hook script, the pipeline Jenkins script, and its YAML file for the code base that needs to be connected to the pipeline; Configure the Reviewboard platform. Configuration items include the version control system code repository address, Reviewboard platform user account, and authentication token.

Images