Test continuous integration method, system and storage medium based on submission flag driving

Abstract

This invention discloses a continuous integration testing method, system, and storage medium driven by submission flags, relating to the field of continuous integration testing technology. The method includes: acquiring code push events, extracting submission description information, and scanning flags; if a registration class flag is detected, automatically parsing the test project name, inferring the test type, retrieving the project path, and writing the project information into a test case library; if a test type flag is detected, selecting the corresponding type of test project, compiling it, and writing back the build status; then selecting projects with a passed build status, parsing standardized test results, and writing back the test status; finally, traversing the test case library, and based on the responsible person identifier mapping relationship, instantly mentioning the responsible person to the failed project submitter's identifier. This invention achieves a fully automated closed loop of test triggering and code submission strong binding, selective test type scheduling, and precise targeted notification of the responsible person for failures.

Description

Technical Field

[0001] This application relates to the field of continuous integration technology for software testing, and in particular to a C++ continuous integration method and system based on commit flags. Background Technology

[0002] Continuous Integration (CI) is a crucial practice in modern software engineering. Its core idea is to frequently merge code changes from developers into a shared code repository and promptly identify integration issues through automated build and testing processes, thereby reducing defect fixing costs and improving software delivery quality. In industrial-grade C++ software development scenarios, especially in the field of embedded control software, the need for test automation is particularly urgent. C++ projects typically include various test types such as unit tests, interface tests, and module tests. The large number of test projects and complex compilation dependencies place high demands on the scheduling capabilities of continuous integration systems.

[0003] In existing continuous integration testing solutions, a common approach is to trigger a predefined build pipeline using hook scripts in the version control system, thereby automatically running tests after code commits. For example, CN109542769A discloses an automated testing method for continuous integration. This method configures hook scripts on the SVN service to call the Jenkins service to build automated tests. Each time code associated with a task number is committed, the hook script triggers the continuous integration tool to schedule test execution. After the test is completed, feedback information is pushed to the responsible party via email or instant messaging. However, the above solutions have the following shortcomings: First, the triggering granularity is coarse. Every code commit triggers the full test pipeline, making it impossible to selectively execute specific types of tests based on the actual scope of the commit content. This results in test projects unrelated to the current changes consuming a large amount of build resources. Second, test project integration relies on manual configuration. Every time a new test project is created, developers must manually modify the pipeline configuration file of the continuous integration tool to add the new project path to the build script. This operation is cumbersome and prone to configuration conflicts in multi-person collaboration scenarios. Third, the test result notification mechanism is imperfect. The above solutions typically only support sending unified notifications to preset fixed recipients and cannot provide precise targeted notifications based on the actual committer of the failed project, thus limiting the efficiency of problem response.

[0004] CN115982011A discloses a continuous automated testing platform for improving software quality. This platform uses a continuous integration server to monitor repository status, schedule execution, and trigger polling to integrate and execute testing tools, and supports automatic test report feedback. However, the test triggering mechanism in this solution is still primarily based on full triggering, lacking fine-grained scheduling methods based on code commit content; the access management of test projects also relies on pre-configured build scripts, requiring manual maintenance of the platform configuration when adding new test projects; furthermore, test result notifications are mainly uniform broadcasts, without providing targeted notification capabilities associated with the specific responsible party for failed projects.

[0005] Therefore, a new technical solution is needed to address the problems in existing continuous integration testing systems, such as the lack of selective scheduling of test types based on code commit content in the test pipeline, the need for manual modification of configuration files for test project access, and the inability to proactively notify the responsible parties of test results with accurate correlation. Summary of the Invention

