Code repair method and device in continuous integration environment and related equipment

Abstract

This disclosure provides a code repair method, apparatus, and related equipment in a continuous integration environment, relating to the field of software technology. The method includes: triggering a continuous integration pipeline task for the target code branch in response to a code merge request; monitoring the task status information of the continuous integration pipeline task and its subtasks during execution; if the continuous integration pipeline task has completed execution but at least one subtask has failed, acquiring the task status information and execution log information of all failed subtasks, and integrating this information with the code change content corresponding to the code merge request, code context information, and code execution environment information to obtain multi-dimensional fault correlation analysis information; inputting the multi-dimensional fault correlation analysis information into a pre-trained code repair model to output a code repair solution. This disclosure can significantly improve the efficiency and accuracy of code repair in a continuous integration environment.

Description

Technical Field

[0001] This disclosure relates to the field of software development technology, and in particular to a code repair method, apparatus and related equipment in a continuous integration environment. Background Technology

[0002] In the continuous integration process under the DevOps system, the pipeline execution is automatically triggered after a code merge request is initiated. The pipeline includes a series of automated tasks such as code retrieval, compilation and building, unit testing, integration testing, image packaging, deployment and verification. Through pipeline tasks, problems such as syntax errors, logical defects, and dependency conflicts can be detected in time before the code is merged into the main branch, which is a key line of defense to ensure code quality.

[0003] With the increasing complexity of software systems and the popularization of microservice architecture, pipeline task chains are becoming longer and longer, and scenarios of multi-task parallel or serial execution are becoming more and more common. Pipeline task execution failure has become a high-frequency event in the R&D process.

[0004] Traditional fault handling requires developers to manually locate failed tasks, check scattered error logs, compare code differences, and resubmit after fixing to trigger the pipeline. This highly relies on manual intervention, resulting in low troubleshooting efficiency, long processing cycles, and susceptibility to human error. It makes it difficult to fully leverage the automation value of the DevOps system and also affects the timely delivery of products.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] This disclosure provides a code repair method, apparatus, and related equipment in a continuous integration environment, which at least to some extent overcomes the technical problems in related technologies where fault location and code repair after the continuous integration pipeline fails rely entirely on manual processing, resulting in low troubleshooting efficiency, long processing cycles, and susceptibility to errors.

[0007] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0008] According to one aspect of this disclosure, a code repair method in a continuous integration environment is provided, comprising: in response to a code merge request, triggering a continuous integration pipeline task of a target code branch, wherein the continuous integration pipeline task includes: multiple subtasks automatically executed in a preset order; during the execution of the continuous integration pipeline task, monitoring the task status information of the continuous integration pipeline task and each subtask; when the continuous integration pipeline task is completed and at least one subtask fails, obtaining the task status information and execution log information of all failed subtasks in the continuous integration pipeline task, and integrating them in multiple dimensions with the code change content, code context information, and code execution environment information corresponding to the code merge request to obtain multi-dimensional fault correlation analysis information of the continuous integration pipeline task; inputting the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model, and outputting a code repair scheme, wherein the code repair scheme is used to repair the code requested to be merged by the code merge request, so that the repaired code completes the execution of the continuous integration pipeline task and there are no failed subtasks.

[0009] In some embodiments, the continuous integration pipeline task includes at least one of the following: code compilation task, code format verification task, code testing task, code security detection task, code packaging task, and code deployment task.

[0010] In some embodiments, the multi-dimensional fault correlation analysis information of the continuous integration pipeline task is input into a pre-trained code repair model to output a code repair solution, including: performing structured processing on the multi-dimensional fault correlation analysis information; slicing the structured multi-dimensional fault correlation analysis information to obtain multiple slice data, retaining the data identifier of each slice data and the data correlation relationship between each slice data; inputting each slice data and the corresponding data identifier and data correlation relationship into the pre-trained code repair model to output a code repair solution.

[0011] In some embodiments, after inputting the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model and outputting a code repair scheme, the method includes: generating a code repair instruction based on the code repair scheme; repairing the code requested to be merged in the code merge request according to the code repair instruction; generating a code merge request based on the repaired code, and re-triggering the continuous integration pipeline task of the target code branch.

[0012] In some embodiments, after generating a code merge request based on the repaired code and re-triggering the continuous integration pipeline task of the target code branch, the method includes: counting the number of times the continuous integration pipeline task is triggered; if the number of times the continuous integration pipeline task is triggered exceeds a preset threshold, stopping the generation of the code merge request for the target code branch and outputting a code repair failure notification message.

[0013] In some embodiments, after triggering a continuous integration pipeline task for the target code branch in response to a code merge request, the method further includes: during the execution of the continuous integration pipeline task, recording the task status identifier of each subtask in a cache, wherein the task status identifier is used to identify the execution status of each subtask; and when the continuous integration pipeline task is completed, determining the execution status of each subtask based on the cached task status identifiers of each subtask.

[0014] According to another aspect of this disclosure, a code repair device in a continuous integration environment is also provided, comprising: a task triggering module, configured to trigger a continuous integration pipeline task of a target code branch in response to a code merge request, wherein the continuous integration pipeline task includes: multiple subtasks that are automatically executed in a preset order; a task status monitoring module, configured to monitor the task status information of the continuous integration pipeline task and each subtask during the execution of the continuous integration pipeline task; and a multi-dimensional fault information acquisition module, configured to acquire the continuous integration pipeline task when the continuous integration pipeline task has been completed and at least one subtask has failed to execute. The task status information and execution log information of all failed subtasks in the continuous integration pipeline task are combined with the code change content, code context information, and code execution environment information corresponding to the code merge request to obtain multi-dimensional fault correlation analysis information of the continuous integration pipeline task. The code repair module is used to input the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model and output a code repair solution. The code repair solution is used to repair the code requested to be merged in the code merge request so that the repaired code can complete the execution of the continuous integration pipeline task and there are no failed subtasks.

[0015] According to another aspect of this disclosure, an electronic device is also provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the code repair method in a continuous integration environment as described above by executing the executable instructions.

