Method, device, equipment and storage medium for continuous integration fault determination

Abstract

The application provides a method, device and equipment for continuous integration fault determination and a storage medium, and relates to the technical field of computer software operation and maintenance. The method comprises the following steps: when a pipeline anomaly is detected, acquiring multi-modal data, current environment data and benchmark environment data, wherein the multi-modal data comprises log features, index features, code features and configuration features; performing cross-modal feature fusion on the log features, the index features, the code features and the configuration features to generate a fusion feature vector; calculating the environment fingerprint similarity of the current environment data and the benchmark environment data; and inputting the fusion feature vector and the environment fingerprint similarity into a pre-trained classification model to generate a fault root cause classification result. The present scheme can enhance the correlation analysis capability of multi-source fault information, improve the accuracy of fault root cause positioning and classification judgment in a continuous integration scenario, and shorten the fault troubleshooting time.

Description

Technical Field

[0001] This invention relates to the field of computer software operation and maintenance technology, and specifically to a method, apparatus, device, and storage medium for continuous integration fault determination. Background Technology

[0002] In modern software development and DevOps practices, Continuous Integration (CI) has become a core component for enterprises to improve delivery efficiency and quality. With the widespread adoption of microservice architectures and increasing system complexity, enterprises typically need to maintain hundreds or even thousands of continuous integration pipelines, involving collaboration across multiple dimensions such as code changes, build scripts, environment configuration, and dependent services. However, the types of failures during the build process are becoming increasingly diverse, including compilation errors due to code defects, dependency conflicts caused by inconsistent environment configurations, build timeouts due to insufficient resources, and dependency failures caused by the unavailability of third-party services.

[0003] Existing monitoring tools can only detect the symptoms of failures (such as build failure logs) and cannot quickly locate the root cause. This forces operations personnel to manually analyze massive amounts of data, which is time-consuming and prone to missing crucial clues. In addition, the dynamic nature of the build environment further exacerbates the complexity of troubleshooting.

[0004] Therefore, improving the accuracy of root cause localization in continuous integration scenarios has become a technical problem that needs to be solved. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and storage medium for continuous integration fault determination, so as to improve the accuracy of fault root cause localization.

[0006] In a first aspect, this application provides a method for determining continuous integration faults, the method comprising:

[0007] When a pipeline anomaly is detected, multimodal data, current environment data, and baseline environment data are acquired. The multimodal data includes log features, indicator features, code features, and configuration features.

[0008] Cross-modal feature fusion is performed on the log features, the indicator features, the code features, and the configuration features to generate a fused feature vector;

[0009] Calculate the environmental fingerprint similarity between the current environmental data and the baseline environmental data;

[0010] The fused feature vector and the environmental fingerprint similarity are input into a pre-trained classification model to generate a fault root cause classification result.

[0011] Furthermore, the method also includes:

[0012] Based on the environmental fingerprint similarity, the fused feature vector, and the code features, a list of similar cases is determined from the fault mode library, which includes multiple historical repair cases.

[0013] Based on the list of similar cases, a recommended repair solution is determined.

[0014] Furthermore, determining a list of similar cases from the fault mode library based on the environmental fingerprint similarity, the fused feature vector, and the code features includes:

[0015] The Hamming distance is determined based on the environmental fingerprint similarity and the environmental fingerprint similarity of historical repair cases in the fault mode library;

[0016] The cosine similarity is determined based on the fused feature vector and the fused feature vector of historical repair cases in the fault mode library.

[0017] The Jaccard distance is determined based on the code characteristics and the code characteristics of historical repair cases in the failure mode library.

[0018] The comprehensive similarity is determined based on the Hamming distance, the cosine similarity, and the Jaccard distance.

[0019] All historical repair cases in the fault mode library are sorted according to their overall similarity to obtain a list of similar cases.

[0020] Furthermore, determining the comprehensive similarity based on the Hamming distance, the cosine similarity, and the Jaccard distance includes:

[0021] The comprehensive similarity is obtained by multiplying the Hamming distance by a first preset weight, adding the cosine similarity by a second preset weight, and adding the Jaccard distance by a third preset weight.

[0022] Furthermore, determining the recommended repair solution based on the list of similar cases includes:

[0023] Obtain the repair success rate of each historical repair case in the list of similar cases;

[0024] Based on the repair success rate and preset weight, as well as the comprehensive similarity, determine the expected repair success rate of all historical repair cases;

[0025] Based on the expected repair success rate, the recommended repair solution is determined.

[0026] Furthermore, determining the recommended repair solution based on the expected repair success rate includes:

[0027] Clone the current environment in the sandbox based on the current environment data;

[0028] The N repair schemes with the highest expected repair success rate are tested and verified in the sandbox to obtain a scoring result;

[0029] The repair solution corresponding to the highest score in the scoring results is taken as the recommended repair solution.

[0030] Furthermore, the current environment data includes static fingerprints, dynamic fingerprints, and construction context. Calculating the environmental fingerprint similarity between the current environment data and the baseline environment data includes:

[0031] Based on the hash algorithm, the current fingerprint hash values ​​of the static fingerprint, the dynamic fingerprint, and the construction context are determined;