[0006] The purpose of this invention is to provide a continuous integration testing method, system, and computer-readable storage medium driven by commit flags, in order to solve the problems in existing continuous integration testing systems, such as the lack of selective scheduling of test types based on code commit content, the need for manual modification of configuration files for test project access, and the inability to proactively notify the responsible party of test results with accurate correlation.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: A continuous integration test method driven by commit flags is applied to a continuous integration server. It obtains code push events from the code repository through an event push interface configured to the code repository, and extracts the commit description information corresponding to the code push events. The commit description information is then scanned for flags to identify registration class flags and test type flags. If a registration class flag is detected, the test project name is parsed from the commit description information, the test type is inferred from the test project name, and the project path of the test project is retrieved from the commit file information corresponding to the code push event. The test project name, test type, project path, and committer identifier are written into a test case library in a structured format. If a test type flag is detected, the test case library is read, test projects corresponding to the test type flag are selected, and each test project is compiled in a specified build environment. The build status is written back to the test case library; test projects with a build status of "passed" are also selected from the test case library, and the test executable files of each test project are executed one by one through subprocess calls, with a timeout protection mechanism set, the standardized test result files output by each test project are parsed, and the test status of each test project is written back to the test case library. The execution process of each test project is independent of each other; the test case library is traversed, the build status and test status of each test project are counted, and a visual test report is generated; according to the preset responsible person identifier mapping relationship, the submitter identifier corresponding to the failed test project is converted into an instant messaging platform user identifier, and a structured message containing a summary of the test results and a link to the visual test report is pushed to the R&D group through an instant messaging robot, and the responsible person corresponding to the failed project is mentioned in the structured message; if no flag is scanned, the current pipeline is terminated.

[0008] Preferably, when the submission description information contains multiple test type flag bits, the test pipelines corresponding to each test type flag bit are triggered sequentially according to the preset test type priority order.

[0009] Preferably, when performing the registration step triggered by the registration class flag, if the project path of the test project is not found in the submitted file information, an alarm notification is sent to the instant messaging account corresponding to the submitter identifier, and the registration operation is skipped; if a record corresponding to the test project name already exists in the test case library, the project path field and submitter identifier field of the record are updated.

[0010] Preferably, before executing the test executable files of each test project through subprocess calls, it is verified that the test executable files corresponding to each test project actually exist in the file system; if the test executable files do not exist, the test status of the test project is marked as failed, and the remaining test projects in the queue to be executed are processed.

[0011] Preferably, the timeout protection mechanism has a timeout limit of 200 to 600 seconds; when the execution time of the test executable file of a certain test project exceeds the timeout limit, the subprocess corresponding to the test project is forcibly terminated, and the test status of the test project is marked as timeout failure.

[0012] Preferably, the structured message adopts Markdown format, and the content of the structured message includes the overall test pass rate, a list of failed project names, a list of failed test project names and corresponding failed test cases, and a direct link to the visual test report.

[0013] A continuous integration test system driven by commit flags includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the following functional modules: a flag scanning module, used to obtain code push events from the code repository through an event push interface configured to the code repository, extract the commit description information corresponding to the code push event, and perform flag scanning on the commit description information to identify registration class flags and test type flags; an automatic registration module, data-connected to the flag scanning module, used to parse the test project name from the commit description information when the registration class flag is detected, infer the test type based on the test project name, retrieve the project path from the commit file information corresponding to the code push event, and write the test project name, test type, project path, and submitter identifier into a test case library in a structured format; and a compilation scheduling module, data-connected to the flag scanning module and the automatic registration module, used to read the test case library when the test type flag is detected. The system performs several steps: First, it filters test projects corresponding to the test type flag. Then, it compiles each test project in a specified build environment and writes the build status of each test project back to the test case library. Next, it executes a parsing module connected to the compilation scheduling module. This module filters test projects with a passed build status from the test case library, executes the test executable files of each test project one by one via subprocess calls, sets a timeout protection mechanism, parses the standardized test result files output by each test project, and writes the test status of each test project back to the test case library. Finally, it sends a notification push module connected to the execution parsing module. This module iterates through the test case library to statistically analyze the build and test status of each test project, generates a visual test report, converts the submitter identifier of a failed test project into an instant messaging platform user identifier based on a preset responsible person identifier mapping relationship, and pushes a structured message containing a summary of the test results and a link to the visual test report to the development group via an instant messaging robot. The message also includes a targeted mention of the responsible person for the failed test project.