[0016] According to another aspect of this disclosure, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the code repair method in a continuous integration environment as described in any of the preceding claims.

[0017] According to another aspect of this disclosure, a computer program product is also provided, comprising: a computer program or instructions that, when executed by a processor, implement the code repair method in a continuous integration environment as described in any one of the preceding claims.

[0018] The code repair method, apparatus, and related equipment provided in this embodiment of the continuous integration environment monitor the task status information of the continuous integration pipeline task and its subtasks during the execution of the continuous integration pipeline task. When the continuous integration pipeline task is completed but at least one subtask fails, the method acquires the task status information and execution log information of all failed subtasks in the continuous integration pipeline task. It then integrates the code change content, code context information, and code execution environment information corresponding to the code merge request in multiple dimensions to obtain multi-dimensional fault correlation analysis information of the continuous integration pipeline task. This information is input into a pre-trained code repair model to output a code repair scheme to repair the code requested to be merged in the code merge request, so that the repaired code completes the continuous integration pipeline task and there are no failed subtasks.

[0019] In this embodiment, by combining the task status information of failed subtasks, execution log information, and information from multiple dimensions such as code changes, code context information, and code execution environment information corresponding to code merging requests, a code repair scheme is generated based on a pre-trained code repair model. This enables automatic location, intelligent analysis, and automatic code repair of pipeline faults, effectively reducing the cost of manual intervention, improving the efficiency and accuracy of code repair processing, shortening the software development and delivery cycle, and significantly enhancing the automation and intelligence level of the continuous integration process.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0022] Figure 1This diagram illustrates an application system architecture according to an embodiment of the present disclosure. Figure 2 This diagram illustrates a code repair method in a continuous integration environment according to an embodiment of the present disclosure. Figure 3 This diagram illustrates a flowchart of a code repair scheme based on a large code repair model, as described in an embodiment of this disclosure. Figure 4 This diagram illustrates an automatic code repair flowchart according to an embodiment of the present disclosure; Figure 5 This diagram illustrates a specific implementation flowchart of a code repair method in a continuous integration environment according to an embodiment of this disclosure. Figure 6 A timing diagram illustrating a code repair method in a continuous integration environment according to an embodiment of this disclosure is shown. Figure 7 This diagram illustrates a code repair device in a continuous integration environment according to an embodiment of the present disclosure. Figure 8 A structural block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0023] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0024] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0025] To facilitate understanding, before introducing the embodiments of this disclosure, the following explanations are provided for several terms involved in the embodiments of this disclosure: DevOps: Development and Operations, is a concept and practice that integrates software development and IT operations. Its core is to shorten the cycle from code development to product launch through automated processes and cross-team collaboration, while improving delivery quality and operational efficiency.

[0026] Repository: Deployed on server Zhang Xiaohong, it is used to centrally store and manage the source code, configuration files and version history of software projects, ensuring data centralization and traceability.

[0027] CI: Continuous Integration. Developers frequently merge code into a shared repository, and the system automatically triggers processes such as compilation and testing to quickly discover and resolve code conflicts and defects.

[0028] CD: Continuous Deployment, based on continuous integration, automatically deploys code that has passed all tests to the test and production environments, enabling rapid and stable iteration and deployment of product features.

[0029] Pipeline: An automated workflow consisting of multiple tasks executed in a specific logical order, used to connect the entire process of development, testing, and deployment, and to achieve process standardization and automation.

[0030] Task: The smallest unit of execution in a pipeline. It is the basic component that makes up the pipeline and is responsible for completing a single specific operation (such as compilation, testing, deployment, etc.).

[0031] The specific implementation methods of the embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0032] The inventors discovered through research that existing fault handling solutions for continuous integration pipeline tasks have the following main shortcomings: 1) Limited Fault Information Dimensions Make Root Cause Localization Difficult: Existing solutions only provide execution logs and basic error messages for individual failed tasks, without correlating them with data such as code changes, overall project structure, and commit history. Most actual faults are caused by code modifications, and error messages outside the code context make it difficult to directly pinpoint the root cause. Developers need to manually integrate information across platforms, resulting in low troubleshooting efficiency.

[0033] 2) High cost of manual intervention and highly repetitive processing: The entire process, from viewing fault details, local debugging, code modification, resubmission to triggering the pipeline, relies on manual operation. Especially when there are multiple failed tasks in the pipeline, it is necessary to view the details of each one and repeatedly compare code differences, which is time-consuming. If the repair is inaccurate, the above process must be repeated, significantly extending the fault repair cycle.

[0034] 3) The repair and verification process is inefficient and wastes a lot of system resources. The existing solution requires manual submission and re-execution of the entire pipeline after each code repair. Even if only a small amount of code is modified, the entire process of compilation, testing, and packaging must be repeated, which is time-consuming and consumes a lot of server resources.

[0035] 4) Insufficient multi-task fault collaborative analysis capability: When multiple subtasks in the pipeline fail consecutively, the existing solution cannot identify the correlation between faults. For example, the failure of an upstream task may cause the downstream task to fail to execute, or errors in common code may cause multiple module tests to fail. It can only display the error information of each task in isolation, which greatly increases the complexity of manual analysis.

[0036] To address the aforementioned problems, the embodiments of this disclosure utilize automation and intelligent methods to automatically handle faults in continuous integration pipelines, offering the following advantages: 1) Break down information silos and achieve automatic integration of multi-dimensional fault data. Automatically collect details of failed tasks, project code structure, current code changes and historical commit information, and structure and integrate scattered fault-related data to provide a complete context for intelligent fault diagnosis, fundamentally solving the problems of single fault information and difficulty in fault location.

[0037] 2) Relying on a large model to achieve intelligent diagnosis and replace manual analysis, the integrated multi-dimensional fault information is input into the code to repair the large model in a standardized format. By utilizing the code understanding and fault attribution capabilities of the large model, accurate and executable code repair solutions are automatically generated, reducing the subjectivity and error of manual analysis and solving the problems of high manual costs and low troubleshooting efficiency.