[0032] The environmental fingerprint similarity is determined based on the current fingerprint hash value and the baseline fingerprint hash value corresponding to the baseline environment data.

[0033] Furthermore, acquiring the benchmark environment data includes:

[0034] The environmental fingerprint obtained from the last successfully constructed environmental fingerprint database is used as the baseline environmental data. The environmental fingerprint database includes traceable environmental fingerprints recorded through a blockchain structure.

[0035] Secondly, this application provides an apparatus for determining continuous integration faults, the apparatus comprising:

[0036] The acquisition module is used to acquire multimodal data, current environment data, and baseline environment data when a pipeline anomaly is detected. The multimodal data includes log features, indicator features, code features, and configuration features.

[0037] The feature generation module is used to perform cross-modal feature fusion on the log features, the indicator features, the code features and the configuration features using an attention mechanism model to generate a fused feature vector;

[0038] The similarity calculation module is used to calculate the environmental fingerprint similarity between the current environmental data and the benchmark environmental data;

[0039] The fault classification module is used to input the fused feature vector and the environmental fingerprint similarity into a pre-trained classification model to generate fault root cause classification results.

[0040] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0041] The memory stores computer-executed instructions;

[0042] The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any of the first aspects.

[0043] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0044] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0045] This application provides a method, apparatus, device, and storage medium for continuous integration fault determination. The method includes: acquiring multimodal data, current environment data, and baseline environment data when a pipeline anomaly is detected, and performing cross-modal fusion of log features, indicator features, code features, and configuration features; simultaneously, classifying fault root causes by combining the environmental fingerprint similarity of the current environment data and the baseline environment data. This solution can enhance the correlation analysis capability of multi-source fault information, improve the accuracy of fault root cause location and classification in continuous integration scenarios, and shorten fault troubleshooting time. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0047] Figure 1 A schematic diagram of the method for determining continuous integration faults provided in this application;

[0048] Figure 2 The system architecture diagram provided for this application;

[0049] Figure 3 A schematic diagram of the environmental fingerprint database and blockchain-based storage provided in this application;

[0050] Figure 4 A schematic diagram of the structure of the multi-head attention multimodal feature fusion model provided in this application;

[0051] Figure 5 A flowchart illustrating the process of similar case retrieval and repair recommendations provided for this application;

[0052] Figure 6 A schematic diagram of the sandbox verification and automated repair process provided for this application;

[0053] Figure 7 A schematic diagram of the hierarchical strategy management architecture provided for this application.

[0054] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0055] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0056] In a microservices architecture, pipelines typically connect code repositories, build execution environments, logging systems, monitoring systems, and configuration management components, completing build, testing, and pre-release checks after code submission, merging, or scheduled triggering.

[0057] Existing continuous integration fault handling solutions typically collect build logs, monitoring metrics, and pipeline configuration information after detecting build failures or pipeline anomalies. These information is then sent to operations personnel via an alerting platform for analysis. Some solutions also incorporate code change logs, using rule matching or experience-based judgment to determine the cause of failure. Their working principle primarily relies on analyzing a single information source or simply concatenating data from multiple sources to identify anomalies.

[0058] However, with the continuous increase in the number of pipelines and frequent changes in environment versions, the above solutions do not fully utilize the correlation between logs, metrics, code, and configuration, making it difficult to accurately distinguish different root causes such as code defects, environment drift, or configuration anomalies from the coupled multi-source information. Especially when the same fault symptom may be caused by different reasons, simple rules or shallow fusion methods are prone to misjudgment.

[0059] In view of this, this solution integrates four types of heterogeneous data: logs, metrics, code, and configuration, to capture deep correlations between cross-modal features. At the same time, it combines the environmental fingerprint similarity between the current environmental data and the benchmark environmental data to jointly determine the root cause of the failure.

[0060] In a suitable system deployment scenario, this solution can run in the cluster environment on which the continuous integration pipeline relies, and work in conjunction with log storage, metric storage, code repository and pipeline engine, thereby realizing automated root cause identification of abnormal pipelines under the existing continuous integration architecture, and providing more accurate judgment basis for subsequent processing.

[0061] Figure 1A flowchart illustrating the method for determining continuous integration faults provided in this application is shown below. Figure 1 As shown, it includes the following steps:

[0062] S101: When a pipeline anomaly is detected, acquire multimodal data, current environment data, and baseline environment data. Multimodal data includes log features, indicator features, code features, and configuration features.

[0063] In this application, pipeline anomalies serve as triggering conditions for the fault determination process, indicating that the continuous integration pipeline has entered a state of failure, timeout, interruption, or test failure. In specific implementations, the execution entity can be deployed on the service node associated with the continuous integration pipeline engine, or on an analytics server that communicates with log storage, metric storage, code repository, and configuration management components. This execution entity receives anomaly events pushed by the pipeline engine. These events carry pipeline identifiers, build task identifiers, trigger times, code branch identifiers, and execution node identifiers. Using these anomaly events as retrieval keys, it synchronously retrieves multimodal data related to the current anomaly within a preset time window. Log features in the multimodal data are used to describe the fault behavior in build logs, test logs, and pre-deployment check logs. Metric features are used to describe the runtime metrics collected before and after the anomaly, such as processor utilization, memory usage, disk read / write latency, network error count, and container restart count. Code features are used to characterize the code commit content, changed file paths, number of commits, dependency file modifications, and interface definition changes corresponding to this pipeline. Configuration features are used to characterize changes in pipeline scripts, build parameters, container image identifiers, dependency version lists, environment variables, resource quotas, and external service connection parameters. Current environment data is used to characterize the real-time state of the build environment when the anomaly occurred, and baseline environment data is used to characterize the reference environment state before the pipeline ran normally.