[0014] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described continuous integration testing method.

[0015] The beneficial effects of this invention are: (1) By embedding the test type flag in the submission description information, selective triggering of the test pipeline is achieved, which solves the problem of coarse triggering granularity and the consumption of a lot of build resources by irrelevant test projects in the existing solution, and makes the test execution scope and code modification scope accurately match. (2) The test project name, type, path and submitter identifier are automatically written into the test case library through the test project automatic registration mechanism driven by the registration class flag. No continuous integration configuration file needs to be modified when creating a new test project, which solves the problem that test project access depends on manual configuration and that configuration conflicts are easy to occur in multi-person collaboration. (3) By converting the identifier of the submitter of the failed project into the identifier of the instant messaging platform through the preset responsible person identifier mapping relationship, and combining the direct link of the visual test report, the test results are pushed to the R&D group in the form of structured messages and the responsible persons of the failed projects are mentioned in a targeted manner. This solves the problem that the existing solution notification mechanism is imperfect and cannot accurately target the responsible persons, and changes the test result notification from passive viewing to active notification. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a continuous integration testing method driven by a commit flag. Detailed Implementation

[0017] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0018] Example 1: like Figure 1 As shown, this embodiment discloses a continuous integration test method driven by a commit flag, applied to a continuous integration server, to achieve a fully automated closed loop from code push event capture to test execution, report generation, and result notification. The method includes the following steps: Step S101: The continuous integration server obtains code push events from the code repository through the event push interface configured in the code repository, and extracts the commit description information corresponding to the code push event. Specifically, the continuous integration server configures an event push interface on the code push event hook of the code repository. When a developer performs a code push operation to the code repository, the code repository sends a code push event data packet containing commit description information, commit file information, and committer identifier to the continuous integration server. The continuous integration server extracts the commit description information from the data packet, which is the commit description text filled in by the developer when performing the code push.

[0019] Step S102: Scan the submission description information for flag bits to identify registration class flag bits and test type flag bits. Specifically, the continuous integration server performs regular expression matching on the extracted submission description information to scan whether it contains registration class flag bits or test type flag bits; the registration class flag bit is used to trigger the automatic registration process of the test project, and the test type flag bit is used to trigger the compilation and execution pipeline of the corresponding type of test project; if no flag bits are scanned, the current pipeline is terminated, no build record is generated, and no notification is pushed.

[0020] Step S103: If a registration flag is detected, the automatic registration process for the test project is executed. Specifically, the continuous integration server parses the test project name from the submission description information, infers the test type based on the naming rules of the test project name, retrieves the project path of the test project from the submission file information corresponding to the code push event, and writes the test project name, test type, project path, and submitter identifier into the test case library in a structured format. If a record corresponding to the test project name already exists in the test case library, the project path field and submitter identifier field of that record are updated. If no project path is found, an alarm notification is sent to the instant messaging account corresponding to the submitter identifier, and the registration operation is skipped.

[0021] Step S104: If a test type flag is detected, the test case library is read, the test projects corresponding to the test type flag are selected, and each test project is compiled in the specified build environment. The build status of each test project is then written back to the test case library. Specifically, the continuous integration server reads all project records in the test case library whose test types match the test type flag, and sequentially performs compilation operations on each test project in the specified build environment. If compilation is successful, the build status field of the project is marked as passed; if compilation fails, it is marked as failed, and the compilation error summary is also written back to the test case library.