[0038] 3) Build a fully automated repair loop to reduce manual intervention. Based on the repair solution output by the large model, the code modification and branch submission are completed automatically, and the continuous integration pipeline is re-triggered to run, forming an automated closed loop of "fault detection, intelligent diagnosis, code repair, and pipeline rerun", which greatly reduces manual operation.

[0039] 4) Enhance multi-task fault collaborative processing capabilities: By integrating the execution status and code context of the entire task chain, the large model can identify the inherent relationship between multiple failed tasks, generate a globally unified repair solution, solve the problem of isolated analysis of multi-task faults and difficulty in collaborative troubleshooting, and significantly improve the automation level and fault repair efficiency of the continuous integration system.

[0040] This disclosed embodiment can automatically take over the subsequent processing flow after a pipeline execution failure: After the pipeline completes, it obtains the complete code, code change information, and details of the failed task, and inputs them into the large model according to the standardized format; based on the modification suggestions output by the large model, it automatically generates repair code and pushes it to the corresponding code branch, automatically triggering the pipeline execution again to verify the repair effect. If a single repair fails, it continues to obtain the latest failure log and repeat the above automatic repair and rerun process, while setting a maximum retry threshold to avoid unlimited execution. The entire process requires no manual intervention, eliminating the need for manual error checking, review, and verification, effectively reducing time and labor costs, and improving R&D delivery efficiency.

[0041] Figure 1 A schematic diagram of an exemplary application system architecture is shown, illustrating an application of the code repair method in a continuous integration environment as described in this disclosure. For example... Figure 1 As shown, the system architecture may include terminal device 10, network 20 and server 30.

[0042] Network 20 is a medium used to provide a communication link between terminal device 10 and server 30, and can be a wired network or a wireless network.

[0043] Optionally, the aforementioned wireless or wired networks use standard communication technologies and / or protocols. The network is typically the Internet, but can also be any network, including but not limited to Local Area Networks (LANs), Metropolitan Area Networks (MANs), Wide Area Networks (WANs), mobile, wired or wireless networks, private networks, or any combination of virtual private networks. In some embodiments, technologies and / or formats, including Hyper Text Markup Language (HTML), Extensible Markup Language (XML), etc., are used to represent data exchanged over the network. Furthermore, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Networks (VPNs), and Internet Protocol Security (IPSec) can be used to encrypt all or some links. In other embodiments, custom and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.

[0044] Terminal device 10 can be various electronic devices, including but not limited to smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, wearable devices, augmented reality devices, virtual reality devices, etc.

[0045] Optionally, the client of the application installed on different terminal devices 10 may be the same, or the client of the same type of application based on different operating systems. Depending on the terminal platform, the specific form of the application client may also be different; for example, the application client may be a mobile client, a PC client, etc.

[0046] Server 30 can be a server that provides various services, such as a backend management server that supports the device operated by the user using terminal device 10. The backend management server can analyze and process received requests and other data, and feed the processing results back to the terminal device.

[0047] Optionally, the server can be a standalone physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0048] Those skilled in the art will know that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative; any number of terminal devices, networks, and servers can be included depending on actual needs. This disclosure does not limit the scope of the embodiments.

[0049] Under the above system architecture, this disclosure provides a code repair method in a continuous integration environment, which can be executed by any electronic device with computing power.

[0050] In some embodiments, the code repair method in a continuous integration environment provided in this disclosure can be executed by a terminal device in the above-described system architecture; in other embodiments, the code repair method in a continuous integration environment provided in this disclosure can be executed by a server in the above-described system architecture; in still other embodiments, the code repair method in a continuous integration environment provided in this disclosure can be implemented by the terminal device and the server in the above-described system architecture through interaction.

[0051] Figure 2 This diagram illustrates a code repair method in a continuous integration environment according to an embodiment of the present disclosure, such as... Figure 2As shown in the embodiments of this disclosure, the code repair method in a continuous integration environment includes the following steps: S202, in response to the code merge request, trigger the continuous integration pipeline task of the target code branch, wherein the continuous integration pipeline task includes: multiple subtasks that are automatically executed in a preset order.

[0052] In this embodiment, a code merge request refers to an operation request initiated by a developer or automation tool to submit and merge code to be merged into a target code branch, used for pipeline verification of the code to be merged before merging. The target code branch refers to the code branch to which this code merge request points; it can be a project development branch or the main branch. A continuous integration pipeline task is a series of tasks in a continuous integration system that automate compilation, testing, and verification of code according to a preset process. A subtask refers to the smallest execution unit constituting a continuous integration pipeline task, and can be, but is not limited to, code compilation tasks, code testing tasks, format verification tasks, security detection tasks, packaging tasks, deployment verification tasks, etc.

[0053] In the above steps, when a code merge request to merge code into the target code branch is received, a continuous integration pipeline task for the target code branch is automatically started. The continuous integration pipeline task includes a series of subtasks that are automatically executed in a predetermined order to automatically verify the code to be merged.

[0054] S204: During the execution of the continuous integration pipeline task, monitor the task status information of the continuous integration pipeline task and each subtask.

[0055] In this embodiment of the disclosure, task status information is used to characterize the execution results or progress of continuous integration pipeline tasks or their subtasks, including but not limited to the following: executing, successful execution, failed execution, waiting to execute, skipped execution, abnormal termination, etc. The continuous integration pipeline task execution process in S204 above refers to the entire operational phase of the pipeline from startup to completion; during this operational phase, the execution status of the continuous integration pipeline tasks and their subtasks is monitored and collected to subsequently determine whether the continuous integration pipeline tasks and their subtasks have been successfully or failed.

[0056] Optionally, in some embodiments, after triggering the continuous integration pipeline task of the target code branch in response to the code merge request, the code repair method in the continuous integration environment provided in this disclosure embodiment may further include the following steps: during the execution of the continuous integration pipeline task, the task status identifier of each subtask is recorded in a cache, wherein the task status identifier is used to identify the execution status of each subtask; when the continuous integration pipeline task is completed, the execution status of each subtask is determined according to the task status identifier of each subtask in the cache.