[0064] S102: Perform cross-modal feature fusion on log features, indicator features, code features, and configuration features to generate a fused feature vector.

[0065] Specifically, log features, metric features, code features, and configuration features are mapped to a unified feature space, then input into an attention mechanism model for correlation learning and weighted aggregation, outputting a fused feature vector. This computational process enables the model to weight and aggregate information from different modalities based on their relevance; for example, anomaly information in logs can be correlated with code changes or configuration changes.

[0066] In one possible implementation, the attention mechanism model can be implemented using a network structure suitable for cross-modal feature fusion. It encodes the mutual influence of various features and, after appropriate transformation, obtains a fixed-length fused feature vector. To ensure the stability of the fusion result, the input features can also be normalized or regularized during the training phase. The attention allocation mechanism characterizes the correlation strength between different modalities, enabling the differences in potential root causes under the same fault manifestation to be distinguished in a unified feature space. For example, when all logs show construction failure, if the model identifies a high correlation weight between code changes and log error locations, and a low weight for environment-related factors, the fused feature vector will be more biased towards code defect representation. If the correlation weight between abnormal indicators and configuration changes significantly increases, the fused feature vector will contain more obvious environmental changes or configuration anomaly features, thus providing a distinguishable representation basis for subsequent root cause classification.

[0067] S103: Calculate the environmental fingerprint similarity between the current environmental data and the baseline environmental data.

[0068] In this application, environmental fingerprint similarity is used to measure the consistency between current environmental data and baseline environmental data. To make different forms of environmental information comparable, the executing entity first constructs environmental fingerprints for both the current and baseline environmental data. An environmental fingerprint can consist of multiple features from the environmental data, such as operating system version, tool version, dependency information, resource status, runtime parameters, and contextual information related to the build and execution. These features can be normalized and encoded to generate the current and baseline environmental fingerprints; for example, hash encoding can be used.

[0069] In one implementation, multiple features from the current environment data are arranged in a preset order and hashed to obtain the current environment fingerprint. A baseline environment fingerprint is obtained using the same method. The current and baseline environment fingerprints are input into a distance metric function to obtain an environment fingerprint similarity score in the range of 0 to 1, where a value closer to 1 indicates a more consistent environment, and a value closer to 0 indicates a greater difference. Specifically, the current environment data includes static fingerprints, dynamic fingerprints, and the construction context. Based on a hash algorithm, the current fingerprint hash values ​​of the static fingerprint, dynamic fingerprint, and construction context are determined. These three are then normalized and encoded according to a preset field order and input into the hash calculation module to generate the current fingerprint hash value. Subsequently, the system reads the pre-stored baseline fingerprint hash value from the baseline environment data and compares the two with the similarity calculation module. The comparison can be based on the number of consistent bits in the hash string, Hamming distance, or normalized matching coefficient to obtain the environment fingerprint similarity, thus characterizing the degree of closeness between the current environment and the baseline environment.

[0070] In this implementation, by uniformly mapping static features, dynamic features, and construction context to hash results, environmental differences can be quickly encoded and compared. The comparison results are used as a quantitative basis for the degree of environmental similarity, which can more accurately identify environmental drift and environmental reuse, and improve the ability to determine the association with historically successfully constructed benchmark environments.

[0071] In another implementation, environmental fingerprint similarity is calculated using a weighted similarity algorithm. For discrete fields of each feature in the environmental data, if the current value matches the baseline value of the benchmark environmental data, that field receives a higher score; otherwise, different scores are assigned based on the degree of difference. For numerical fields, similarity scores can be calculated using normalized distance. For set fields, similarity scores can be calculated using set matching degree. Let the environmental fingerprint contain n fields, with each field having a weight of w. i The field similarity score is s i Then, the environmental fingerprint similarity can be represented by each field w. i Multiply by s i Then sum them up and divide by the total weights.

[0072] This step involves a structured comparison between the current fault environment and a reference environment, enabling the classification model to utilize not only the fault behavior itself but also evidence of environmental deviation. When the environmental fingerprint similarity is significantly low, the classification stage can more easily identify environment-related root causes; when the environmental fingerprint similarity is high, the classification stage can more easily identify code defect-type root causes.

[0073] S104: Input the fused feature vector and environmental fingerprint similarity into the pre-trained classification model to generate the root cause classification result of the fault.

[0074] In this application, a classification model is used to generate root cause classification results for faults based on fused feature vectors and environmental fingerprint similarity. In its implementation, the classification model is deployed in a fault analysis service and trained offline based on continuously integrated historical fault samples. Each training sample includes log features, indicator features, code features, configuration features, current environmental data, corresponding baseline environmental data, and root cause categories labeled with manual confirmation or historical processing conclusions. During training, a fused feature vector is first obtained using the same attention mechanism model as in S102, and then environmental fingerprint similarity is obtained through the same environmental fingerprint construction and environmental fingerprint similarity calculation process as in S103. The two are then jointly input into the classification model.