[0022] Step S105: Select test projects with a pass build status from the test case library, execute the test executable files of each test project one by one through subprocess calls, set a timeout protection mechanism, parse the standardized test result files output by each test project, and write the test status of each test project back to the test case library. The execution process of each test project is independent of each other. Specifically, the continuous integration server selects project records with a pass build status from the test case library and verifies that the test executable files corresponding to each project actually exist in the file system. If the test executable files do not exist, the test status of the test project is marked as failed, and the remaining test projects in the execution queue are processed. For the test projects that have passed the verification, the test executable files of each project are executed one by one through subprocess calls, and a timeout protection mechanism is set. The timeout limit is 200 seconds to 600 seconds, with a default of 300 seconds. When the execution time of the test executable file of a certain test project exceeds the timeout limit... When the test fails, the child process corresponding to the test project is forcibly terminated, and the test status of the test project is marked as timeout failure. The execution process of each test project is independent of each other. The failure or timeout of a single project does not interrupt the testing of other projects. When the test executable file is executed, the test results are written to the standardized test result file in the specified path by means of command line parameters. The continuous integration server parses the standardized test result file, counts the number of failed test cases, and if the number of failed test cases is zero, the test status of the project is marked as passed. Otherwise, it is marked as failed, the list of failed test case names is extracted, and the above test status is written back to the test case library.

[0023] Step S106: Traverse the test case library, statistically analyze the build and test status of each test project, and generate a visual test report. Specifically, after the compilation and execution of all test types are completed, the continuous integration server traverses all project records in the test case library, statistically analyzes the number and names of failed build projects, the number of failed test projects and their corresponding failed test case lists, the number of successful test projects, the overall test pass rate, and other information; simultaneously, it calls the visual report generation tool to scan the test result directory, batch converts the standardized test result files output by each project into visual report data, and generates a visual test report, which can be accessed via a fixed link.

[0024] Step S107: Based on the preset responsible person identifier mapping relationship, the submitter identifier corresponding to the failed test project is converted into an instant messaging platform user identifier. A structured message containing a summary of the test results and a link to a visual test report is pushed to the development group via an instant messaging robot. The responsible person for the failed project is specifically mentioned in the structured message. Specifically, the continuous integration server formats the results information collected in step S106 into a structured message and sends the structured message to the development group through the interface of the instant messaging robot. When assembling the structured message, the submitter identifier in the failed project record is used as the key to find the corresponding instant messaging platform user identifier in the preset responsible person identifier mapping relationship, and the instant messaging platform user identifier is mentioned in the message. If the submitter identifier is not registered in the responsible person identifier mapping relationship, the responsible person information is noted in text form in the message, and the notification is not blocked due to the missing mapping. The structured message adopts Markdown format. The content of the structured message includes the overall test pass rate, a list of failed project names, a list of failed test project names and corresponding failed test cases, and a direct link to the visual test report.

[0025] When the submission description information contains multiple test type flags, the test pipelines corresponding to each test type flag are triggered sequentially according to the preset test type priority order. That is, after the compilation and execution of the first test type are completed in sequence, the compilation and execution of the second test type are started, until all test types are processed.

[0026] In this embodiment, by embedding registration class flags and test type flags in the submission description information, intent-driven selective triggering of the test pipeline is achieved: when the submission description information does not contain any flags, the pipeline terminates immediately, without generating invalid build records, thus avoiding the consumption of build resources by irrelevant test projects; when it contains test type flags, only the corresponding type of test pipeline is triggered, ensuring precise matching between the test execution scope and the code modification scope, achieving a strong binding between test triggering and code submission. By mapping the responsible party's identifier to the identifier of the failed project submitter, the identifier of the instant messaging platform user is converted, and the responsible party is specifically mentioned, transforming test result notification from passive viewing to proactive notification, significantly improving the problem response speed. Furthermore, when the submission description information contains multiple test type flags simultaneously, each type of test pipeline is triggered sequentially according to a preset priority order, achieving orderly scheduling of multiple test types and avoiding resource contention.

[0027] Example 2: This embodiment discloses a detailed implementation of the automatic registration sub-process of the test project, which corresponds to the specific expansion of step S103 in Embodiment 1, and supports the logic of registration exception handling and test case library update.

[0028] Step S201: The continuous integration server extracts the test project name carried by the registration class flag from the submission description information. Specifically, the format of the registration class flag is a combination of registration keywords and project name in the submission description information. The continuous integration server parses the test project name string from the combination text using regular expressions, for example, the project name is "ProjectA_UT".