[0057] In the above embodiments, by recording the task status identifiers of each subtask in real time to a cache during the execution of the continuous integration pipeline task, and quickly determining the execution status of each subtask based on the cached task status identifiers after the pipeline execution is completed, efficient, real-time, and reliable collection of subtask execution status can be achieved. Compared with traditional code repair solutions, there is no need to repeatedly query execution logs or backtrack execution records, reducing system query overhead and data processing latency, and improving the response speed of fault identification. At the same time, the caching mechanism ensures the consistency and traceability of task status, avoiding inaccurate fault judgment due to status loss or statistical delay, providing stable and accurate status data support for subsequent multi-dimensional fault information integration and large-scale model fault diagnosis, further improving the stability and execution efficiency of the entire automated code repair process.

[0058] S206. When the continuous integration pipeline task is completed but at least one subtask fails, obtain the task status information and execution log information of all failed subtasks in the continuous integration pipeline task. Combine this information with the code change content, code context information, and code execution environment information corresponding to the code merge request to perform multi-dimensional integration and obtain multi-dimensional fault correlation analysis information of the continuous integration pipeline task.

[0059] In this step, "continuous integration pipeline task completion" means that all pre-defined subtasks in the pipeline have been executed sequentially (regardless of success or failure), entering the end state. A failed subtask refers to a task that failed execution, causing the entire continuous integration pipeline to fail validation. The task status information for these failed subtasks can refer to information characterizing subtask execution failure or abnormal results, such as execution failure, execution timeout, abnormal termination, or not executed. Execution log information refers to the running records, error messages, stack traces, and prompts automatically output by the system during subtask execution, serving as direct evidence for locating the cause of the failure. The code change information includes the added, modified, and deleted code content relative to the target code branch in this code merge request, as well as comparison information on the differences; the code context information refers to the location, code structure, call relationships, dependency chains, related classes and methods, and other related information of the code to be repaired in the project, used to understand the code's execution logic; the code execution environment information is the environment-related information of the code to be repaired actually running in the pipeline, including but not limited to: operating system, runtime version, dependency package version, environment variables, configuration parameters, etc.; multi-dimensional integration refers to the unified collection and correlation processing of the above scattered information; multi-dimensional fault correlation analysis information is the complete dataset formed after integration for fault diagnosis.

[0060] Optionally, in some embodiments, code context information includes, but is not limited to: project code directory structure, code dependencies, and historical information of historical commit merge requests.

[0061] In this embodiment of the disclosure, when the continuous integration pipeline has been completed and there are failed subtasks, the status and log information of all failed subtasks are collected, and multi-dimensional data is integrated in combination with the current code change, code context and execution environment information to form multi-dimensional fault correlation analysis information for fault diagnosis. This can realize the unified integration of fault-related information, break the problem of the isolation of various information in traditional fault repair solutions, and provide complete and comprehensive context support for intelligent fault diagnosis.

[0062] S208 inputs multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model and outputs a code repair solution. The code repair solution is used to repair the code requested to be merged in the code merge request, so that the repaired code can complete the continuous integration pipeline task and there are no failed subtasks.

[0063] In this embodiment, the code repair model refers to a pre-trained large-scale model for code repair. In practice, this model can be pre-trained based on a large number of code fault samples, repair cases, and code logic data, enabling it to perform code fault identification, root cause analysis, and repair solution generation. It does not require additional training during the current pipeline execution and can directly receive fault data and output repair results. The code repair solution refers to a specific executable plan output by the large-scale code repair model to resolve pipeline task failures. It typically includes the code snippet to be modified, the modification method, dependency adjustment suggestions, and environment configuration optimizations. Its core purpose is to repair defects in the code or resolve faults caused by the environment or dependencies.

[0064] It should be noted that the code requested to be merged in the code merging request in this embodiment refers to all the code to be merged into the target code branch in the code merging request that triggers the pipeline execution this time (i.e. the code to be repaired that caused the pipeline subtask to fail).

[0065] As can be seen from the above, the code repair method in the continuous integration environment provided in this embodiment combines the task status information of failed subtasks, execution log information, and information from multiple dimensions such as code changes, code context information, and code execution environment information corresponding to the code merge request. Based on a pre-trained code repair model, it generates a code repair scheme, which can realize automatic pipeline fault location, intelligent analysis, and automatic code repair. This effectively reduces the cost of manual intervention, improves the efficiency and accuracy of code repair processing, shortens the software development and delivery cycle, and significantly improves the automation and intelligence level of the continuous integration process.

[0066] In some embodiments, the continuous integration pipeline tasks in this disclosure may include, but are not limited to, at least one of the following: code compilation tasks, code format verification tasks, code testing tasks, code security detection tasks, code packaging tasks, and code deployment tasks.

[0067] The code compilation task is used to convert source code into an executable program or object file and check the correctness of code syntax; the code format verification task is used to verify whether the code conforms to the preset coding standards; the code testing task is used to verify whether the code logic and function are normal through unit testing, integration testing and other methods; the code security detection task is used to identify security vulnerabilities and potential risks in the code; the code packaging task is used to package the compiled and tested code into a deployable software package or image; and the code deployment task is used to release the packaged artifact to the specified environment to complete the deployment verification.

[0068] In the above embodiments, this embodiment incorporates various common pipeline tasks such as code compilation, format verification, testing, security detection, packaging, and deployment into its scope of application. This enables the code repair method of the present invention to adapt to different stages and types of pipeline failure scenarios, possessing strong versatility, scalability, and scenario coverage capabilities. It can achieve automated diagnosis and repair in various failure situations such as compilation errors, non-standard formats, functional abnormalities, security vulnerabilities, packaging failures, and deployment anomalies, thereby improving the applicability and practical value of the method.

[0069] For example, Figure 3 This document illustrates a flowchart of a code repair scheme based on a large code repair model, as described in an embodiment of this disclosure. Figure 3 As shown, the specific steps are as follows: S302, perform structured processing on multi-dimensional fault correlation analysis information; S304, the multi-dimensional fault correlation analysis information after structured processing is sliced ​​to obtain multiple slice data, and the data identifier of each slice data and the data correlation relationship between each slice data are retained; S306 inputs each slice of data, along with the corresponding data identifiers and data relationships, into a pre-trained code repair model and outputs a code repair solution.