[0075] After receiving the fused feature vector and environmental fingerprint similarity, the classification model outputs the probability distribution of each root cause category. The executing entity can select the category with the highest probability as the root cause classification result and save the corresponding probability value as the confidence level.

[0076] This application provides a method for continuous integration fault determination, comprising: when a pipeline anomaly is detected, acquiring multimodal data, current environment data, and baseline environment data, wherein the multimodal data includes log features, indicator features, code features, and configuration features; employing an attention mechanism model to perform cross-modal feature fusion of log features, indicator features, code features, and configuration features to generate a fused feature vector; calculating the environmental fingerprint similarity between the current environment data and the baseline environment data; and inputting the fused feature vector and the environmental fingerprint similarity into a pre-trained classification model to generate a fault root cause classification result. In this application, by uniformly collecting log, indicator, code, configuration, and environment information around the abnormal pipeline, using an attention mechanism model to extract the correlation features between multimodalities, and introducing the difference between the current environment and the reference environment into classification inference in the form of environmental fingerprint similarity, a joint root cause judgment process for continuous integration scenarios is formed. This enables the differentiation of different root causes when the same fault manifestation corresponds to multiple potential causes, while retaining traceable evidence of environmental changes.

[0077] Based on the aforementioned embodiments, after obtaining the root cause classification results, a recommended remediation plan can be further determined for the root cause of the fault. Specifically, this includes the following steps:

[0078] S105: Based on environmental fingerprint similarity, fused feature vectors and code features, determine a list of similar cases from the fault mode library, which includes multiple historical repair cases.

[0079] In one implementation, the environmental fingerprint similarity, fused feature vector, and code features of the current fault are input into the case retrieval module. The case retrieval module performs a unified vectorized representation of historical repair cases within the fault mode database and calculates the comprehensive similarity between the current fault and each historical case. The comprehensive similarity can be obtained by weighting the environmental fingerprint similarity, feature vector similarity, and code feature matching degree, where the weights can be set based on the repair success rate or case credibility of historical cases. The retrieval module sorts the cases from high to low comprehensive similarity and selects several cases from those meeting a threshold condition as a list of similar cases, thus ensuring that the cases in the list maintain consistency with the current fault in terms of environmental drift, feature behavior, and code change patterns.

[0080] S106: Determine the recommended repair solution based on the list of similar cases.

[0081] After obtaining a list of similar cases, a recommended remediation plan is generated based on the remediation measures, post-remediation verification results, and expected remediation success rate for each historical remediation case. This recommended plan can include a single remediation measure or multiple candidate remediation measures ranked by priority, and can include corresponding applicable conditions and rollback conditions. When multiple historical remediation cases point to different remediation measures, the system filters them according to similarity, success rate, and number of historical verifications, outputting a recommended remediation plan with a higher match to the current fault. Once this plan is generated, it can be directly executed by pipeline maintenance personnel, or further validated in a sandbox environment to determine the final remediation action.

[0082] By combining environmental fingerprint similarity, fused feature vectors, and code features for historical case retrieval, it is possible to locate historical repair cases that are closer to the current fault from the fault mode library, and generate more targeted repair recommendations accordingly. This improves the accuracy of historical experience reuse and enhances the matching degree and processing efficiency of fault repair decisions.

[0083] Based on the foregoing embodiments, step S105, which involves determining the list of similar cases, includes:

[0084] S1051. Determine the Hamming distance based on the environmental fingerprint similarity and the environmental fingerprint similarity of historical repair cases in the fault mode library.

[0085] S1052. Determine the cosine similarity based on the fused feature vector and the fused feature vector of historical repair cases in the fault mode library.

[0086] S1053. Determine the Jaccard distance based on code characteristics and the code characteristics of historical repair cases in the fault mode library.

[0087] S1054. Determine the comprehensive similarity based on Hamming distance, cosine similarity, and Jaccard distance.

[0088] The similarity in three dimensions—environmental fingerprint similarity, fused feature vector, and code feature—is calculated respectively, and the comprehensive similarity is calculated based on these three similarities.

[0089] In one implementation, the Hamming distance is multiplied by a first preset weight, then the cosine similarity is multiplied by a second preset weight, and finally the Jaccard distance is multiplied by a third preset weight to obtain the comprehensive similarity. Specifically, the Hamming distance, cosine similarity, and Jaccard distance can be normalized to the same dimension and then linearly combined with their corresponding weights. The first, second, and third preset weights can be obtained through offline training using historical fault samples and set according to the influence of environmental difference sensitivity, semantic feature consistency, and code change overlap on the three types of indicators. This allows the comprehensive similarity to simultaneously reflect the matching of environmental, log indicator cross-modal feature fusion features, and code change features. After the comprehensive similarity is calculated, it can be used as the basis for ranking historical repair cases; a higher value indicates a stronger correlation between the candidate case and the current fault scenario.