[0029] Step S202: Infer the test type based on the naming rules of the test project name. Specifically, the continuous integration server determines the test type based on the suffix of the test project name: if the project name ends with "_UT", the test type is inferred to be a unit test; if the project name ends with "_IT", the test type is inferred to be an interface test; if the project name ends with "_MT", the test type is inferred to be a module test. The above naming rules are agreed upon in advance by the development team and maintained in the configuration file of the continuous integration server.

[0030] Step S203: Retrieve the project path of the test project from the commit file information corresponding to the code push event. Specifically, the continuous integration server traverses the list of changed files included in this code push event, matches the directory path containing the name of the test project in each file path, and records the matched directory path as the project path.

[0031] Step S204: Determine whether the project path has been found. If the project path has not been found, proceed to step S205; if the project path has been found, proceed to step S206.

[0032] Step S205: Send an alarm notification to the instant messaging account corresponding to the submitter identifier and skip this registration operation. Specifically, the continuous integration server sends an alarm message to the submitter's instant messaging account via an instant messaging robot. The message content includes an explanation that the project name and path were not found, prompting the submitter to check the submitted files; this registration operation is terminated, no data is written to the test case library, and the continuous integration server continues to process subsequent processes.

[0033] Step S206: Determine whether a record corresponding to the test project name already exists in the test case library. If it exists, proceed to step S207; otherwise, proceed to step S208.

[0034] Step S207: Update the project path field and submitter identifier field of existing records in the test case library. Specifically, the continuous integration server locates records in the test case library with the same project name as the test project name, updates the project path field of the record to the project path retrieved in step S203, updates the submitter identifier field to the submitter identifier of this code push event, and retains the remaining fields such as test type, historical build status, and historical test status unchanged.

[0035] Step S208: Append a new record to the test case library. Specifically, the continuous integration server assembles the test project name, inferred test type, retrieved project path, and submitter identifier into a new record in a structured format and appends it to the test case library file. The build status field and test status field in the new record are initialized to empty values, waiting to be filled in during the subsequent compilation and execution phases.

[0036] In this embodiment, the automatic test project registration mechanism driven by the registration class flag allows developers to automatically complete project name resolution, test type inference, project path retrieval, and test case library writing simply by including the registration class flag in the submission description. Creating a new test project requires no modification to any continuous integration configuration files, eliminating the risk of configuration conflicts in multi-user collaboration scenarios. When the project path is not found, the system sends an alert to the submitter and skips the registration, ensuring the robustness of the registration process. When the project name already exists in the test case library, the system automatically updates the project path and submitter identifier fields, achieving idempotent maintenance of test project information.

[0037] Example 3: This embodiment discloses a detailed implementation of the test case compilation and execution sub-process, which corresponds to the specific expansion of steps S104 and S105 in Embodiment 1, and supports pre-execution file verification and timeout protection mechanisms.

[0038] Step S301: Read the test case library, filter all test project records corresponding to the current test type flag, and obtain the project path and expected generation path of the test executable file for each project. Specifically, the continuous integration server reads the test case library file, iterates through all project records whose test type field matches the current test type flag, extracts the project path field and expected generation path field of the test executable file from each record, and constructs a list of projects to be compiled.

[0039] Step S302: Perform build environment initialization. Specifically, the continuous integration server initializes the build toolchain according to the configuration requirements of the specified build environment, including setting the compiler executable file path, build tool version, and related environment variables to ensure that subsequent compilation operations are performed in a consistent build environment.

[0040] Step S303: Perform compilation operations on each test project in the list of projects to be compiled in sequence, and write the compilation results back to the test case library. Specifically, the continuous integration server traverses the list of projects to be compiled, executes the compilation command for each test project, and outputs the compilation artifacts to the directory specified by the expected generation path field in the project record; if the compilation is successful, the build status field of the project record is marked as passed, and if the compilation fails, it is marked as failed and the compilation error summary is written back to the test case library; after the traversal is completed, the build status fields of all projects to be compiled in the test case library have been updated.

[0041] Step S304: Filter test projects with a build status of "passed" from the test case library, and verify that the test executable files corresponding to each project actually exist in the file system. Specifically, the continuous integration server reads the test case library, filters project records with a build status of "passed," and for each filtered record, reads the expected generation path field of its test executable file, checking whether the executable file pointed to by that path actually exists in the file system.