[0070] In the above embodiments, the multi-dimensional fault correlation analysis information is structured, converting the originally scattered and unstructured task status information, execution log information, code change content, code context, and execution environment information of failed subtasks into a standardized format (e.g., JSON format) recognizable by the large code repair model. This enables unified organization and encapsulation of the data. Because the large model has limited context and the collected content is extensive, it cannot all be transmitted to the large model at once. In this embodiment, the structured information is sliced ​​to obtain multiple slice data, retaining the data identifiers corresponding to each slice and the data relationships between the slice data, ensuring that the data retains complete logical connections and traceability after splitting. Each slice data, along with its corresponding data identifier and data relationships, is input into a pre-trained large code repair model. The model then performs fault root cause analysis and code repair reasoning, outputting the corresponding code repair solution.

[0071] This embodiment achieves precise correlation between code change information and pipeline fault information by structurally encapsulating and standardizing the input data, thereby improving the large model's ability to understand and locate faults and ensuring that the generated code repair suggestions are more accurate and reliable.

[0072] For example, Figure 4This illustration shows a flowchart of an automatic code repair process according to an embodiment of the present disclosure, such as... Figure 4 As shown, the specific steps are as follows: S210 generates code repair instructions based on the code repair scheme; S212, Repair the code requested to be merged in the code merging request according to the code repair instruction; S214, Generate a code merge request based on the repaired code and re-trigger the continuous integration pipeline task of the target code branch.

[0073] In the above embodiments, executable code repair instructions are generated based on the code repair scheme output by the code repair big model. Then, the code to be merged corresponding to this code merge request is automatically repaired according to the code repair instructions. Finally, the code merge request is regenerated based on the repaired code, and the continuous integration pipeline task of the target code branch is automatically triggered again to verify whether the code repair is effective and whether the pipeline can be executed normally. This approach automates the entire process of fault diagnosis, code repair, and pipeline rerun without manual intervention, significantly improving code fault repair efficiency and R&D delivery speed.

[0074] Optionally, in some embodiments, after generating a code merge request based on the repaired code and re-triggering the continuous integration pipeline task of the target code branch, the code repair method in the continuous integration environment provided in this disclosure may further include the following steps: S216, Count the number of times the continuous integration pipeline task is triggered; S218: If the number of times a continuous integration pipeline task is triggered exceeds a preset threshold, stop generating code merge requests for the target code branch and output a code fix failure notification message.

[0075] The above embodiment, based on automatic code repair and pipeline re-triggering, adds a threshold control mechanism for automatic pipeline retry. This achieves automatic retries for faults while avoiding the waste of system resources caused by unlimited retries. The specific process is as follows: After regenerating the merge request based on the repaired code and triggering the pipeline task, the cumulative number of triggers of the continuous integration pipeline task under the target code branch is first counted. If the counted number of triggers exceeds a preset threshold (e.g., 5 times), the generation of new code merge requests is stopped, and a notification message indicating code repair failure is output, prompting relevant personnel to intervene.

[0076] After counting the number of times the continuous integration pipeline task is triggered, if the number of triggers does not reach the preset threshold, the next pipeline execution is automatically initiated to complete the fault retry; if the number of triggers exceeds the preset threshold, the retry process is terminated in time and a notification is issued. This ensures the adequacy of fault repair and avoids meaningless repeated execution, thereby improving the system resource utilization and the controllability of fault handling.

[0077] Through the above embodiments, automatic retry of pipeline failures can be realized. After the pipeline execution is completed, a corresponding flag bit is generated to record the pipeline execution status and error information. If the number of failures has not been reached, the next execution can be automatically triggered.

[0078] Taking the DevOps system as an example, the code repair method provided in the continuous integration environment in this embodiment of the disclosure automatically obtains the overall structure of the project code, the history of commits, the modified code and the detailed information of the task when a failed task occurs in the pipeline after the developer commits a code branch and completes the pipeline. The system then sends this information to the large model, recommits the code to the current branch, and reruns the pipeline until the pipeline repair is completed and the code is finished.

[0079] Figure 5 This diagram illustrates a specific implementation flowchart of a code repair method in a continuous integration environment according to an embodiment of this disclosure. Figure 6 This diagram illustrates the timing of a code repair method in a continuous integration environment according to an embodiment of this disclosure. Figure 5 and Figure 6 As shown in the embodiments of this disclosure, the code repair method in a continuous integration environment includes the following process in its specific implementation: 1) After developers submit the modified code, documentation, and configuration files to the target branch, the DevOps system automatically triggers the execution of the pipeline corresponding to that branch (such as Pipeline-1). The pipeline (Pipeline-1) starts a series of tasks such as compilation, testing, and packaging in sequence according to the preset process.

[0080] 2) The status monitoring module continuously monitors the running status of the pipeline (Pipeline-1) and each task, collecting real-time data on task execution progress, CPU usage, disk usage, memory consumption, and task status indicators. These indicators are stored in the Redis cache system, while log information is stored locally. Upon completion of the entire pipeline execution, the final status of all tasks is immediately verified.

[0081] 3) The tasks in Pipeline-1 include build tasks, code formatting verification tasks, testing tasks, security testing tasks, deployment tasks, etc., all of which are completed. If the execution is successful, the automatic remediation process is not triggered, and success information, including start time, end time, and the execution result of each task, is stored in the log system. The customer is notified via email that Pipeline P1 is complete, and the email content includes the notifier, pipeline details, and the final time.

[0082] 4) If at least one task fails, the pipeline's automatic repair process (e.g., Fix-Pipeline-1, the repair process for pipeline 1) will be triggered immediately. Simultaneously, the user will be notified by email that the automatic repair process is about to be executed. The email will include the pipeline name, the reason for the pipeline failure, a list of failed tasks, and the unique identifier for the automatic repair process, Fix-Pipeline-1.