[0090] The comprehensive similarity not only retains the sensitivity of Hamming distance to environmental fingerprint differences, but also retains the ability of cosine similarity to characterize the directional relationship of fused features and the ability of Jaccard distance to express the differences in code feature sets. This makes the similar case screening results closer to the actual root cause features of the fault, and improves the accuracy of subsequent case retrieval and repair recommendations.

[0091] S1055. Sort all historical repair cases in the fault mode library according to their comprehensive similarity to obtain a list of similar cases.

[0092] A list of similar cases is generated, ranked from highest to lowest overall similarity. If different cases have the same overall similarity, they can be further distinguished based on fine-grained matching results of environmental fingerprint similarity or code features.

[0093] This approach incorporates environmental differences, cross-modal feature fusion features, and code change features into a unified evaluation framework, freeing the selection of historical remediation cases from reliance on information from a single source. The list of similar cases directly reflects the historical handling experience most closely related to the current fault, thereby providing a more accurate candidate set for subsequent remediation recommendations and improving case reuse efficiency and fault decision consistency.

[0094] Based on the aforementioned embodiments, after obtaining the list of similar cases, step S106, when determining the recommended repair scheme, needs to consider the repair success rate of each recommended repair scheme, specifically including the following steps:

[0095] S1061. Obtain the repair success rate of each historical repair case in the list of similar cases.

[0096] The success rate of a repair is pre-determined based on factors such as whether the repair was successful on the first attempt, whether manual intervention was required, and the stability after the repair. For example, if a repair is successful on the first attempt and runs stably for 24 hours, the success rate is 100%.

[0097] S1062. Based on the repair success rate, preset weights, and comprehensive similarity, determine the expected repair success rate for all historical repair cases.

[0098] The purpose of this step is to optimize the ranking of the similar case list based on the repair success rate. Specifically, the repair success rate and overall similarity are input into a preset weighted calculation unit, which generates the corresponding expected repair success rate according to the preset weights. The weighted calculation unit can be implemented using a linear weighting method, that is, the repair success rate and overall similarity are multiplied by their respective weights and then summed to obtain a comprehensive score reflecting the feasibility of repair in the current scenario.

[0099] S1062. Based on the expected success rate of the repair, the recommended repair plan is determined.

[0100] After performing the above calculations on all historical remediation cases in the similar case list, the expected remediation success rate of each case can be obtained, and the remediation action, configuration change or rollback plan corresponding to the historical remediation case with the highest expected remediation success rate can be determined as the recommended remediation plan.

[0101] By jointly evaluating the actual effectiveness of historical repair cases with the similarity to the current failure scenario, the recommended repair solutions can better align with the root causes of the current pipeline anomalies, thereby generating more targeted handling suggestions and enabling the reuse of historical experience in similar failure scenarios. Because the expected repair success rate also considers historical repair effects, the final recommendation result is less reliant on a single historical success record, increasing the probability of successful repair decisions.

[0102] Furthermore, based on any of the above embodiments, when determining the recommended repair solution, multiple determined solutions can be simulated and verified to determine the solution with the best repair effect. Specifically, this includes the following steps:

[0103] S10621. Clone the current environment in the sandbox based on the current environment data.

[0104] S10622. In the sandbox, perform repair verification on the N repair schemes with the highest expected repair success rate and obtain the scoring results.

[0105] S10623. The repair solution corresponding to the highest score in the scoring results shall be used as the recommended repair solution.

[0106] The candidate solutions are then further screened based on the objective scores obtained from isolation verification, ensuring that the recommended remediation results are consistent with the actual executable state of the current environment. By adopting this implementation method, the selection criterion for recommended remediation solutions is expanded from simply historical success rates to the verification results after environment cloning. This improves the accuracy and feasibility of the remediation recommendations and reduces the risks associated with direct trial and error in a real pipeline environment.

[0107] In some embodiments, to achieve traceability of baseline environment data, a traceable environment fingerprint database is established using a blockchain-like approach, containing environment snapshot information from each code change, environment modification, pipeline failure, and failure repair. When acquiring baseline environment data, the last successfully constructed environment fingerprint is retrieved from the fingerprint database and used as the baseline environment data. The environment fingerprint database can be deployed in a combined structure of distributed storage nodes and on-chain ledgers. Only environment fingerprint summaries, index identifiers, and audit information are recorded on-chain; the complete fingerprint content can be stored in a controlled data area to reduce on-chain load and maintain query efficiency. The acquisition of baseline environment data is accomplished by calling an on-chain query interface. First, the on-chain record corresponding to the most recent successful construction is retrieved based on the pipeline identifier and project identifier. Then, the complete environment fingerprint is extracted from the environment fingerprint database based on the index in the record and output to the subsequent similarity calculation module.

[0108] This solution leverages the traceable records formed by the blockchain structure to ensure clear source of benchmarks and reliable evidence storage, thereby providing consistent data reference for subsequent environmental fingerprint similarity calculations and fault root cause determination.

[0109] The overall solution will be introduced below with a specific example.

[0110] First, deploy a fault self-healing operator and a policy resolver in the cluster, defining fault self-healing policy templates and binding rules. The fault self-healing operator continuously listens for build events in the continuous integration pipeline, coordinating the entire fault diagnosis and self-healing process. The policy resolver parses pipeline tags, matches policy bindings, merges policies, and generates the final fault self-healing policy.