[0042] Step S305: Determine if the test executable file exists. If it does not exist, mark the test status of the test project as failed and continue processing the remaining test projects in the execution queue; if it exists, add the test project to the execution queue.

[0043] Step S306: Execute the test executables of each test project in the execution queue one by one using subprocess calls, and set a timeout protection mechanism. Specifically, the continuous integration server traverses the execution queue, starts the corresponding test executable for each test project using subprocess calls, and specifies the test result output path using command-line parameters during the call. The test executable is required to write the test results to a standardized test result file at the specified path when the process exits. At the same time, a timeout protection is set for each subprocess, with a timeout limit of 200 to 600 seconds, and a default of 300 seconds. When the execution time of the test executable of a certain test project exceeds the timeout limit, the subprocess corresponding to that test project is forcibly terminated, and the test status of that test project is marked as timeout failure. The next test project in the execution queue is then processed. The execution process of each test project is independent of each other, and the failure or timeout of a single project does not interrupt the testing of other projects.

[0044] Step S307: Parse the standardized test result files output by each test project and write the test status of each test project back to the test case library. Specifically, the continuous integration server reads the standardized test result files generated in step S306 for each test project. The standardized test result files are in JUnitXML format. The continuous integration server parses the JUnitXML format files and counts the number of failed test cases. If the number of failed test cases is zero, the test status field of the project in the test case library is marked as passed. If the number of failed test cases is greater than zero, the test status field of the project is marked as failed, and the list of failed test case names is written to the test case library. After all test projects have been processed, the test status fields of all projects in the test case library have been updated.

[0045] In this embodiment, by verifying the actual existence of the test executable file in the file system before execution, execution anomalies caused by missing compilation artifacts are avoided. The execution processes of each test project are independent of each other, and the failure or timeout of a single project does not interrupt the testing of other projects, thus achieving fault isolation. The timeout protection mechanism (timeout limit of 200 to 600 seconds) effectively prevents the pipeline from being blocked for a long time due to test project suspension, forcibly terminates timeout child processes and marks timeout failures, ensuring the robustness and timeliness of the test process.

[0046] Example 4: This embodiment discloses a test continuous integration system driven by a commit flag, including a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the following functional modules.

[0047] The flag scanning module is used to obtain code push events from the code repository through the event push interface configured to the code repository, extract the commit description information corresponding to the code push event, and perform flag scanning on the commit description information to identify the registration class flag and the test type flag. Specifically, the flag scanning module listens for code push events from the code repository. After receiving a code push event, it extracts the commit description information from the event data packet, performs regular expression matching on the commit description information, and outputs the flag type and flag value for use by subsequent modules.

[0048] The automatic registration module, connected to the flag scanning module, is used to parse the test project name from the submission description information when a registration class flag is detected. It infers the test type based on the test project name, retrieves the project path from the submission file information corresponding to the code push event, and writes the test project name, test type, project path, and submitter identifier into the test case library in a structured format. The automatic registration module receives the registration class flag value and code push event data output by the flag scanning module, and completes the project name parsing, test type inference, project path retrieval, and test case library writing or updating operations. If the project path is not found, an alarm notification is sent to the submitter via instant messaging, and the registration is skipped.

[0049] The compilation scheduling module, data-connected to the flag scanning module and the automatic registration module, is used to read the test case library when a test type flag is detected, filter the test projects corresponding to the test type flag, compile each test project in a specified build environment, and write the build status of each test project back to the test case library. The compilation scheduling module receives the test type flag value output by the flag scanning module, reads the test case library maintained by the automatic registration module, filters the project records of the corresponding type, sequentially performs the compilation operation in the specified build environment, and updates the build status field of the test case library with the compilation results.

[0050] The execution parsing module is connected to the compilation scheduling module and is used to filter test projects with a build status of "pass" from the test case library. It executes the test executable files of each test project one by one through subprocess calls, sets a timeout protection mechanism, parses the standardized test result files output by each test project, and writes the test status of each test project back to the test case library. The execution process of each test project is independent of each other.