[0083] 5) In Fix-pipeline-1 of the remediation process, the information collection module collects necessary information according to preset rules, including the project code directory structure and dependencies, the changes to the files and code in this commit, the commit history, logs of failed tasks, error messages, and environment configuration. See the description below for details.

[0084] 6) After information collection is completed, it is converted into structured content. A detailed description of the structured content for each part is provided.

[0085] 7) Slice the structured content. Due to the limited context of the large model and the large amount of collected content, it is not possible to pass all of it to the large model at once. Each time, slice it into a preset number of characters (such as 5000 characters) of context information, file name and probability to ensure the correlation between files.

[0086] 8) Use the large model to analyze the specific reasons for failure and generate targeted repair solutions (e.g., Solution-1, i.e., the repair solution for pipeline 1). The repair solution includes, but is not limited to, the following: ① The specific reasons for the failure of each task in the pipeline; ② Suggestions for adjusting the settings or configurations of the pipeline; ③ Suggestions for system security, and convenient explanations and descriptions of whether there are any vulnerabilities.

[0087] 9) According to Solution-1, in Fix-Pipeline-1, continue to modify the code, execute Git commands, add changes, save changes, and commit to the repository.

[0088] 10) Submit the fixed code to the target code branch to trigger Pipeline-2.

[0089] 11) Pipeline-2 repeats all tasks and waits for them to complete. If a task still fails, the fix-pipeline-2 process is executed.

[0090] 12) If all tasks in the rerun of the pipeline execute successfully, the repair is considered complete, the system records the repair log and sends a notification to the user. If the pipeline reaches the maximum number of attempts, the specific reasons for the failure are recorded and the user is notified.

[0091] In one embodiment, to achieve unified organization, collection, and management of multi-dimensional fault-related data, this disclosure embodiment performs unified structured processing on all data related to pipeline faults and code, and stores it in a text system. The specific data collection and push process is as follows: 1) After the continuous integration pipeline completes its operation, its raw execution logs are stored in the DevOps system's database by default. At this time, the system will issue an execution completion notification and actively pull the complete raw logs of the pipeline and push them to the text system for storage. 2) If a subtask in the pipeline fails to execute, the system will proactively identify the failed task and retrieve its detailed error logs, execution path, and other relevant information, pushing them to the text system for centralized storage to facilitate subsequent fault tracing. 3) After each code submission by the developer, the system will automatically capture the changes to the code (including newly added, modified, and deleted code snippets) and actively push them to the text system via API interface or remote transmission to achieve real-time synchronization of code change data; 4) Regarding the overall code structure of the project, the system will periodically obtain the latest project code directory, call relationships, dependency chains and other structural information according to a preset cycle, and push it to the text system to ensure that the code structure data stored in the text system is consistent with the actual project. 4) Before code deployment, the system will automatically collect the configuration information of the current deployment environment, including the operating system version, the names and corresponding versions of various components, environment variables, configuration parameters, etc., and actively push them to the text system to retain the deployment environment context data; 6) When developers push code, their submission description will be pre-linked with detailed text content of the user story, requirement setting document and test document corresponding to this code modification. The system will automatically extract the content of such related documents and actively push it to the text system to improve the background information of the fault diagnosis requirements. 7) The system will periodically retrieve all code commit records from the project code repository within the past month, including information such as the committer, commit time, commit description, and code change summary, and push them to the text system to provide historical commit references for root cause analysis of failures.

[0092] In one embodiment, after the continuous integration pipeline completes execution, fault-related data can be obtained from multiple dimensions and uniformly structured and converted into standardized JSON and other formats, specifically including: 1) Overall pipeline overview log information: As shown in Table 1, it includes overview log content such as pipeline name, start time, end time, runtime, overall error information, task names and execution relationships between tasks, which is converted into JSON format for storage.

[0093] 2) Detailed log information of failed tasks: As shown in Table 2, it includes the name of the failed task, execution time, dependent image resources, initialization script, running code, test content and detailed error information, etc., all of which are uniformly converted into JSON format.

[0094] 3) Content of this code change: As shown in Table 3, it includes the modified code text, version difference comparison and related attachment information, which are presented in a structured JSON format.

[0095] 4) Overall project directory structure: As shown in Table 4, the project code directory is organized in a structured way in the form of a file tree and converted into JSON format.

[0096] 5) Deployment environment and dependency configuration information: As shown in Table 5, it includes environment information such as operating system version, third-party component name and version, database version, middleware version, etc., which are structured and converted into JSON format.

[0097] 6) Project-related requirement documents: As shown in Table 6, these include user stories, requirement descriptions, test documents, and other content related to this code submission. They are presented in Markdown plain text format and encapsulated in JSON format.

[0098] 7) Code commit history information: As shown in Table 7, it includes historical commit records such as committer, commit time, modification description and code change content, all of which are uniformly converted into JSON format.

[0099] The above methods can convert multi-source and heterogeneous fault and code-related data into structured and standardized format data (such as JSON format), providing standardized and complete input data for subsequent large-scale model fault diagnosis and code repair.

[0100] Table 1 Overall Overview Log Information of the Production Line

[0101] Table 2. Log details of a single failed task

[0102] Table 3: Code Submissions vs. Changes

[0103] Table 4. Project Structured Directory

[0104] Table 5 Deployment Configuration and Environment Information (JSON Format)

[0105] Table 6 Related Requirements and Test Documents

[0106] Table 7 Project Code Submission History