[0111] Figure 2 The system architecture diagram provided in this application is for reference only. Figure 2This system, centered on a fault self-healing operator, comprises a strategy management layer, a multimodal acquisition layer, an environmental fingerprint layer, a feature fusion layer, a fault mode library, a diagnostic layer, a sandbox validation layer, and an automated execution layer. The strategy management layer achieves large-scale, efficient pipeline management through strategy templates and pipeline tagging mechanisms. The multimodal acquisition layer collects four types of feature data from log storage, metric storage, code repositories, and the pipeline engine. The environmental fingerprint layer collects snapshot information of the built environment and then constructs a blockchain-based, traceable environmental fingerprint library; when a fault occurs, it calculates similarity between the current environmental fingerprint and the baseline environment. The feature fusion layer deeply fuses the four types of features collected by the multimodal acquisition layer and the similarity features calculated by the environmental fingerprint layer using a multi-head attention Transformer to obtain a fused feature vector. The fault mode library stores historical fault cases and provides similar case retrieval functionality. The diagnostic layer performs root cause classification and confidence assessment based on the fused feature vector. The sandbox validation layer dynamically creates sandbox environments to comprehensively validate and evaluate candidate solutions and provides the optimal validation solution. The automated execution layer is responsible for the automated repair of the production environment and provides feedback on the repair results. The entire system forms a complete closed loop from fault detection, fault diagnosis, fault verification, fault repair, and fault logging.

[0112] Figure 3 This application provides a schematic diagram of the environmental fingerprint database and blockchain-based storage, as shown below. Figure 3 As shown, environmental fingerprint collection mainly involves gathering static fingerprints, dynamic fingerprints, and constructing a context. Then, a fingerprint hash is calculated using SHA-256 to obtain the current environmental fingerprint. This collected current environmental fingerprint is ultimately stored in a blockchain-based fingerprint storage system. The blockchain-based fingerprint storage system uses a chain structure to record each environmental change. Each block contains a fingerprint hash, timestamp, reason for the change, the person making the change, and the hash of the previous block, ensuring that the change history cannot be tampered with. Environmental fingerprint comparison involves first performing fingerprint difference analysis on the current fingerprint and the baseline fingerprint (the environmental fingerprint saved from the last successful execution), and then calculating a comprehensive similarity score using multi-factor similarity (feature similarity, fingerprint similarity, code similarity) (the specific calculation method is described in the aforementioned embodiment and will not be elaborated here).

[0113] After obtaining the comprehensive similarity score, the root cause of the failure can be determined using a classification model, based on the aforementioned embodiments. Then, historical repair cases can be retrieved from the failure mode library based on the comprehensive similarity score. Alternatively, the comprehensive similarity score can be used to first determine if the failure is due to environmental drift, triggering a corresponding repair decision. If the comprehensive similarity score is less than a preset value, a severe drift is determined, triggering a rollback operation to revert to the baseline environment. The rollback process references the content stored in the blockchain-style fingerprint. If the comprehensive similarity score determines that no severe drift has occurred, the root cause of the failure is then determined based on the classification model.

[0114] Figure 4 This is a schematic diagram of the structure of the multi-head attention multimodal feature fusion model provided in this application. Figure 4 As shown, the structure mainly includes a modality coding layer, a multi-head attention layer, and a fusion layer. The modality coding layer consists of four independent modality encoders: a BERT encoder for log features, an LSTM encoder for metric features, an MLP encoder for code features, and a CNN encoder for configuration features, each outputting modality features of different dimensions. The multi-head attention layer uses four attention heads to capture four cross-modal relationships: log-metric, log-code, code-configuration, and metric-configuration, outputting 256-dimensional features from each attention head. The feature fusion layer concatenates the outputs of the four attention heads and reduces the dimensionality to obtain a 128-dimensional fused feature vector, which is then concatenated with the environmental fingerprint similarity to obtain the input to the classification model.

[0115] Figure 5 A flowchart illustrating the process of similar case retrieval and repair recommendations provided for this application is shown below. Figure 5 As shown, the system collects the feature vector, environmental fingerprint, and code changes of the current fault. Then, it calculates the similarity in three dimensions with historical cases in the fault mode library: feature similarity (using cosine similarity to calculate the distance between the current fused feature vector and the feature vector of historical cases), fingerprint similarity (using Hamming distance to calculate the similarity between the current environmental fingerprint and the fingerprint of historical cases), and code similarity (using Jaccard similarity to calculate the similarity between the current code change and the code change of historical cases). These similarities are then weighted (e.g., feature similarity: fingerprint similarity: code similarity = 5:3:2) to obtain a comprehensive similarity. The comprehensive similarity of all cases is calculated sequentially, and the cases are sorted by similarity to obtain the top K cases. The top K cases are then weighted and adjusted according to the repair success rate. Finally, a recommended repair solution and the expected repair success rate are given.

