METHOD AND SYSTEM FOR ERROR DETECTION AND CORRECTION IN PIPELINES FOR CONTINUOUS INTEGRATION / CONTINUOUS PROVISION

Abstract

The present disclosure provides a method (300) and a system (130) for error detection and correction in continuous integration / continuous delivery (CI / CD) pipelines. The system (130) executes a CI / CD pipeline based on updates to a software received from one or more development devices (110) and detects errors in the updates and / or in the code stored in a repository (220) by processing log data generated during the execution of the CI / CD pipeline using a local AI model (140).The system (130) then executes a first error correction script generated by the local AI model (140) to correct the detected errors, and iteratively executes a second error correction script generated by an external AI model (150) for errors that persist after the implementation of the first error correction script, until a stop condition is met.

Description

Embodiments of the present disclosure relate to automated error detection and correction, and in particular, the present disclosure relates to a system and a method for automatically detecting and executing errors that occur in continuous testing, integration, delivery, and deployment pipelines. Software development encompasses many different phases, and one of the most important parts of the development process is testing and debugging software code. In a continuous development environment (CDE), where software is continuously developed, integrated, and deployed, real-time bug detection and remediation are desirable to minimize the time between build and release. Software verification processes analyze a software application during its creation / deployment and report bugs detected during software / code execution. Generally, bugs detected in a project's software code must be fixed, and this typically depends on the project team managing the project. They usually resolve bugs based on bug logs maintained in a codebase repository on version control platforms like GitLab.Although such repositories facilitate error detection and correction for the software code under development, they still depend on manual intervention, which is costly and time-consuming, as developers have to review thousands of lines of code and logs to identify the error (or its cause) and find a suitable solution, which is particularly undesirable in continuous testing, integration, delivery, and deployment environments. Patent document US2024345904A1 discloses a method for automatically detecting and correcting errors in software deployment pipelines. The process involves gathering information about errors within a pipeline job and using natural language processing (NLP) models to identify appropriate error correction scripts that address these problems. The identified scripts are then executed to correct the errors. The NLP models are trained using error descriptions from an error database and can be retrained / updated as new data records are added. Patent document US10459695B2 provides solutions for detecting and correcting errors in software, such as in source code, using machine learning. A machine learning algorithm is trained using source code, source code corrections, and extracted code features to provide a trained classifier. Test data, such as code to be scanned for errors or code known to contain errors, is provided to the trained classifier. The classifier can generate a code correction or corrected code. Code corrections can be applied to the source code to provide corrected code. Patent document US11579962B2 discloses a computer system and a method for automated program error correction. The computer system comprises a memory, a preprocessing processor, and an automated error correction processor. The memory stores program code. The preprocessing processor retrieves the program code from memory and preprocesses it by tokenizing the program code with tokens, converting the tokens into vectors, and adding location information for the tokens. The automated error correction processor receives the preprocessed program code as input from the preprocessing processor, detects an error in the preprocessed program code, corrects the detected error, and outputs the corrected program code. The error detection and correction are based on a deep learning result and the location information for the tokens. However, the methods or machine learning models used in the cited documents sometimes fail to accurately identify and / or correct errors. These documents do not provide fallback mechanisms to resume error correction when the model fails, leading to longer resolution times and requiring human intervention, which is particularly undesirable in a continuous development context. Therefore, there is a need for an automated solution for automated error detection and correction in continuous integration and continuous delivery (CI / CD) pipelines. A general objective of this disclosure is to provide a system and method for detecting and correcting software errors in continuous integration and continuous delivery (CI / CD) environments. Another objective of this disclosure is to provide a local model that recommends scripts for error correction. Another purpose of the present disclosure is to provide a fallback mechanism that uses an external model for errors that the local model cannot correct. Another task of the present disclosure is to iteratively generate error correction scripts until a stop condition is met. Another purpose of this disclosure is to retrain the local model with the error correction script from the external model for the error. A further purpose of this disclosure is to inform users that the error cannot be corrected if the local model and the external model are unable to correct the error. Embodiments of the present disclosure relate to automated error detection and correction, and in particular, the present disclosure relates to a system and a method for automatically detecting and correcting errors that occur in continuous testing, integration, delivery, and deployment pipelines. One aspect of the present disclosure relates to a method for error detection and correction in continuous integration and continuous delivery (CI / CD) pipelines.The process involves the execution of a CI / CD pipeline by a system based on software updates received from one or more developer devices, the detection of errors in the updates and / or the code stored in a repository by the system through the processing of log data generated during the execution of the CI / CD pipeline by a local AI model, the execution by the system of a first error correction script generated by the local AI model to fix the detected error, and for errors that remain unresolved after the implementation of the first error correction script, the iterative execution by the system of a second error correction script generated by an external AI model until a stop condition is met.This enables the automatic correction of errors, thereby reducing the burden on developers and accelerating development cycles. In some implementations, the local AI model can be configured to extract files from the repository that caused the error. In some embodiments, the implementation of the first error correction script and / or the second error correction script may include at least one of the following: disabling an error-causing part of the code or replacing the error-causing parts of the code with alternative code. In some embodiments, the method may be triggered upon implementation of one or a combination of a merge request pipeline, a commit pipeline, and a predetermined job defined in a template. In some embodiments, the process can be triggered at predetermined intervals. In some embodiments, if the fault remains unresolved after the stop condition has been met, the method may include the system transmitting a notification to one or more developer devices regarding the failure to correct the fault. In some embodiments, the local AI model can be pre-trained using one or a combination of a masked speech modeling technique or a next sentence prediction technique. In some embodiments, the method may include fine-tuning the local AI model based on the second error correction script generated by the external AI model upon fixing the error. In some embodiments, the method for executing the first error correction script and / or the second error correction script may include: the system cloning the repository to obtain a cloned repository, the system correcting the cloned repository with the first error correction script and / or the second error correction script, and the system iteratively executing the CI / CD pipeline on the cloned repository until a stop criterion is met. One aspect of the present disclosure relates to a system for error detection and correction in continuous testing and continuous delivery (CI / CD) pipelines, including a processor and a memory functionally coupled to the processor, wherein the memory contains one or more processor-executable instructions configured to cause the processor to execute a CI / CD pipeline based on updates to software received from one or more developer devices, to detect errors in the updates and / or code stored in a repository by processing log data generated during the execution of the CI / CD pipeline through a local AI model, to execute an initial error correction script generated by the local AI model to correct the detected error, and for errors that remain unresolved after the implementation of the initial error correction script,to iteratively execute a second error correction script generated by an external AI model until a stop condition is met. The accompanying drawings serve to enhance understanding of the present disclosure and are incorporated into and form part of this description. The drawings illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. Fig. 1 illustrates an exemplary network architecture implementing a fault detection and correction system in a continuous integration and continuous delivery (CI / CD) pipeline according to one embodiment of the present disclosure. Fig. 2 illustrates an exemplary workflow implemented by the system according to one embodiment of the present disclosure. Fig. 3 illustrates a flowchart of a fault detection and correction method in a CI / CD pipeline according to one embodiment of the present disclosure.Figure 4 illustrates an exemplary computer system in which or with which embodiments of the present disclosure can be implemented according to one embodiment of the present disclosure. The following describes in detail embodiments of the disclosure illustrated in the accompanying drawings. These embodiments are described in sufficient detail to clearly convey the embodiments of the present disclosure. However, the level of detail provided is not intended to limit the expected variations of the embodiments; rather, it is intended to cover all modifications, equivalents, and alternatives that fall within the scope of the present disclosure as defined by the accompanying claims. Embodiments of the present disclosure relate to automated error detection and correction, and in particular, the present disclosure relates to a system and a method for automatically detecting and correcting errors that occur in continuous testing, integration, delivery, and deployment pipelines.One aspect of the present disclosure relates to a method for error detection and correction in continuous integration and continuous delivery (CI / CD) pipelines.The process involves the execution of a CI / CD pipeline by a system based on software updates received from one or more developer devices, the detection of errors in the updates and / or the code stored in a repository by the system through the processing of log data generated during the execution of the CI / CD pipeline by a local AI model, the execution by the system of a first error correction script generated by the local AI model to fix the detected error, and for errors that remain unresolved after the implementation of the first error correction script, the iterative execution by the system of a second error correction script generated by an external AI model until a stop condition is met.This enables the automatic correction of errors, thereby reducing the burden on developers and accelerating development cycles. Referring to Fig. 1, a network environment / architecture 100 is shown, which implements a system for error detection and correction during continuous integration and continuous delivery (CI / CD). The network environment 100 can include one or more developers via corresponding developer devices (such as developer devices 110-1 to 110-3, collectively referred to as developer devices 110). A repository can be created for the project, which is associated with the software developed by the developers and can be stored and / or deployed on the server 120. The server 120 can be a version control platform (such as GitLab, GitHub). The server 120 can also be configured to enable CI / CD, allowing developers 110 to continuously create, merge / integrate, test, and release / deploy new features / code.In some embodiments, the server 120 can be associated with other servers, with replicas of the server 120 containing the repositories being created in near real time. The server 120 can be coupled to the developer devices 110 via a communication network 125, for example, via wired means (such as electrical wires, cables, fiber optic cables, and the like), wireless means (such as telecommunications networks, satellite networks, wireless fidelity (Wi-Fi), Bluetooth, local area networks, wide area networks, and the like), or a combination thereof. In some embodiments, the Server 120 can be configured to manage a repository that can contain code and various other aspects related to the code, such as file structures, versions, test details, and the like, associated with software under development. In one embodiment, the code can be associated with a specific project managed in the repository, and the code can be stored in various files or directory structures within the project in the repository. In another embodiment, the repository can track and manage log files for each project related to testing, integration, and deployment of the code. In one example, different versions of the code are managed under different version numbers in the repository. In one embodiment, the repository can manage different projects (associated with the same or different software). Developers can create software and add functionality to it by writing code (i.e., instructions executable by the processor). Each time new functionality is created, the associated code in the repository can be updated to reflect the software on the Server 120. The repository can contain files, including project-related software code, log files, installation packages, and other data. Furthermore, the Server 120 can be configured to maintain logs of the tasks / jobs executed by the Server 120 during the implementation of CI / CD pipelines. These CI / CD pipelines can include one or more jobs / tasks for continuous integration (triggered upon receiving a template, merge request, and / or commit request), continuous testing, continuous delivery, and continuous deployment.The CI / CD pipeline may comprise a sequential list of jobs / tasks (which may be further processor-executable instructions) involved in testing, integration, delivery, and / or deployment of the software. In some embodiments, Server 120 may also be configured to maintain a log associated with the execution of the CI / CD pipeline. In some embodiments, a log file may be generated to manage, among other things, error logs associated with the jobs / tasks for integrating and / or deploying each particular version of the developed code. Figure 1 is for illustrative purposes only and may contain additional and / or alternative elements or variations thereof, and the present disclosure encompasses all such variations. As mentioned previously, errors frequently occur during CI / CD pipeline execution. Examples of such errors include: configuration errors (caused by pipeline syntax errors, missing environment variables, dependency incompatibilities, unrecognized commands / parameters, etc.), build errors (caused by compilation errors, incompatible package versions, dependency resolution issues, etc.), test errors (e.g., unit test failures, integration test failures, etc.), deployment errors (e.g., infrastructure failures, authentication / authorization failures, artifact management errors, etc.), network errors, hardware failures, scaling errors, and the like (but are not limited to these). Typically, such errors are logged and manually resolved by the developers.In the context of CI / CD pipelines / workflows, software can be developed, built, and deployed quickly and continuously. Efficient error management is crucial for adhering to project schedules and ensuring product reliability, and manual error detection and resolution processes in version control platforms like GitLab often prove to be time-consuming and error-prone. Generally, manual error detection processes in such systems are labor-intensive and highly susceptible to human error. Furthermore, delays in error resolution can disrupt project schedules and impact productivity. Another challenge is that logs often contain large amounts of data, making it difficult to pinpoint specific errors.Therefore, there is a need for an automated solution that can efficiently scan protocols, detect errors, and make fixes / corrections in real time or near real time, saving developers time and effort. Some existing automated solutions use classification models or deep learning models for error correction. However, such solutions are often limited and have several disadvantages, such as high computational costs, failure to utilize the capabilities of generative artificial intelligence (AI), lack of workflows when the models cannot correct the errors, and the like. In some embodiments, the Server 120 may include a System 130 for automatically detecting and correcting errors in the CI / CD pipelines. In some embodiments, the System 130 may include a processor and memory (not shown). The processor may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuits, electronic circuits, and / or any devices that process data based on operating instructions. Among other functions, the one or more processors may be configured to retrieve and execute computer-readable / processor-executable instructions stored in memory of the System 130.The memory can be configured to store one or more machine-readable instructions or routines on a non-volatile, machine-readable storage medium, which can be retrieved and executed to create or share data packets with System 130 components. The memory can include any non-transitory storage device, including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read-only memory (EPROM), flash memory, and the like. The processor can be configured to execute the processor-executable instructions stored on a non-transitory, machine-readable storage medium and in the hardware.The computer-readable storage medium can store instructions which, when executed by the processor, can implement error detection and correction during the implementation of CI / CD pipelines. In some embodiments, the system 130 can be configured to receive the log file and detect errors within it. Furthermore, relevant logs from the log file and the detected error can be processed by a (local) AI model 140, which can generate an initial error correction script for the detected error. In one embodiment, the local AI model 140 can be configured to automatically access and read the log file. In some embodiments, it can access the most recent log file. The local AI model 140 can be configured to correct the errors in the code that are recorded and stored in the log file. The specific path to the error (or the code or line of code that causes the error) can also be recorded in the log file.In one embodiment, the code corrected by the local AI model 140 and the log file associated with the project can be updated as soon as the error-prone code has been corrected, i.e., the specific error has been corrected, and the local AI model 140 can be configured to assign a new version number to the corrected code in the repository and / or store the files separately. In one embodiment, error detection and correction can be triggered for a specific job identifier, a merge request, commits, or submissions of a template for a new feature or version of the software. In another embodiment, the pipeline can be continuously monitored in near real-time, and upon detection of an error at runtime, a flag can be sent to an affected user / developer or project team so that correction can be initiated either automatically by the local AI model 140 or manually.In some embodiments, the local AI model 140 can be implemented within the server 120. In some embodiments, the local AI model 140 can be part of the server 120 or a separate system coupled to the server 120. In some embodiments, the local AI model 140 can be configured to continuously monitor the server 120 and the log files of the repositories it contains for real-time updates. Runtime errors (among other things) can also be stored in the log file, and the local AI model 140 can be configured to access this in real time or near real time to identify patterns in the log file for error detection. When detecting errors based on processing / analyzing the log file, the error can be traced back to specific sections, paths, or line numbers of files within the repository.Upon detection of an error, i.e., error-prone code, the local AI model 140 is configured to automatically correct the error-prone code in the file and update the file. The first error correction script can be configured to disable the error-prone code and / or replace it with at least part of the corrective action. If the first error correction script successfully corrects the error, the system 130 terminates its execution. If the first error correction script does not correct the error, the system 130 forwards a request to an external AI model 150 to correct the error. The external AI model 150 can be a generative AI model, a large language model (LLM), or a large multimodal model (LMM) configured to generate a second error correction script. The repository can then be updated with this second error correction script.In some embodiments, requirements can be iteratively submitted to the external AI model 150, and the second error correction script can be used to update the repository until a stop condition is met, the error is fixed, or a predetermined number of iterations are completed. If the error is not resolved by either the local AI model 140 or the external AI model 150, system 130 can be configured to notify developers of the unresolved issue by sending a message / notification (e.g., via email, message, or other log entry). If the error is resolved, system 130 can notify developers (by sending notifications to the developer device 110) that the specific error has been corrected and that the updated version of the codebase and log file is available in a specific location within the repository. In some implementations, the error-prone code can be annotated using a first visual indicator, and the annotation disables the code but does not delete it from the file. The replaced code in the project file is highlighted using a second visual indicator and enabled after the replaced code passes the runtime test. If the replaced code fails the runtime test, the process is repeated until alternative code is found to replace the error-prone code. If the local AI model 140 does not find alternative code, it is configured to notify the project team accordingly.In one implementation, any code inserted into the project can be replaced but not deleted, and error-prone code is commented on and / or highlighted with a visual indicator containing specific details and the path to the code in the log file. System 130 can leverage advanced generative AI and LLM models to automate error detection and correction processes. These models can be configured to analyze GitLab logs in real time to identify patterns indicative of errors and, based on model predictions, suggest and / or apply corrections, thereby streamlining the error management process. In some implementations, the error correction script generated by the local AI model 140 can display a Bidirectional Encoder Representations from Transformers (BERT) or T5 model to identify and resolve errors. BERT and T5 are machine learning models that help computers understand the meaning of text by analyzing the relationships between words in a sentence.In one embodiment, BERT is designed to help computers and systems understand the meaning of ambiguous language in texts by using the surrounding text to determine the context. In some embodiments, the local AI model 140 can be pretrained using masked language modeling (MLM) and next-sentence prediction techniques. In some embodiments, the local AI model 140 can be pretrained on various repositories available in the version control platform implemented by System 130. In one embodiment, the local AI model 140 can be trained on a user-defined database of GitLab bugs and fixes. The database can contain bug types, bug codes, and corrected code.In one embodiment, the local AI model 140 can be continuously fine-tuned if the error is initially not corrected by the local AI model 140, but subsequently by the external AI model 150. The local AI model 140 can be configured to search the repository for similar errors and solutions and use the best possible solution for the error-prone code. Furthermore, the external AI models can be larger models (e.g., those with more than one billion parameters) that may be accessible via application programming interfaces (APIs). In one example, the external AI models could correspond to models provided by OpenAI, Anthropic, and similar organizations. In another example, the external AI models could be an Azure-licensed Generative Pretrained Transformer (GPT) 4 model. In some implementations, the number of parameters in the local AI model can be smaller than that of the external AI model. The smaller number of parameters in the local AI model can enable computationally more efficient generation of error correction scripts compared to the external AI model.Experts will recognize that various other NLP or ML (machine learning) tools and methods can be used, and that all of these variations fall within the scope of this disclosure. With reference to Fig. 2, an exemplary workflow implemented by System 130 is shown. As shown, System 130 can be configured to receive updates 202 (which may contain new features or versions of the software) from one or more of the developer devices 110. The software and its updates 202 can be developed by a project team for a project, the project team comprising a number of developers with different access rights. The project can be implemented in a continuous development environment (CDE), which is typically used for the development and deployment of code by a number of developers concurrently. All information related to the project can be stored in a repository 220, which can be continuously updated in near real time.Repository 220 can contain various files related to the development, testing, and other aspects of the software project. Each project can be managed in a separate project repository within the main repository, and different versions / branches of the software / project, code development, tests, bug fixes, log files, and the like associated with each project can be managed in a structured or unstructured manner. In accordance with CDE practices, System 130 can be configured to integrate and / or deploy updates when received from the developer devices 110. System 130 can be configured to implement CI / CD pipelines that may include multiple jobs / tasks for integrating, testing, delivering, and / or deploying the software. Log data 210 can be managed during the implementation / execution of the CI / CD pipelines. The log data 210 can also be configured to display and / or explicitly flag errors that occur during the execution of the CI / CD pipelines. In some embodiments, the local AI model 140 can be connected to the repository 220. The local AI model 140 can be configured to continuously scan the log data 210, the repository 220, and the updates 202 to detect errors in near real time. The local AI model 140 can also track the latest versions of the code associated with the software being developed and tested. In some embodiments, the local AI model 140 can be configured to identify patterns indicating errors in the log data 210. In some embodiments, the local AI model 140 can also be configured to extract files (or parts thereof) from the repository 220 that are causing the errors. Such files can be parts of the code that are causing the errors. In some embodiments, the files can be identified by specific paths that lead to the directory, the file, and ultimately to the part of the code that is prone to errors. The code is typically stored and updated in the files within the project in the repository 220. For example, the code might contain functionality to perform a specific function as desired in the project.In one example, the code might be located in a file named "File1". This code could be a sorting algorithm, and the error might be found on line 5 or between line 5 and line 8 of the code within that file. This path to the error(s) is recorded in the log file and referred to as the specified path. In an example scenario, because the line number in the code changes when the update is implemented, a new log file can be created and linked to the log file that is being scanned and where the errors are corrected. Once the error is detected, the local AI model 140 can be configured to generate an initial error correction script that can be implemented to fix the error. This initial error correction script can be implemented / executed by either commenting out / disabling the error-causing parts of the code in the repository or replacing them with alternative code that does not cause errors. If the local AI model 140 is unable to correct the errors, the system 130 can be configured to send / transmit the log data 210 and the extracted files (or the error-causing code) to the external AI model 150, which can be configured to generate a second error correction script to fix the errors until a stop condition is met (i.e., a predetermined number of iterations have been performed or the error is resolved). The second error correction script can also be implemented / executed by either commenting out / disabling or replacing error-causing parts of the code in the repository with alternative code that does not cause errors, according to the second correction script. In some embodiments, the first and / or second error correction script is implemented in a new branch of repository 220, for example, in a cloned repository 220A. The version control platform that manages repositories 220 and 220A, and which can be implemented by System 130 or Server 120, can be configured to run the CI / CD pipeline after the implementation of the first and / or second error correction script. In some embodiments, a hearing module 204 can be configured to determine whether the CI / CD pipeline for the cloned repository 220A has been successfully implemented. If the CI / CD pipeline fails again, as indicated by 204A, System 130 can be configured to repeatedly perform the error detection and correction process until a stop criterion is met (e.g.,(whether the CI / CD pipeline runs successfully or the error detection and correction process is repeated up to a maximum retry threshold). System 130 can use the cloned repository 220A for subsequent iterations. If the CI / CD pipeline runs successfully, as specified in 204B, System 130 shuts down. With reference to Fig. 3, a method 300 for error detection and correction in CI / CD pipelines is described. In some embodiments, the method 300 can be implemented by the system 130 (or by a processor in the system 130). In step 302, the method 300 comprises the execution of a CI / CD pipeline by the system 130 based on updates (such as the updates 202 shown in Fig. 2) to software received from developer devices (such as the developer devices 110 from Fig. 1). The software can be managed in a repository (such as repository 220) by a version control platform such as GitLab. The repository 220 can contain processor-executable instructions for implementing the software. The updates can relate to the implementation of new features or versions of the software.The developers (using their developer devices 110) can send the updates as merge requests, commits, or submissions of predefined templates (which may contain project identifiers, authorization / authentication tokens, test branches, and the like) to implement the new feature or version of the software. In some embodiments, the method 300 may be integrated into the merge request pipelines and / or commit pipelines. In some embodiments, errors may occur when the CI / CD pipeline executes one or more jobs / tasks to integrate, test, deliver, and / or deploy software or features / versions thereof. In some embodiments, logs / log files / log data (such as the log data 210 shown in Fig. 2) may be generated during the implementation of the CI / CD pipelines.In some embodiments, the method 300 can be triggered for a predetermined set of jobs / tasks that are uniquely identifiable by corresponding identifiers that can be selected by the developers. In other embodiments, the method 300 can be triggered periodically at intervals specified by the developers. In step 304, the procedure 300 includes the detection of errors in the updates and / or code stored in the (version control) repository by the system 130 based on the log data generated during the execution of the CI / CD pipeline, using a local AI model (such as the local AI model 140 from Figures 1 and 2). In some embodiments, the local AI model 140 may be a natural language processing model configured to tokenize and analyze the code associated with the software. The local AI model 140 may use the code stored in the repository 220, as well as the updates provided by the developers and the log data 210. The local AI model 140 can analyze and detect errors in the code based on patterns in the log data 210 that indicate the presence of errors.In some embodiments, the local AI model 140 can also be configured to extract files from the repository that are causing the error. The files can be identified using their paths. Furthermore, the local AI model 140 can be configured to identify specific lines in the extracted files that are causing the error, enabling more efficient error correction. In step 306, the procedure 300 includes the execution of an initial error correction script by the system 130 to correct the detected error. In some embodiments, the implementation / execution of the initial error correction script can include disabling the error-causing parts of the code or replacing the error-causing parts of the code with alternative corrective code. In step 308, for errors that remain unresolved after the implementation of the first error correction script, the procedure 300 includes the iterative execution of a second error correction script by the system 130 using an external AI model (such as the external AI model 150 from Figures 1 and 2). The correction of the repository 220 with the second error correction script can be achieved by disabling and / or replacing the error-causing parts of the code. The external AI model 150 can be an LLM or any other generative AI model. In some examples, the external AI model 150 can have at least 1 billion parameters. In one example, the external AI model 150 can be one of the models provided by OpenAI. In some embodiments, the iterations can be terminated after one of the stopping conditions is met.In some embodiments, the stop conditions may include a predetermined number of iterations or the correction of the error. In some embodiments, if the second error correction script successfully corrects the error, it can be used to retrain the local AI model 140. In such embodiments, the local AI model 140 can be fine-tuned using a labeled dataset with the second correction script as the label and the log data and repository as input features. In some embodiments, supervised learning techniques can be used to fine-tune the local AI model 140. Typically, the local AI model 140 may not be able to correct the error because it is a novel or new situation for which the local AI model 140 may not have been trained.Fine-tuning the local AI model 140 with the second error correction script (which successfully fixes the error) can enable the local AI model 140 to learn how to handle similar situations. In step 310, if the fault remains unresolved after the stop condition has been met, procedure 300 includes the transmission of a notification of the failure to rectify the fault by system 130 to the developer devices 110. The notification can be delivered via email, webhook, API (e.g., to project management platforms like Jira), message, pop-up, additional log data, and similar methods. Developers can manually resolve the error after receiving the notification through their developer device 110. In some embodiments, a new branch of repository 220, for example, a cloned repository 220A, can be created to implement the first and / or second bug fix script. The version control platform that manages repositories 220 and 220A, and which can be implemented by System 130 or Server 120, can be configured to run the CI / CD pipeline after the first and / or second bug fix script has been implemented. In some embodiments, a hearing module 204 can be configured to determine whether the CI / CD pipeline for the cloned repository 220A has been successfully implemented. If the CI / CD pipeline fails again, as indicated by 204A, System 130 can be configured to reimplement procedure 300. Procedure 300 can be executed / repeated until a stop criterion is met (e.g.,(whether the CI / CD pipeline is running successfully or if procedure 300 is repeated up to a maximum retry threshold). Procedure 300 can be repeated using the cloned repository 220A for subsequent iterations. If the CI / CD pipeline runs successfully, as indicated by 204B, procedure 300 terminates. By providing an automated solution for error correction, System 130 and Procedure 300 reduce the burden on developers, accelerate integration and deployment implementation, and minimize downtime by enabling real-time or near-real-time error detection and correction in continuous integration and deployment pipelines. Furthermore, the continuous learning and improvement of the local AI model 140 enables it to handle new situations. With reference to Fig. 4, the computer system 400 can comprise an external storage device 410, a bus 420, main memory 430, read-only memory 440, mass storage device 450, a communication port 460, and a processor 470. A person skilled in the art will recognize that the computer system 400 can comprise more than one processor and one communication port. The processor 470 can comprise various modules associated with embodiments of the present disclosure. In one embodiment, the communication port 460 can be an RS-232 port for use with a modem-based dial-up connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber optic cabling, a serial port, a parallel port, or any other existing or future port. The communication port 460 can be selected depending on the network, for example, a local area network (LAN), a wide area network (WAN), or any network to which the computer system 400 can be connected. In one embodiment, the memory 430 can be a random-access memory (RAM) or any other dynamic memory device generally known in the art. The read-only memory can be any static memory device, for example (but not limited to) a PROM (programmable read-only memory) chip for storing static information, such as boot or BIOS (Basic Input / Output System) instructions for the processor 470. In one embodiment, the mass storage device 450 can be any current or future mass storage solution that can be used to store information and / or instructions. Examples of mass storage solutions include (but are not limited to) Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., with Universal Serial Bus (USB) and / or FireWire interfaces), one or more optical disks, RAID (Redundant Array of Independent Disks) storage, e.g., an array of hard disks (e.g., SATA arrays). In one embodiment, bus 420 connects the processor(s) 470 to the other memory and communication blocks. Bus 420 can be, for example, a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, a Small Computer System Interface (SCSI), USB, or the like, for connecting expansion cards, drives, and other subsystems, as well as other buses, such as a front-side bus (FSB) that connects the processor 470 to the computer system 400. Optionally, operator and management interfaces, such as a display, keyboard, joystick, and cursor control device, can be connected to bus 420 to support direct operator interaction with the computer system 400. Other operator and management interfaces can be provided via network connections made through communication port 460. The components described above serve only to illustrate various possibilities. The exemplary computer system 400 described above is not intended to limit the scope of this disclosure in any way. While various embodiments of the invention are described above, other and further embodiments of the invention can be developed without deviating from its basic scope. The scope of the invention is defined by the following claims. The invention is not limited to the described embodiments, versions, or examples, which were included to enable a person with average technical knowledge to manufacture and use the invention in combination with the information and knowledge available to such a person. The present disclosure provides a system and a method for detecting and correcting errors in software in continuous integration and continuous delivery (CI / CD) environments. The present disclosure provides a fallback mechanism that uses an external model for errors that the local model cannot correct. The present disclosure minimizes downtime by providing real-time or near real-time error detection and correction in continuous integration and deployment pipelines. The present disclosure provides a mechanism for the continuous learning and improvement of a local AI model by retraining it with successful bug fixes from an external AI model. The present disclosure reduces the effort required by developers by automating the error detection and correction process and accelerates integration and deployment. QUOTES INCLUDED IN THE DESCRIPTION This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature US 2024345904A1