[0107] As can be seen from the above, the code repair scheme provided in this embodiment of the continuous integration environment automatically obtains a list of all failed tasks in the pipeline and detailed error information for each task after the branch code is submitted to the repository and the pipeline runs. The error information of the tasks, along with necessary information such as code changes, is organized and sent to the large model for processing. The large model provides code modification suggestions, and the system automatically creates repair code, resubmits the modified code, and automatically reruns the pipeline until it is repaired. This embodiment of the disclosure, through a multi-dimensional fault information linkage collection mechanism, deeply integrates project code structure, code change differences, submission history and failed task logs, and environment configuration. After structured encapsulation, this information is input into the large model, providing complete contextual support for fault diagnosis and significantly improving the accuracy of problem localization. Simultaneously, relying on the large model, a repair solution is intelligently generated, and the code submission and pipeline rerun are completed through an automated process, constructing a closed-loop system of detection-diagnosis-repair-verification. This reduces core steps requiring manual intervention, significantly shortening the fault repair cycle and reducing the error rate of manual operations, effectively solving the pain points of isolated information and low efficiency in existing technologies. Reduce the time spent manually troubleshooting and waiting for problems to be fixed, and automate the resolution of production line failures.

[0108] It should be noted that the acquisition, storage, use, and processing of data in this disclosed technical solution comply with the relevant provisions of laws and regulations. All types of data, such as personal identity data, operational data, and behavioral data related to individuals, customers, and groups, obtained in this disclosed embodiment have been agreed upon by the users.

[0109] Based on the same inventive concept, this disclosure also provides a code repair device for a continuous integration environment, as described in the following embodiments. Since the principle by which this device solves the problem is similar to that of the method embodiments described above, the implementation of this device embodiment can refer to the implementation of the method embodiments described above, and repeated details will not be repeated.

[0110] Figure 7 This diagram illustrates a code repair device in a continuous integration environment according to an embodiment of the present disclosure. Figure 7 As shown, the device includes: a task triggering module 701, a task status monitoring module 702, a multi-dimensional fault information acquisition module 703, and a code repair module 704.

[0111] The system includes the following modules: Task Trigger 701, which responds to a code merge request and triggers a continuous integration pipeline task for the target code branch. The continuous integration pipeline task includes multiple subtasks executed automatically in a preset order. Task Status Monitoring 702 monitors the task status information of the continuous integration pipeline task and its subtasks during execution. Multi-dimensional Fault Information Acquisition 703 acquires the task status information and execution log information of all failed subtasks in the continuous integration pipeline task when the task has completed execution but at least one subtask has failed. This information is then combined with the code change content, code context information, and code execution environment information corresponding to the code merge request to obtain multi-dimensional fault correlation analysis information for the continuous integration pipeline task. Code Repair 704 inputs the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model and outputs a code repair solution. This solution repairs the code requested to be merged in the code merge request, ensuring that the repaired code completes the continuous integration pipeline task without any failed subtasks.

[0112] In some embodiments, the continuous integration pipeline tasks in this disclosure may include, but are not limited to, at least one of the following: code compilation tasks, code format verification tasks, code testing tasks, code security detection tasks, code packaging tasks, and code deployment tasks.

[0113] In some embodiments, the code repair module 704 is further configured to: perform structured processing on the multi-dimensional fault association analysis information; perform slicing processing on the structured multi-dimensional fault association analysis information to obtain multiple slice data, retain the data identifier of each slice data and the data association relationship between each slice data; input each slice data and the corresponding data identifier and data association relationship into a pre-trained code repair large model, and output a code repair scheme.

[0114] In some embodiments, the code repair module 704 is further configured to: generate code repair instructions based on the code repair scheme; repair the code requested to be merged in the code merge request according to the code repair instructions; generate a code merge request based on the repaired code, and re-trigger the continuous integration pipeline task of the target code branch.

[0115] In some embodiments, the code repair module 704 is further configured to: count the number of times the continuous integration pipeline task is triggered; and if the number of times the continuous integration pipeline task is triggered exceeds a preset threshold, stop generating code merging requests for the target code branch and output a code repair failure notification message.

[0116] In some embodiments, the code repair apparatus in the continuous integration environment provided in this disclosure may further include: a task status caching module, used to record the task status identifiers of each subtask in a cache during the execution of the continuous integration pipeline task, wherein the task status identifiers are used to identify the execution status of each subtask; when the continuous integration pipeline task is completed, the execution status of each subtask is determined according to the task status identifiers of each subtask in the cache.

[0117] It should be noted that the examples and application scenarios implemented by the modules in the above device embodiments and the corresponding steps in the method embodiments are the same, but are not limited to the content disclosed in the above method embodiments. It should also be noted that the above modules, as part of the device, can be executed in a computer system such as a set of computer-executable instructions.

[0118] Those skilled in the art will understand that various aspects of this disclosure can be implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, which can be collectively referred to herein as a "circuit", "module" or "system".

[0119] Based on the same inventive concept, this disclosure also provides an electronic device, which includes: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the code repair method in a continuous integration environment by executing the executable instructions. Since the principle by which this electronic device solves the problem is similar to that of the above-described method embodiments, the implementation of this electronic device embodiment can refer to the implementation of the above-described method embodiments, and repeated details will not be elaborated further.

[0120] The following reference Figure 8 To describe an electronic device 800 according to such an embodiment of the present disclosure. Figure 8 The electronic device 800 shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments disclosed herein.

[0121] like Figure 8 As shown, the electronic device 800 is manifested in the form of a general-purpose computing device. The components of the electronic device 800 may include, but are not limited to: at least one processing unit 810, at least one storage unit 820, and a bus 830 connecting different system components (including storage unit 820 and processing unit 810).

[0122] The storage unit stores program code that can be executed by the processing unit 810, causing the processing unit 810 to perform the steps described in the "Exemplary Methods" section above according to various exemplary embodiments of this disclosure. For example, the processing unit 810 can execute the following steps of the above method embodiment: In response to the code merge request, trigger the continuous integration pipeline task of the target code branch, wherein the continuous integration pipeline task includes: multiple subtasks that are automatically executed in a preset order; during the execution of the continuous integration pipeline task, monitor the task status information of the continuous integration pipeline task and each subtask; when the continuous integration pipeline task is completed and at least one subtask fails to execute, obtain the task status information and execution log information of all failed subtasks in the continuous integration pipeline task, and perform multi-dimensional integration by combining the code change content, code context information, and code execution environment information corresponding to the code merge request, to obtain multi-dimensional fault correlation analysis information of the continuous integration pipeline task; input the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model, and output a code repair scheme, which is used to repair the code requested to be merged in the code merge request, so that the repaired code completes the execution of the continuous integration pipeline task and there are no failed subtasks.