[0051] The execution parsing module includes the following three sub-modules: a queue construction sub-module, used to filter test projects with a pass construction status from the test case library, verify that the test executable files corresponding to each test project actually exist in the file system, and organize the verified test projects into an ordered queue to be executed; if the test executable file does not exist, the test status of the corresponding test project is marked as failed and not added to the queue to be executed; a sub-process execution sub-module, which is data-connected to the queue construction sub-module, used to execute the test executable files of each test project in the queue to be executed one by one through sub-process calls, and implement a timeout protection mechanism with a timeout limit of 200 seconds to 600 seconds. After the timeout, the corresponding sub-process is forcibly terminated and marked as timeout failure. The execution process of each test project is independent of each other; and a result parsing sub-module, which is data-connected to the sub-process execution sub-module, used to parse the standardized test result files output by each test project, count the number of failed test cases, and write back the test status of each test project to the test case library.

[0052] The notification push module, connected to the execution parsing module, it iterates through the test case library to statistically analyze the build and test status of each test project, generates a visual test report, and converts the submitter's identifier corresponding to a failed test project into an instant messaging platform user identifier based on a preset responsible person identifier mapping relationship. It then pushes a structured message containing a summary of the test results and a link to the visual test report to the development group via an instant messaging robot, specifically mentioning the responsible person for the failed project within the structured message. The notification push module also reads the updated test case library from the execution parsing module, calls the visual report generation tool to generate a visual test report, assembles a structured notification message based on the responsible person identifier mapping relationship, and pushes the message through the instant messaging robot interface.

[0053] In this embodiment, the system uses a test case library as the core data storage. Each functional module achieves state transfer by reading and writing to the test case library, resulting in low coupling between modules and facilitating independent maintenance and expansion. The three sub-modules within the execution parsing module (queue construction sub-module, subprocess execution sub-module, and result parsing sub-module) have clearly defined responsibilities, and each sub-module independently processes data at its corresponding stage, further improving the maintainability and testability of the system.

[0054] In summary, the present invention has the following beneficial effects based on the above embodiments: (1) Selective triggering of the test pipeline is achieved by using the test type flag, and the test execution scope is precisely matched with the code modification scope, avoiding irrelevant tests from consuming build resources; (2) Through the automatic registration mechanism driven by the registration class flag, no continuous integration configuration file needs to be modified when creating a new test project, eliminating the risk of configuration conflicts in multi-person collaboration; (3) By designing the timeout protection mechanism and the execution process of each project independently, fault isolation is achieved, ensuring the robustness of the test process; (4) By mapping the responsible person's identifier and using the targeted mention mechanism of the instant messaging robot, the notification of test results is transformed from passive viewing to proactive notification, accurately reaching the responsible persons of the failed project; (5) By attaching a direct link to the visual test report to the structured Markdown format message, the cost of problem location is reduced and the problem response efficiency of the R&D team is improved.

[0055] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several modifications and improvements can be made without departing from the inventive concept of this application, and these all fall within the protection scope of this application.

Claims

1. A test continuous integration method based on commit flag driving, applied to a continuous integration server, characterized in that, include: Obtain the code push event and extract the corresponding submission description information, perform flag bit scanning on the submission description information, and identify the registration class flag bit and test type flag bit; If a registration class flag is detected, the test project name is parsed from the submission description information, the test type is inferred from the test project name, the project path is retrieved from the submission file information corresponding to the code push event, and the test project name, test type, project path, and submitter identifier are written into the test case library in a structured format; if a test type flag is detected, the test case library is read, the test projects corresponding to the test type flag are selected, each test project is compiled in the specified build environment, and the build status of each test project is written back to the test case library. The test cases are selected from the test case library and the test projects with a pass build status are executed. The test status of each test project is written back to the test case library. The test case library is traversed, and the submitter identifier corresponding to the failed test project is converted into an instant messaging platform user identifier according to the preset responsible person identifier mapping relationship. The responsible person corresponding to the failed test project is mentioned in a targeted manner in real time.