[0116] Figure 6 The diagram illustrating the sandbox verification and automated repair process provided in this application is shown below. Figure 6 Policy diagnosis involves generating candidate repair solutions through the diagnostic layer. Policy matching uses a policy parser to parse pipeline tags, policy templates, and policy binding rules to determine the effective policy, assess its confidence threshold, and determine whether verification in a sandbox environment is necessary. The sandbox verification phase clones a complete environment based on the current fingerprint to perform parallel verification of candidate repair solutions. The scoring results of the candidate solutions are then obtained and recorded, and the ranking based on the scores is optimized to obtain the optimal solution. Solutions that successfully execute and pass verification in the sandbox will be implemented for repair in the production environment. The feedback phase collects and records the verification results and updates the fault mode library for subsequent diagnostic optimization.

[0117] Figure 7 A schematic diagram of the hierarchical strategy management architecture provided for this application. (See diagram below.) Figure 7 As shown, the strategy definition layer maintains some basic templates, the strategy binding layer maintains the binding relationships between teams, environments, languages, etc., and the pipeline layer mainly maintains pipeline tags. The tag collector collects and parses pipeline tags, calculates the binding priority (team > environment > language) based on the binding relationships in the strategy binding layer, and then merges the tags with the strategies in the strategy definition layer to finally issue its own effective strategy for each pipeline.

[0118] This application implements a continuous integration (CI) fault self-healing system based on multimodal feature fusion and an environment fingerprint database through the collaborative work of a core controller and eight core modules, constructing a complete closed-loop operation and maintenance system for CI fault self-healing. The system adopts a declarative management paradigm, abstracting diverse CI pipeline faults into four standard categories: code defects, environment drift, resource insufficiency, and dependency failures. Users only need to focus on the desired build state without intervening in complex fault handling processes. A hierarchical management mechanism using strategy templates and label selectors enables batch management of pipelines and consistent management of heterogeneous environments. Fault classification based on multi-head attention multimodal feature fusion, combined with a hybrid decision-making mechanism of fault pattern library and real-time prediction, employs a multi-factor similarity retrieval and success rate-weighted ranking multi-objective optimization algorithm to generate repair solutions. The entire process is automated from fault detection to repair completion. Sandbox isolation verification ensures operational security, blockchain-based storage guarantees the immutability of change history, and a retesting verification mechanism ensures persistent repair rather than superficial symptom relief. In the practical application of the intelligent vehicle cloud R&D platform, it not only reduces the time for resolving dependency conflicts, but also saves resource costs. Developers do not need to learn how to operate the consoles of various cloud platforms; they can define build requirements through declarative configuration files.

[0119] In summary, this application's solution introduces a blockchain-based environmental fingerprint database to achieve tamper-proof recording and traceable auditing of environmental configuration changes; it introduces a multi-head attention multimodal feature fusion mechanism to capture cross-modal correlations between logs, metrics, code, and configuration features, improving diagnostic accuracy; it introduces a sandbox verification mechanism to isolate and verify remediation solutions before execution in the production environment, avoiding impact on the production environment's stability and improving the success rate of remediation; it constructs a similar case retrieval system to achieve intelligent reuse of historical fault experience, improving the remediation time for recurring faults; and it introduces a hierarchical policy management system to achieve automated management capabilities for large-scale pipelines through policy templates and tag selectors, reducing the complexity of operation and maintenance management.

[0120] This application also provides an apparatus for determining continuous integration faults, the apparatus comprising:

[0121] The acquisition module is used to acquire multimodal data, current environment data, and baseline environment data when a pipeline anomaly is detected. The multimodal data includes log features, indicator features, code features, and configuration features.

[0122] The feature generation module is used to perform cross-modal feature fusion of log features, indicator features, code features and configuration features using an attention mechanism model to generate a fused feature vector;

[0123] The similarity calculation module is used to calculate the environmental fingerprint similarity between the current environmental data and the benchmark environmental data;

[0124] The fault classification module is used to input the fused feature vector and environmental fingerprint similarity into a pre-trained classification model to generate fault root cause classification results.

[0125] Furthermore, the device also includes a repair recommendation module for:

[0126] Based on environmental fingerprint similarity, fused feature vectors and code features, a list of similar cases is determined from the fault mode library, which includes multiple historical repair cases.

[0127] Based on the list of similar cases, a recommended repair solution was determined.

[0128] Furthermore, the repair recommendation module is also used to: determine the Hamming distance based on the environmental fingerprint similarity and the environmental fingerprint similarity of historical repair cases in the fault mode library; determine the cosine similarity based on the fused feature vector and the fused feature vector of historical repair cases in the fault mode library; determine the Jaccard distance based on the code features and the code features of historical repair cases in the fault mode library; determine the comprehensive similarity based on the Hamming distance, cosine similarity, and Jaccard distance; and sort all historical repair cases in the fault mode library according to the comprehensive similarity to obtain a list of similar cases.

[0129] The improved recommendation module is also used to: multiply the Hamming distance by the first preset weight, add the cosine similarity multiplied by the second preset weight, and add the Jaccard distance multiplied by the third preset weight to obtain the comprehensive similarity.

[0130] The repair recommendation module is also used to: obtain the repair success rate of each historical repair case in the similar case list; determine the expected repair success rate of all historical repair cases based on the repair success rate, preset weight, and comprehensive similarity; and determine the repair recommendation scheme based on the expected repair success rate.