[0123] Storage unit 820 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 8201 and / or cache memory 8202, and may further include a read-only memory (ROM) 8203.

[0124] The storage unit 820 may also include a program / utility 8204 having a set (at least one) of program modules 8205, such program modules 8205 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0125] Bus 830 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0126] Electronic device 800 can also communicate with one or more external devices 840 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 800, and / or with any device that enables electronic device 800 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 850. Furthermore, electronic device 800 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 860. As shown, network adapter 860 communicates with other modules of electronic device 800 via bus 830. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 800, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0127] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0128] Based on the same inventive concept, this disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the code repair method in a continuous integration environment described above. Since the principle by which this computer-readable storage medium solves the problem is similar to that of the above method embodiments, the implementation of this computer-readable storage medium embodiment can refer to the implementation of the above method embodiments, and repeated details will not be elaborated further.

[0129] More specific examples of computer-readable storage media in this disclosure may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0130] In this disclosure, a computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of transmitting, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device.

[0131] Optionally, the program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0132] In practical implementation, program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0133] Based on the same inventive concept, this disclosure also provides a computer program product, including a computer program or instructions, which, when executed by a processor, implements the code repair method in a continuous integration environment as described in any of the above method embodiments. Since the principle by which this computer program product embodiment solves the problem is similar to that of the above method embodiments, the implementation of this computer program product embodiment can refer to the implementation of the above method embodiments, and repeated details will not be elaborated further.

[0134] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0135] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0136] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0137] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

Claims

1. A code repair method in a continuous integration environment, characterized in that, include: In response to a code merge request, a continuous integration pipeline task for the target code branch is triggered, wherein the continuous integration pipeline task includes: multiple subtasks that are automatically executed in a preset order; During the execution of the continuous integration pipeline task, the task status information of the continuous integration pipeline task and each subtask is monitored; When the continuous integration pipeline task is completed but at least one subtask fails, the task status information and execution log information of all failed subtasks in the continuous integration pipeline task are obtained. Combined with the code change content, code context information and code execution environment information corresponding to the code merge request, multi-dimensional integration is performed to obtain multi-dimensional fault correlation analysis information of the continuous integration pipeline task. The multi-dimensional fault correlation analysis information of the continuous integration pipeline task is input into a pre-trained code repair model, and a code repair scheme is output. The code repair scheme is used to repair the code requested to be merged in the code merge request, so that the repaired code can complete the continuous integration pipeline task and there are no failed subtasks.

2. The code repair method in a continuous integration environment according to claim 1, characterized in that, The continuous integration pipeline tasks include at least one of the following: code compilation task, code format verification task, code testing task, code security detection task, code packaging task, and code deployment task.

3. The code repair method in a continuous integration environment according to claim 1, characterized in that, The multi-dimensional fault correlation analysis information of the continuous integration pipeline task is input into a pre-trained code repair model, and a code repair solution is output, including: The multi-dimensional fault correlation analysis information is then processed in a structured manner. The structured multi-dimensional fault correlation analysis information is sliced ​​to obtain multiple slice data, and the data identifier of each slice data and the data correlation between each slice data are preserved. Each slice of data, along with its corresponding data identifier and data association, is input into a pre-trained code repair model, which then outputs a code repair solution.

4. The code repair method in a continuous integration environment according to claim 1, characterized in that, After inputting the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model and outputting a code repair solution, the method includes: Based on the code repair scheme, generate code repair instructions; According to the code repair instructions, the code requested to be merged in the code merge request is repaired; Generate a code merge request based on the repaired code and re-trigger the continuous integration pipeline task for the target code branch.

5. The code repair method in a continuous integration environment according to claim 4, characterized in that, After generating a code merge request based on the repaired code and re-triggering the continuous integration pipeline task for the target code branch, the method includes: Count the number of times the continuous integration pipeline task is triggered; If the number of times the continuous integration pipeline task is triggered exceeds a preset threshold, the generation of code merging requests for the target code branch will be stopped, and a code fix failure notification message will be output.

6. The method of claim 1, wherein, After triggering the continuous integration pipeline task for the target code branch in response to the code merge request, the method further includes: During the execution of the continuous integration pipeline task, the task status identifier of each subtask is recorded in the cache, wherein the task status identifier is used to identify the execution status of each subtask; When the continuous integration pipeline task is completed, the execution status of each subtask is determined based on the task status identifiers of each cached subtask.

7. A code repair device for a continuous integration environment, characterized in that, include: The task triggering module is used to trigger the continuous integration pipeline task of the target code branch in response to the code merge request, wherein the continuous integration pipeline task includes: multiple sub-tasks that are automatically executed in a preset order; The task status monitoring module is used to monitor the task status information of the continuous integration pipeline task and its subtasks during the execution of the continuous integration pipeline task. The multi-dimensional fault information acquisition module is used to acquire the task status information and execution log information of all failed subtasks in the continuous integration pipeline task when the continuous integration pipeline task is completed and at least one subtask fails to execute. It then integrates the code change content, code context information, and code execution environment information corresponding to the code merge request in multiple dimensions to obtain the multi-dimensional fault correlation analysis information of the continuous integration pipeline task. The code repair module is used to input the multi-dimensional fault correlation analysis information of the continuous integration pipeline task into a pre-trained code repair model and output a code repair solution. The code repair solution is used to repair the code requested to be merged in the code merge request, so that the repaired code can complete the continuous integration pipeline task and there are no failed subtasks.

8. An electronic device, comprising: include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to execute the code repair method in a continuous integration environment as described in any one of claims 1 to 6 by executing the executable instructions.

9. A computer readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the processor, it implements the code repair method in a continuous integration environment as described in any one of claims 1 to 6.

10. A computer program product, comprising: A computer program or instruction, characterized in that, when executed by a processor, the computer program or instruction implements the code repair method in a continuous integration environment as described in any one of claims 1 to 6.

Images