2. The test continuous integration method of claim 1, wherein, When the submission description information contains multiple test type flags, the test pipelines corresponding to each test type flag are triggered sequentially according to the preset test type priority order.

3. The test continuous integration method of claim 2, wherein, When performing the registration step triggered by the registration flag, if the project path of the test project is not found in the submitted file information, an alarm notification is sent to the instant messaging account corresponding to the submitter identifier, and the registration operation is skipped.

4. The test continuous integration method of claim 1, wherein, When writing the test project name, test type, project path, and submitter identifier into the test case library, if a record corresponding to the test project name already exists in the test case library, then the project path field and submitter identifier field of that record are updated.

5. The continuous integration testing method according to claim 1, characterized in that, The execution of test projects with a pass build status specifically involves: verifying that the test executable file corresponding to the test project with a pass build status actually exists in the file system; executing the test executable file of each test project through a child process call method; setting a timeout protection mechanism; parsing the standardized test result file output by each test project; and ensuring that the execution process of each test project is independent of each other. If the test executable file does not exist, the test status of the corresponding test project is marked as failed, and the remaining test projects in the queue to be executed continue to be processed.

6. The continuous integration testing method according to claim 5, characterized in that, The timeout protection mechanism has a timeout limit of 200 to 600 seconds. When the execution time of the test executable file of a certain test project exceeds the timeout limit, the child process corresponding to the test project is forcibly terminated, and the test status of the test project is marked as timeout failure.

7. The continuous integration testing method according to any one of claims 1-6, characterized in that, A structured message containing a summary of test results and a link to a visual test report is pushed to the R&D group via an instant messaging robot. The responsible person for the failed project is specifically mentioned in the structured message. The structured message is in Markdown format and includes the overall test pass rate, a list of failed project names, a list of failed test project names and corresponding failed test cases, and a direct link to the visual test report.

8. A continuous integration test system driven by a commit flag, comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it implements the following functional modules: The flag scanning module is used to obtain code push events and extract corresponding submission description information, and to perform flag scanning on the submission description information to identify registration class flags and test type flags; The automatic registration module is data-connected to the flag scanning module. When the registration class flag is scanned, it parses the test project name from the submission description information, infers the test type based on the test project name, retrieves the project path from the submission file information corresponding to the code push event, and writes the test project name, test type, project path and submitter identifier into the test case library in a structured format. The compilation scheduling module is data-connected to the flag scanning module and the automatic registration module. When the test type flag is scanned, it reads the test case library, filters and executes test projects with a build status of "pass", and writes the test status of each test project back to the test case library. The execution parsing module is connected to the compilation scheduling module and is used to filter test projects with a build status of "pass" from the test case library. It executes the test executable files of each test project one by one through subprocess calls, sets a timeout protection mechanism, parses the standardized test result files output by each test project, and writes the test status of each test project back to the test case library. The execution process of each test project is independent of each other. The notification push module is connected to the execution parsing module and is used to traverse the test case library. According to the preset responsible person identifier mapping relationship, the submitter identifier corresponding to the failed test project is converted into the instant messaging platform user identifier, and the responsible person corresponding to the failed project is immediately mentioned.

9. The continuous integration testing system according to claim 8, characterized in that, The execution parsing module includes: The queue construction submodule is used to filter test projects with a construction status of "passed" from the test case library, verify that the test executable files corresponding to each test project actually exist in the file system, and organize the verified test projects into an ordered queue to be executed. The subprocess execution submodule is data-connected to the queue construction submodule. It is used to execute the test executable files of each test project in the queue to be executed one by one through the subprocess call method, and implements a timeout protection mechanism. The execution process of each test project is independent of each other. The result parsing submodule is connected to the subprocess execution submodule and is used to parse the standardized test result files output by each test project and write back the test status of each test project to the test case library.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that, when executed by a processor, implements the steps of the continuous integration testing method according to any one of claims 1 to 7.

Images