[0003] US 10459695B2

[0004] US 11579962B2

[0005]

Claims

Method (300) for error detection and correction in continuous integration and continuous delivery (CI / CD) pipelines, wherein the method (300) comprises: execution of a CI / CD pipeline by a system (130) based on updates to a software received from one or more developer devices (110); detection of errors in the updates and / or in the code stored in a repository (220) by the system (130) by processing log data generated during the execution of the CI / CD pipeline by a local artificial intelligence model (AI model) (140); execution by the system (130) of an initial error correction script generated by the local AI model (140) to correct the detected errors;and for errors that remain unresolved after the implementation of the first error correction script, iterative execution of a second error correction script, generated by an external AI model (150), by the system (130) until a stop condition is met. Method (300) according to claim 1, wherein the local AI model (140) is configured to extract files from the repository (220) that caused the errors. Method (300) according to claim 1, wherein the execution of the first error correction script and / or the second error correction script comprises at least one of the following elements: disabling an error-causing part of the code or replacing the error-causing part of the code with an alternative code. Method (300) according to claim 1, wherein the method (300) is triggered upon implementation of one or a combination of the following elements: a merge request pipeline, a commit pipeline and a predetermined job defined in a template. Method (300) according to claim 1, wherein the method (300) is triggered at predetermined intervals. Method (300) according to claim 1, wherein, if the errors remain unresolved after the stop condition is satisfied, the method (300) comprises the system (130) transmitting a notification of the failure to correct the error to the one or more developer devices (110). Method (300) according to claim 1, wherein the local AI model (140) is pre-trained using one or a combination of the following elements: a masked language modeling technique or a next sentence prediction technique. Method (300) according to claim 1, wherein the method (300) comprises fine-tuning the local AI model (140) based on the second error correction script generated by the external AI model (150) when correcting the errors. Method (300) according to claim 1, wherein the method (300) for executing the first error correction script and / or the second error correction script comprises: cloning the repository (220) by the system (130) to obtain a cloned repository (220A); correcting the cloned repository (220A) by the system (130) with the first error correction script and / or the second error correction script; unditerative execution of the CI / CD pipeline by the system (130) on the cloned repository (220A) until a stop criterion is met. System (130) for error detection and correction in continuous testing and continuous delivery (CI / CD) pipelines, comprising a processor; and memory functionally coupled to the processor, the memory comprising one or more processor-executable instructions configured to cause the processor to: execute a CI / CD pipeline based on updates to a software received from one or more developer devices (110); detect errors in the updates and / or in the code stored in a repository (220) by processing log data generated during the execution of the CI / CD pipeline by a local artificial intelligence (AI) model (140); execute an initial error correction script generated by the local AI model (140) to correct the detected errors;and for errors that remain unresolved after the implementation of the first error correction script, iterative execution of a second error correction script generated by an external AI model (150) until a stop condition is met.

Images