[0131] The repair recommendation module is also used for: cloning the current environment in the sandbox based on the current environment data; verifying the N repair solutions with the highest expected repair success rate in the sandbox and obtaining a score result; and using the repair solution corresponding to the highest score in the score result as the repair recommendation solution.

[0132] Furthermore, the similarity calculation module is specifically used to: determine the current fingerprint hash value of the static fingerprint, dynamic fingerprint, and construction context based on the hash algorithm; and determine the environmental fingerprint similarity based on the current fingerprint hash value and the benchmark fingerprint hash value corresponding to the benchmark environmental data.

[0133] The apparatus provided in this embodiment can execute the methods in the above method embodiments, and its implementation principle and technical effect are similar, so it will not be described in detail here.

[0134] This application also provides an electronic device comprising: at least one processor and a memory. Optionally, the electronic device further includes a communication component. The processor, memory, and communication component are connected via a bus.

[0135] In a specific implementation, at least one processor executes computer execution instructions stored in memory, causing at least one processor to perform the above-described method.

[0136] The specific implementation process of the processor can be found in the above method embodiments, and its implementation principle and technical effect are similar, so it will not be repeated here.

[0137] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0138] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0139] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0140] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0141] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0142] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0143] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0144] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0146] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0147] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0148] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0149] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for continuous integration fault determination, characterized in that, The method includes: When a pipeline anomaly is detected, multimodal data, current environment data, and baseline environment data are acquired. The multimodal data includes log features, indicator features, code features, and configuration features. Cross-modal feature fusion is performed on the log features, the indicator features, the code features, and the configuration features to generate a fused feature vector; Calculate the environmental fingerprint similarity between the current environmental data and the baseline environmental data; The fused feature vector and the environmental fingerprint similarity are input into a pre-trained classification model to generate a fault root cause classification result.

2. The method according to claim 1, characterized in that, The method further includes: Based on the environmental fingerprint similarity, the fused feature vector, and the code features, a list of similar cases is determined from the fault mode library, which includes multiple historical repair cases. Based on the list of similar cases, a recommended repair solution is determined.

3. The method according to claim 2, characterized in that, The step of determining a list of similar cases from the fault mode library based on the environmental fingerprint similarity, the fused feature vector, and the code features includes: The Hamming distance is determined based on the environmental fingerprint similarity and the environmental fingerprint similarity of historical repair cases in the fault mode library; The cosine similarity is determined based on the fused feature vector and the fused feature vector of historical repair cases in the fault mode library. The Jaccard distance is determined based on the code characteristics and the code characteristics of historical repair cases in the failure mode library. The comprehensive similarity is determined based on the Hamming distance, the cosine similarity, and the Jaccard distance. All historical repair cases in the fault mode library are sorted according to their overall similarity to obtain a list of similar cases.

4. The method according to claim 3, characterized in that, The determination of the comprehensive similarity based on the Hamming distance, the cosine similarity, and the Jaccard distance includes: The comprehensive similarity is obtained by multiplying the Hamming distance by a first preset weight, adding the cosine similarity by a second preset weight, and adding the Jaccard distance by a third preset weight.

5. The method according to claim 3 or 4, characterized in that, The step of determining the recommended repair solution based on the list of similar cases includes: Obtain the repair success rate of each historical repair case in the list of similar cases; Based on the repair success rate and preset weight, as well as the comprehensive similarity, determine the expected repair success rate of all historical repair cases; Based on the expected repair success rate, the recommended repair solution is determined.

6. The method according to claim 5, characterized in that, The step of determining the recommended repair solution based on the expected repair success rate includes: Clone the current environment in the sandbox based on the current environment data; The N repair schemes with the highest expected repair success rate are tested and verified in the sandbox to obtain a scoring result; The repair solution corresponding to the highest score in the scoring results is taken as the recommended repair solution.

7. The method according to any one of claims 1-4, characterized in that, The current environment data includes static fingerprints, dynamic fingerprints, and construction context. Calculating the environmental fingerprint similarity between the current environment data and the baseline environment data includes: Based on the hash algorithm, the current fingerprint hash values ​​of the static fingerprint, the dynamic fingerprint, and the construction context are determined; The environmental fingerprint similarity is determined based on the current fingerprint hash value and the baseline fingerprint hash value corresponding to the baseline environment data.

8. The method according to any one of claims 1-4, characterized in that, Acquiring the baseline environment data includes: The environmental fingerprint obtained from the last successfully constructed environmental fingerprint database is used as the baseline environmental data. The environmental fingerprint database includes traceable environmental fingerprints recorded through a blockchain structure.

9. A device for continuous integration fault determination, characterized in that, The device includes: The acquisition module is used to acquire multimodal data, current environment data, and baseline environment data when a pipeline anomaly is detected. The multimodal data includes log features, indicator features, code features, and configuration features. The feature generation module is used to perform cross-modal feature fusion on the log features, the indicator features, the code features and the configuration features using an attention mechanism model to generate a fused feature vector; The similarity calculation module is used to calculate the environmental fingerprint similarity between the current environmental data and the benchmark environmental data; The fault classification module is used to input the fused feature vector and the environmental fingerprint similarity into a pre-trained classification model to generate fault root cause classification results.

10. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images