Component dependency hierarchy determination methods, devices, equipment and media

Abstract

This application provides a method, apparatus, device, and medium for determining component dependency levels. The method includes: generating a component dependency tree based on an unordered component list and the source code of the components in the unordered component list, where the unordered component list represents a list of components corresponding to the target continuous integration pipeline; parsing the dependency paths in the component dependency tree to obtain a row table file, which includes all dependency paths corresponding to the component dependency tree, and all dependency paths are independent of each other; obtaining the level of each dependent component based on its position in the row table file; and determining the component dependency level of the target continuous integration pipeline based on the level of each dependent component. The method of this application improves the efficiency and accuracy of determining component dependency levels.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, device and medium for determining component dependency hierarchy. Background Technology

[0002] In large-scale enterprise applications developed based on service-oriented architecture technology, large monolithic services are broken down into dozens or hundreds of independently running services. There can be hundreds of components that can run independently, and the dependency levels between components can reach dozens of levels.

[0003] In existing technologies, configuring the dependency hierarchy between components by operations engineers can result in poor configuration effectiveness. Summary of the Invention

[0004] This application provides a method, apparatus, device, and medium for determining component dependency hierarchy, in order to solve the problem of poor configuration effect in the prior art.

[0005] Firstly, this application provides a method for determining component dependency hierarchy, including:

[0006] Based on the unordered component list and the source code of the components in the unordered component list, a component relationship dependency tree is generated. The unordered component list represents the list of components corresponding to the target continuous integration pipeline.

[0007] The dependency paths of the component relationship dependency tree are parsed to obtain a row table file. The row table file includes all dependency paths corresponding to the component relationship dependency tree, and all dependency paths are independent of each other.

[0008] Based on the positional relationship of each dependent component in the row table file, the hierarchy of each dependent component is obtained;

[0009] Determine the component dependency hierarchy of the target continuous integration pipeline based on the hierarchy of each dependent component.

[0010] In this application, the hierarchy of each dependent component is obtained based on the positional relationship of each dependent component in the row table file, including:

[0011] Based on the row table file, hierarchical files of different levels are obtained. The hierarchical files include dependent components that are at the same level in the row table file.

[0012] Based on the hierarchical files of different levels, the dependent components in each hierarchical file are filtered and migrated to obtain the target hierarchical files of different levels;

[0013] Based on the target hierarchy files at different levels, the hierarchy of each dependent component is obtained.

[0014] In this application, hierarchical files of different levels are obtained based on the row table file, including:

[0015] Based on the row table file, extract the leaf nodes of each dependent path in the row table file to obtain the hierarchical file and the remaining row table file;

[0016] Using the remaining row table file as the row table file, the process of extracting the leaf nodes of each dependency path in the row table file to obtain the hierarchical file and the remaining row table file is repeated until all dependency components in the row table file have been extracted, resulting in hierarchical files of different levels and the remaining row table file corresponding to each level.

[0017] In this application, based on hierarchical files of different levels, the dependent components in each hierarchical file are filtered and migrated to obtain target hierarchical files of different levels, including:

[0018] Determine the hierarchy file of the current level in order from low-level file to high-level file. The low-level file is the hierarchy file corresponding to the leaf node in the row table file, and the high-level file is the hierarchy file corresponding to the root node in the row table file.

[0019] Compare all dependent components in the current level's hierarchical file with the dependent components in each dependency path in the row table file. If at least two dependent components in the dependency path are the same as at least two dependent components in the hierarchical file, then determine the higher-level dependent components among the at least two dependent components based on the dependency path.

[0020] Migrate higher-level dependent components from the current level of the hierarchy file to the next higher level of the hierarchy file to obtain the first filtering level file;

[0021] Based on the first filtered hierarchical file of each level, the target hierarchical files of different levels are obtained.

[0022] In this application, target level files for different levels are obtained based on the first screening level file for each level, including:

[0023] Determine the first filtering level file of the current level according to the order from low-level files to high-level files;

[0024] For each first dependency component in the first filtering level file, compare the first dependency component with the dependency components of each dependency path in the row table file to determine the second dependency component in the row table file that is the same as the first dependency component.

[0025] If the second dependent component is not a leaf node in the row table file, then determine the third dependent component that the second dependent component depends on in the dependency path.

[0026] If there is no dependency component identical to the third dependency component in other first filter level files below the current first filter level file, then the second dependency component is moved to a higher-level first filter level file to obtain the second filter level file;

[0027] Based on the second filtering level file of each level, the target level files of different levels are obtained.

[0028] In this application, target level files for different levels are obtained based on the second screening level files for each level, including:

[0029] Determine the second filtering level of the current level according to the order from low-level files to high-level files;

[0030] For each fourth dependency component in the second filtering level file, if there is a dependency component identical to the fourth dependency component in the remaining row table file corresponding to the current level, then the fourth dependency component is migrated to the second filtering level file at the next higher level to obtain the third filtering level file;

[0031] Based on the third-level filtering files of each level, target level files for different levels are obtained.

[0032] In this application, the dependency paths of the component relationship dependency tree are parsed to obtain a row table file, including:

[0033] The dependency paths of the component relationship dependency tree are parsed to obtain multiple dependency paths;

[0034] For each dependency path, the dependency path is written into the same line in a preset row table file to obtain the row table file.

[0035] In this application, the method also includes:

[0036] Based on the hierarchy of each dependent component and the preset component dictionary, an ordered list of components is obtained. The component dictionary includes the component GAV information, repository information, project information, build type, and package name of the dependent components.

[0037] Secondly, this application provides a component dependency level determination apparatus, comprising:

[0038] The generation module is used to generate a component dependency tree based on the unordered component list and the source code of the components in the unordered component list. The unordered component list represents the list of components corresponding to the target continuous integration pipeline.

[0039] The parsing module is used to parse the dependency paths of the component relationship dependency tree and obtain a row table file. The row table file includes all dependency paths corresponding to the component relationship dependency tree, and all dependency paths are independent of each other.

[0040] The hierarchy module is used to obtain the hierarchy of each dependent component based on the positional relationship of each dependent component in the row table file;

[0041] The determination module is used to determine the component dependency hierarchy of the target continuous integration pipeline based on the hierarchy of each dependent component.

[0042] Thirdly, this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor;

[0043] The memory stores the instructions that the computer executes;

[0044] The processor executes computer execution instructions stored in memory to implement the method provided in this application.

[0045] 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 provided in this application.

[0046] The component dependency hierarchy determination method, apparatus, device, and medium provided in this application generate a component dependency tree based on an unordered component list and the source code of the components in the unordered component list. Then, the dependency paths of the component dependency tree are parsed to obtain a row table file. Based on the positional relationship of each dependent component in the row table file, the hierarchy of each dependent component is obtained. Finally, based on the hierarchy of each dependent component, the component dependency hierarchy of the target continuous integration pipeline is determined, thereby improving the efficiency and accuracy of component dependency hierarchy determination. Attached Figure Description

[0047] 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.

[0048] Figure 1 A schematic diagram illustrating a scenario for determining component dependency hierarchy, provided as an embodiment of this application;

[0049] Figure 2 A flowchart illustrating a method for determining component dependency hierarchy provided in an embodiment of this application;

[0050] Figure 3 This is a schematic diagram of the hierarchical splitting provided in this embodiment;

[0051] Figure 4 A flowchart illustrating another method for determining component dependency hierarchy provided in an embodiment of this application;

[0052] Figure 5 This is a schematic diagram of script configuration provided in an embodiment of this application;

[0053] Figure 6 A schematic diagram of an unordered component list file provided in an embodiment of this application;

[0054] Figure 7 A schematic diagram of the script file provided in the embodiments of this application;

[0055] Figure 8 A schematic diagram of the component dictionary provided in the embodiments of this application;

[0056] Figure 9 This is a schematic diagram of a dependency tree generation script program provided in an embodiment of this application;

[0057] Figure 10 A schematic diagram of a dependency tree provided for an embodiment of this application;

[0058] Figure 11 A flowchart illustrating the program design of the dependencyLayer.sh script provided in this application embodiment;

[0059] Figure 12 A schematic diagram of the dependencyLayer.sh script program provided in the embodiments of this application;

[0060] Figure 13 A schematic diagram of the dependencyLayer.csv row table file provided in the embodiments of this application;

[0061] Figure 14 The flowchart for parsing the row table file provided in this application;

[0062] Figure 15 This is a schematic diagram of the row table file parsing script provided in an embodiment of this application;

[0063] Figure 16 A flowchart of the first-level check design procedure provided for embodiments of this application;

[0064] Figure 17 A flowchart of the second-level check design procedure provided for embodiments of this application;

[0065] Figure 18 A flowchart of the third-level check design procedure provided for embodiments of this application;

[0066] Figure 19 A schematic diagram of an ordered component list file provided in an embodiment of this application;

[0067] Figure 20 A schematic diagram of a download center provided in an embodiment of this application;

[0068] Figure 21This is a schematic diagram of the log directory of the download center provided in an embodiment of this application;

[0069] Figure 22 This is a schematic diagram illustrating the execution result of the demo-dependency-layer pipeline provided in this application embodiment;

[0070] Figure 23 A schematic diagram showing the comparison of execution results for an ordered component list provided in an embodiment of this application;

[0071] Figure 24 A schematic diagram of a component dependency hierarchy determination device provided in an embodiment of this application;

[0072] Figure 25 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0073] 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

[0074] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0075] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0076] In large-scale enterprise applications developed based on service-oriented architecture technology, large monolithic services are broken down into dozens or hundreds of independently running services. The number of dependent components that can run independently can reach hundreds, and the dependency levels between these components can reach dozens of levels.

[0077] Applications developed using the Java programming language manage dependencies using the Maven tool. Developers can obtain the dependency tree of a single component by running the Maven command `mvn dependency:tree` in the local source code project of a single service component, thus meeting the local development needs of developers.

[0078] With the development of software engineering and cloud platform technologies, CI / CD (Continuous Integration / Continuous Deployment) technology has been maturely used in large-scale enterprise application development projects. Utilizing the CI / CD capabilities provided by cloud platforms, operations engineers configure CI continuous integration pipelines for each component source code repository on the cloud platform. These pipelines are triggered periodically, conditionally, or manually by development engineers, automating the daily compilation and building of component source code. Continuous integration pipelines are divided into two categories: single-component instance continuous integration pipelines and multi-component instance integrated continuous integration pipelines. A single-component instance continuous integration pipeline refers to operations engineers configuring a separate CI continuous integration pipeline for each component source code repository, which is then handed over to development engineers. For the aforementioned large-scale enterprise applications, this approach results in operations engineers configuring a large number of CI continuous integration pipelines, and the upstream and downstream dependencies between pipelines also need to be manually configured one by one, causing significant inconvenience to pipeline operations and maintenance, and is unsuitable for such large-scale enterprise applications. A multi-component instance unified continuous integration pipeline refers to an operations engineer configuring the source code libraries of all or multiple similar components into a single CI continuous integration pipeline. Component dependency levels are configured within the same CI continuous integration pipeline, reducing the number of pipelines and significantly reducing pipeline operations and maintenance workload. This is suitable for the aforementioned large-scale enterprise applications.

[0079] In both types of continuous integration pipelines mentioned above, the configuration of upstream and downstream dependencies and component dependencies is manually done by operations engineers by sorting out the dependency trees of multiple single components. However, this is prone to errors, such as inaccurate dependency configuration leading to compilation failures, or even successful compilation and build despite inaccurate dependency configurations. The scenario where inaccurate component dependency configurations still result in successful compilation and build is as follows:

[0080] Scenario 1: In a development project with lax management of private dependency libraries, the development engineer publishes the compiled and built upstream components to the private dependency library locally, so the downstream components compile successfully.

[0081] Scenario 2: Operations engineers repeatedly execute continuous integration pipelines with upstream and downstream relationships, either single-component instance continuous integration pipelines or multi-component instance integrated continuous integration pipelines. Each time, some upstream components are published to the private dependency library, so the downstream components compile successfully.

[0082] Continuous integration pipelines can expose the accuracy of dependency configurations. While repeatedly manually adjusting dependencies between components and re-executing the pipeline can ultimately ensure accurate dependency configurations, it leads to low overall compilation and build efficiency. This makes it unsuitable for the rapid version iterations and component dependency changes in agile development processes for large enterprise applications, impacting development efficiency. For example, after each version upgrade, the continuous integration pipeline may not execute successfully on the first attempt, requiring multiple failures before success. Furthermore, changes in component dependencies can cause pipeline failures due to developers not promptly notifying operations engineers, or operations engineers' inaccurate manual dependency analysis of multiple individual components.

[0083] In response to at least one of the aforementioned technical problems, the inventors discovered in their research that an unordered list of components can be used to generate a component dependency tree. Then, the dependency paths in the component dependency tree are parsed and converted into row table format for display, resulting in a row table file. Based on the positional relationship of each dependent component in the row table file, the level of each dependent component is determined, thereby achieving the purpose of sorting the dependent components.

[0084] The following describes the application scenarios of the component dependency hierarchy determination method provided in the embodiments of this application.

[0085] Figure 1 This application provides a schematic diagram of a scenario for determining component dependency hierarchy, as shown in the embodiments of this application. Figure 1 As shown, the scenario includes a target continuous integration pipeline and a server. The target continuous integration pipeline corresponds to multiple components. The server generates a component dependency tree based on an unordered list of components and the source code of the components in the unordered list. The unordered list of components represents the list of components corresponding to the target continuous integration pipeline. The dependency paths in the component dependency tree are parsed to obtain a row table file. The row table file includes all dependency paths corresponding to the component dependency tree, and all dependency paths are independent of each other. Based on the positional relationship of each dependent component in the row table file, the hierarchy of each dependent component is obtained. Based on the hierarchy of each dependent component, the component dependency hierarchy of the target continuous integration pipeline is determined.

[0086] Figure 2 This is a flowchart illustrating a method for determining component dependency hierarchy provided in an embodiment of this application, as shown below. Figure 2 As shown, the method includes:

[0087] S201. Based on the unordered component list and the source code of the components in the unordered component list, generate a component dependency tree. The unordered component list represents the list of components corresponding to the target continuous integration pipeline.

[0088] In this embodiment, the target continuous integration pipeline for which component dependency hierarchy determination is required is first obtained. Based on the target continuous integration pipeline, all components within that pipeline are determined, and then the component information of all components is configured in an unordered component list. Next, based on the unordered component list and the source code of all components, a component dependency tree is generated for each component.

[0089] Specifically, the component dependency tree can be generated using the dependency tree command of a dependency management tool, such as Maven. The component dependency tree can be displayed as a file, and the dependency paths in the file can be organized in a top-down tree format. For example, the component in line 2 depends on the component in line 3.

[0090] Additionally, during the generation of the component dependency tree, the Maven dependency management tool may introduce other components not included in the unordered component list. These other components can be filtered, and some can be selected to remain in the component dependency tree. For example, these other components may include self-developed components and third-party components. Self-developed components can be retained, while third-party components can be removed.

[0091] S202. Parse the dependency paths of the component relationship dependency tree to obtain a row table file. The row table file includes all dependency paths corresponding to the component relationship dependency tree, and all dependency paths are independent of each other.

[0092] In this embodiment, after obtaining the component dependency tree, the dependency paths in the component dependency tree are extracted, and all dependency paths are displayed separately in a row table file. This makes it easier for the server to distinguish different dependency paths from the row table file and to determine the location of the dependent components in each dependency path.

[0093] Specifically, the dependency paths of the component relationship dependency tree are parsed to obtain a row table file, which may include:

[0094] The dependency paths of the component relationship dependency tree are parsed to obtain multiple dependency paths;

[0095] For each dependency path, the dependency path is written into the same line in a preset row table file to obtain the row table file.

[0096] S203. Based on the positional relationship of each dependent component in the row table file, obtain the hierarchy of each dependent component.

[0097] In this embodiment, after obtaining the row table file, the positional relationship of each dependent component in each dependency path can be determined from the row table file, such as whether it is a root node, a leaf node, and its distance from leaf nodes. Based on this positional relationship, the hierarchy of each dependent component can be determined. For example, starting from the leaf nodes, the dependent component corresponding to the leaf node in each row can be determined as the first level, and the dependent component corresponding to the node preceding each leaf node can be determined as the second level. This process continues until the hierarchy of the dependent components corresponding to the root nodes of all dependency paths is determined. Here, a leaf node can refer to the last node in a dependency path, and a root node can refer to the first node in a dependency path. For example, if a dependency path includes nodes A, B, and C, where A depends on B and B depends on C, then A is the root node and C is a leaf node.

[0098] Specifically, based on the positional relationship of each dependent component in the row table file, the hierarchy of each dependent component is obtained, which may include:

[0099] Based on the row table file, hierarchical files of different levels are obtained. The hierarchical files include dependent components that are at the same level in the row table file.

[0100] Based on the hierarchical files of different levels, the dependent components in each hierarchical file are filtered and migrated to obtain the target hierarchical files of different levels;

[0101] Based on the target hierarchy files at different levels, the hierarchy of each dependent component is obtained.

[0102] In this embodiment, the dependent components are first initially divided into hierarchical levels based on the positional relationship of each dependent component in the row table file, resulting in hierarchical files of different levels. Since there may be duplicate dependent components, a certain dependent component may exist in multiple hierarchical files, or a certain dependent component may not belong to the current level, it is necessary to filter and migrate the dependent components in the hierarchical files to obtain target hierarchical files of different levels. Then, based on the level of the dependent components in the target hierarchical files of each level, the level of each dependent component is obtained, which improves the accuracy of the hierarchy of dependent components.

[0103] Specifically, based on the row table file, different levels of hierarchical files are obtained, including:

[0104] Based on the row table file, extract the leaf nodes of each dependent path in the row table file to obtain the hierarchical file and the remaining row table file;

[0105] Using the remaining row table file as the row table file, the process of extracting the leaf nodes of each dependency path in the row table file to obtain the hierarchical file and the remaining row table file is repeated until all dependency components in the row table file have been extracted, resulting in hierarchical files of different levels and the remaining row table file corresponding to each level.

[0106] In this embodiment, to facilitate the filtering and migration of dependent components at different levels, the leaf nodes of each dependent path in the row table file are extracted to obtain a hierarchy file and a remaining row table file. Then, following the same method, leaf nodes are extracted from the remaining row table file to obtain the hierarchy file of the next higher level and the remaining row table file corresponding to the next higher level, until all dependent components in the row table file have been extracted.

[0107] Specifically, in the resulting hierarchical files of different levels, each level file is deduplicated, and the dependent components in each level file are different.

[0108] For example, Figure 3 This is a schematic diagram of the hierarchical splitting provided in this embodiment, as shown below. Figure 3 As shown, the first row of the row list file is a dependency path of dependent component A. A depends on B, B depends on C, and so on, with F depending on G. A is the leftmost node of this dependency path, which can be called the root node, and G is the rightmost node of this dependency path, which can be called the leaf node. A dependent component can have multiple dependency paths; for example, the second row is also a dependency path of A. When performing hierarchical splitting, the splitting proceeds sequentially from the rightmost leaf node to the leftmost root node. In the first split, the leaf node is at level 1. After the leaf node GHIJK is split into the level 1 file, its adjacent leftmost node FLMNO becomes a leaf node and continues to participate in the second hierarchical splitting, and so on, until all dependent components are split into their corresponding level files.

[0109] Specifically, based on the hierarchical files at different levels, the dependent components in each level of files are filtered and migrated to obtain target hierarchical files at different levels, which may include:

[0110] Determine the hierarchy file of the current level in order from low-level file to high-level file. The low-level file is the hierarchy file corresponding to the leaf node in the row table file, and the high-level file is the hierarchy file corresponding to the root node in the row table file.

[0111] Compare all dependent components in the current level's hierarchical file with the dependent components in each dependency path in the row table file. If at least two dependent components in the dependency path are the same as at least two dependent components in the hierarchical file, then determine the higher-level dependent components among the at least two dependent components based on the dependency path.

[0112] Migrate higher-level dependent components from the current level of the hierarchy file to the next higher level of the hierarchy file to obtain the first filtering level file;

[0113] Based on the first filtered hierarchical file of each level, the target hierarchical files of different levels are obtained.

[0114] In this embodiment, to make the hierarchy of dependent components more accurate, when splitting the hierarchical files, since the leaf nodes in the row table file are the last nodes that are depended upon and are the foundation nodes for other nodes in the dependency path, the dependent components corresponding to the leaf nodes in the row table file are identified as low-level files. For example... Figure 3 In layer 1, the dependent components corresponding to the root node in the row table file are considered as high-level files, for example... Figure 3 The process begins with layer 8. Then, following the order from lower-level files to higher-level files, the hierarchy files of the current level are determined sequentially. Therefore, the lowest-level files are selected first. Next, all dependent components in the current-level file are compared with the dependent components of each dependency path in the row table file. If at least two dependent components in a dependency path are identical to at least two dependent components in the current-level file, it indicates that a higher-level dependent component exists in the current-level file. Therefore, to identify which component is the higher-level dependent component, it is necessary to determine the higher-level dependent component among the at least two dependent components in the dependency path. This higher-level dependent component is then moved from the current-level file to the next higher-level file, and the moved file becomes the first-selected layer file. These first-selected layer files from different levels are then used as the target layer files for those different levels.

[0115] This place is Figure 3 In the example, layer1 is used as a low-level file in the first-level file. The first dependent component GHIJK in layer1 is selected. GHIJK is compared with each dependent path in the row table file. If there are at least two dependent components in a certain dependent path, such as GH, that are the same as GH in the first dependent component GHIJK, and G is a higher-level component compared with H in this dependent path, then the higher-level component G in the dependent path is deleted from layer1. Then G is added to layer2. Then the dependent components in layer2 are deduplicated.

[0116] Specifically, based on the first-level filtered file of each level, target level files for different levels are obtained, which may include:

[0117] Determine the first filtering level file of the current level according to the order from low-level files to high-level files;

[0118] For each first dependency component in the first filtering level file, compare the first dependency component with the dependency components of each dependency path in the row table file to determine the second dependency component in the row table file that is the same as the first dependency component.

[0119] If the second dependent component is not a leaf node in the row table file, then determine the third dependent component that the second dependent component depends on in the dependency path.

[0120] If there is no dependency component identical to the third dependency component in other first filter level files below the current first filter level file, then the second dependency component is moved to a higher-level first filter level file to obtain the second filter level file;

[0121] Based on the second filtering level file of each level, the target level files of different levels are obtained.

[0122] In this embodiment, to further refine the hierarchy of dependent components, the first filtering level file for the current level is determined in ascending order from lower-level to higher-level files. For each dependent component in this first filtering level file (here referred to as the first dependent component for distinction), each first dependent component is compared with the dependent components of each dependency path in the row table file. The dependent components in the row table file that are identical to the first dependent components are identified (here referred to as the second dependent components for distinction). Based on the dependency path of the second dependent component, the dependent components that the second dependent component depends on are determined (here referred to as the third dependent component). The third dependent component is then compared with the dependent components in first filtering level files at other levels below the current first filtering level file. If no identical dependent component exists in other first filtering level files, the second dependent component is moved to a higher-level first filtering level file, resulting in a second filtering level file. Finally, these second filtering level files from different levels are used as target level files for their respective levels.

[0123] Specifically, based on the second-level filtering file of each level, target level files for different levels are obtained, which may include:

[0124] Determine the second filtering level of the current level according to the order from low-level files to high-level files;

[0125] For each fourth dependency component in the second filtering level file, if there is a dependency component identical to the fourth dependency component in the remaining row table file corresponding to the current level, then the fourth dependency component is migrated to the second filtering level file at the next higher level to obtain the third filtering level file;

[0126] Based on the third-level filtering files of each level, target level files for different levels are obtained.

[0127] In this embodiment, to further improve the accuracy of the hierarchy of dependent components, the second filtering level file of the current level is determined in order from low-level files to high-level files. Each dependent component in the second filtering level file of the current level is compared with the dependent components in the remaining row table file corresponding to the current level. For each dependent component in the second filtering level file of the current level, referred to here as the fourth dependent component, if there is a dependent component identical to the fourth dependent component in the remaining row table file corresponding to the current level, the fourth dependent component is moved to the second filtering level file of the next higher level to obtain the third filtering level file of the current level. Finally, the third filtering level file of each level is used as the target level file of different levels.

[0128] S204. Determine the component dependency hierarchy of the target continuous integration pipeline based on the hierarchy of each dependent component.

[0129] In this embodiment, compared to an unordered list of components, necessary dependent components are added during the generation of the component dependency tree, enriching the dependency relationships of components in the target continuous integration pipeline. Then, the level of each dependent component is used as the dependency level of the components in the target continuous integration pipeline.

[0130] Specifically, an ordered component list can be obtained based on the hierarchy of each dependent component and a pre-defined component dictionary. That is, the dependent components are sorted hierarchically, and the component information of the dependent components is retrieved from the component dictionary to obtain the ordered component list. This ordered component list can then be directly applied to the target continuous integration pipeline. The component dictionary includes the component's GAV information, repository information, project information, build type, and package name.

[0131] This application provides a method for determining component dependency levels. It generates a component dependency tree based on an unordered list of components and the source code of those components. Then, it parses the dependency paths in the dependency tree to obtain a row table file. Based on the positional relationships of each dependent component in the row table file, it obtains the level of each dependent component. Finally, based on the level of each dependent component, it determines the component dependency level of the target continuous integration pipeline, thus improving the efficiency and accuracy of component dependency level determination.

[0132] Figure 4 A flowchart illustrating another method for determining component dependency hierarchy provided in this application embodiment is shown below. Figure 4 As shown, the method includes:

[0133] 401. Create an automatic dependency resolution pipeline;

[0134] Specifically, an automated dependency resolution pipeline can be created on the DevOps cloud platform. The pipeline name can be defined as demo-dependency-layer, including var1_commit_depth, var2_pipeline_giturl, and var2_pipeline_branch. Here, var1_commit_depth defines the source code repository cloning depth; var2_pipeline_giturl defines the address of the pipeline process script library, which stores the unordered component list file; and var2_pipeline_branch defines the name of the component source code repository branch that participates in the automated dependency resolution.

[0135] The demo-dependency-layer pipeline includes 6 task nodes. Figure 5 The script configuration diagram provided in this application embodiment includes the task node name and the script configuration corresponding to the task node. Among them, 1-initParams is used to execute step 402, 2-cloneSrc is used to execute step 403, 3-dependencyTree is used to execute step 404, 4-dependencyLayer is used to execute step 405, 5-getBuildlistfile is used to execute step 406, and 6-downloadCenter is used to execute step 407.

[0136] 402. Obtain the unordered component list file and automatically parse the script files and component dictionaries configured in each node step of the dependency pipeline.

[0137] Specifically, 1-initParams is responsible for initializing necessary parameters and downloading necessary files, including an unordered component list file, script files configured in pipeline node steps, and a component dictionary. Figure 6 This is a schematic diagram of an unordered component list file provided in an embodiment of this application. The `build_layer` column is configured as `build_layer1`, which serves only to generate a dependency tree of each service component concurrently and does not indicate that the hierarchical relationship between service components is parallel. When writing this file, R&D and operations engineers do not need to pay attention to the hierarchical relationship between service components; they only need to write it line by line. Figure 7 This is a schematic diagram of the script files provided in the embodiments of this application, wherein dependencyTree.sh, DependencyLayer.sh, and getBuildlistfile.sh are the core contents of this embodiment. Figure 8This diagram illustrates a component dictionary provided in an embodiment of this application. The component dictionary maintains information such as component GAV information, repository information, project information, build type, and package name, used for format matching when generating an ordered component list. The component dictionary is pre-built into the pipeline; R&D and operations engineers need to promptly add new components to the component dictionary.

[0138] 403. Clone the source code library of the components in the unordered component list file to the pipeline server.

[0139] Specifically, in order to parse the unordered list of components, 2-cloneSrc is responsible for downloading the component source code library to the server or the client's local environment.

[0140] 404. Generate the dependency tree of all components based on the unordered component list file.

[0141] Specifically, 3-dependencyTree generates dependency trees for all components based on the dependencyTree.sh script, and each component's dependency tree is independent. Figure 9 This is a schematic diagram of a dependency tree generation script provided in an embodiment of this application. The dependencyTree.sh script generates the component dependency tree using the `mvn dependency:tree` command. Line 20 details the `mvn` command; line 22 writes the dependency trees of individual services (components) into the same `dependencyTree.log` file; the '&' symbol in line 26 indicates parallel generation of dependency trees; lines 32-34 format the `dependencyTree.log` file. The file format is a summary of multiple individual service (component) dependency trees. Figure 10 This is a schematic diagram of a dependency tree provided in an embodiment of this application.

[0142] 405. Parse all dependency trees into a row table file containing all component dependency paths from left to right.

[0143] Specifically, 4-dependencyLayer can automatically parse all independent top-down tree-structured dependency trees into a left-to-right dependency path row table file that includes the dependency paths of all components. The row table file can be named dependencyLayer.csv. Figure 11The detailed design flowchart of the dependencyLayer.sh script provided in this application embodiment is shown. The main content involves reading dependencyTree.log line by line, looping through each line, and verifying not only the position and hierarchy of the component in the current line but also the position and hierarchy of the component in the next line. There are two ways to write components to the dependencyLayer.csv row table file: one is to append a new line to the end of the row table file, and the other is to append to the end of the current line in the row table file. Figure 12 The diagram below illustrates the dependencyLayer.sh script provided in this embodiment. Lines 13 and 26 are the hierarchy calculation formulas, which calculate the hierarchy numbers of the components in the current and next rows of dependencyTree.log, respectively. Lines 18, 20, 30, 51, and 54 write the components to the dependencyLayer.csv file. Figure 13 This is a schematic diagram of the dependencyLayer.csv row table file provided in an embodiment of this application, wherein, Figure 13 It is by Figure 10 The dependency tree is passed through Figure 12 This is derived from a script program. Each line in the row table file is a dependency path, and the components in the dependency path are separated by English commas; each dependency path depends on the others from left to right, with the leftmost node being the root node of the dependency tree and the rightmost node being the leaf node of the dependency tree; the left node depends on the right node.

[0144] 406. Parse the row table file, traverse the row table file from both the left and right sides to resolve the dependencies, and output an ordered list of components.

[0145] Specifically, this step includes S1 initializing the hierarchical file and S2 hierarchical one-way migration. First, the row table file is split into columns to initialize the hierarchical file. Second, based on the hierarchical file, the hierarchical file and row table file are traversed to complete the hierarchical one-way migration of dependent components. Figure 14 The flowchart for parsing the row table file provided in this application includes four core sub-processes:

[0146] Subprocess 1 is used to initialize the hierarchical files.

[0147] Subprocess 2 is used to traverse the dependency paths of the parsing row table file from right to left, and to migrate the higher-level components that appear in the current level file to the next higher level file in a one-way manner.

[0148] Subprocess 3 is used to traverse the dependency paths of the parsed row table file from left to right and compare them with the lower-level files, and migrate the higher-level components that appear in the current level file to the next higher level file in a one-way manner.

[0149] Subprocess 4 is used to traverse and parse the dependency paths of the remaining row table files in the current level from left to right, and to migrate the higher-level components that appear in the current level file to the next higher level file in a one-way manner.

[0150] S1 initialization of the hierarchy files refers to splitting the dependencyLayer.csv row table file into different layer${n} hierarchy files by column. The column splitting direction for each row is from right to left. Please refer to [link / reference]. Figure 3 'n' represents the build level of the dependent component. 'n' is a positive integer greater than or equal to 1. The smaller 'n' is, the fewer components the component depends on, and the earlier the build occurs. The larger 'n' is, the more components the component depends on, and the later the build occurs. 'layer${n-1}' represents the lower-level file, 'layer${n}' represents the current-level file, and 'layer${n+1}' represents the higher-level file. 'layer${n}_left' represents the remaining row table file for the current level. It refers to the remaining row table data in the 'dependencyLayer.csv' row table file after 'layer${n}' and other level files smaller than 'n' have been separated from the 'dependencyLayer.csv' row table file. Figure 15 The diagram below illustrates the row table file parsing script provided in this application embodiment. Line 64 retrieves the column number of the rightmost leaf node in the dependency path, line 67 retrieves the rightmost leaf node component based on the column number, line 68 writes the leaf node component to the hierarchy file, and line 69 writes the other components, excluding the leaf node component, to the remaining row table file of the current hierarchy.

[0151] Because the dependencies between service components are quite complex, the initialization of the hierarchical file cannot meet the requirements for hierarchical compilation and building. Therefore, it is necessary to check whether the current hierarchical file contains high-level components. If it does, the high-level components in the current hierarchical file need to be migrated unidirectionally to the next higher-level file.

[0152] S2 hierarchical one-way migration refers to migrating dependent components that do not belong to the current level from the current level file to a higher-level file. Based on the current level file, it iterates through the current level file and the row table file, checking whether the dependent component belongs to the current level, thus completing the hierarchical one-way migration of the dependent component. Each level file completes the hierarchical check, hierarchical one-way migration, and component dictionary matching of dependent components in order from lower to higher levels.

[0153] S2-level unidirectional migration includes the following four steps:

[0154] Step 1: The first hierarchical check and unidirectional migration refers to traversing and parsing each component in the dependency path of the row table file from right to left, and comparing them one by one with the components in the current level file. This traversal and parsing involves comparing the current level file and the row table file. The technical implementation is as follows:

[0155] Compare each component in the current layer $n file with each component in the dependencyLayer.csv file, starting from the rightmost column and working backwards. If two or more components are found to be identical, it indicates that a higher-level component has appeared in the current layer file. This higher-level component should be moved to a higher-level file. In this case, retain the rightmost identical component in the dependency path, remove the other identical components from the current layer $n file, and append them to the higher-level layer $n+1 file. Then, sort the layer $n and layer $n+1 files to remove duplicates. Figure 16 The flowchart of the first level check design procedure provided in this application embodiment is shown, where d = d-1 controls the traversal direction of the row table file dependency path to be from right to left. The variable noo refers to the number of times the component in a single dependency path appears in the current level file. When noo is greater than or equal to 2, the same component name layern_item that appears at this time is unidirectionally migrated to the next higher level file.

[0156] The second step, the second level-based check and unidirectional level migration, involves traversing and parsing each component in the dependency path of the row table file from left to right, and comparing them one by one with the components in the current level file. This traversal and parsing involves comparing the current level file, all lower-level files, and the row table file. The technical implementation is as follows:

[0157] Compare each component in the current layer $n file with each component in the dependencyLayer.csv file, starting from the leftmost column and moving to the rightmost column. If a matching component is found, and its right-hand dependency is not empty and not present in any lower-level files, it indicates a higher-level component has appeared in the current layer. This higher-level component should be moved to a higher-level file. In this case, remove the matching component from the current layer $n file and append it to the higher-level layer $n+1 file. Then, sort and deduplicate the layer $n and layer $n+1 files. Figure 17The flowchart of the second-level check design procedure provided in this application embodiment is shown. Here, d = d + 1 controls the traversal direction of the row table file dependency path to be from left to right. ${dlf_item} = ${layern_item} and ${d} < ${dlf_item_column_cn} indicates that the component in the dependency path is the same as the component in the layer file, and the dependency path has not yet traversed to the leaf node; d_right = d + 1 is the column number of the component to the right of the component name dlf_item in the dependency path; dlf_item_right is the right-hand component. n > ${initValue} controls whether to check lower-level files. initValue is a positive integer greater than or equal to 1, defining the initial layer number, which can be configured according to the actual situation of the development project. When the right-hand component of the same component is not in the lower-level file, the same component name layern_item is unidirectionally migrated to the higher-level file.

[0158] Step 3: The third level check and one-way level migration refers to traversing and parsing each component in the dependency path of the remaining row table file of the current level from left to right, and comparing it one by one with the components in the current level file. This traversal and parsing involves comparing the current level file and the remaining row table file of the current level file. The technical implementation is as follows:

[0159] All components in the current layer $n$ file are compared one by one with each component in the dependency path of the remaining rows table file of the current layer $n$_left. The comparison order is from the leftmost column to the rightmost column of the dependency path. If the comparison results show that there is a component with the same name, it means that there is a high-level component in the current layer. The high-level component should be moved to the high-level file. So the same component is removed from the current layer $n$ file and appended to the high-level file layer $n+1. The layer $n$ and layer $n+1 files are sorted and deduplicated. Figure 18 The flowchart of the third-level check design procedure provided in this application embodiment shows that a = a + 1 controls the traversal direction of the dependency path of the remaining row table file in the current level to be from left to right. ${layern_item} = ${layern_left_item} indicates that the component in the current level is the same as the component in the dependency path of the remaining row table file in the current level, and the component name layern_item is unidirectionally migrated to the higher-level file.

[0160] Step 4: Matching the component dictionary. This involves matching the final results of the filtered layer${n} level files with the component dictionary to obtain information such as the component's repository, project, build type, and package name. This information is then output to the Buildlistfile, an ordered component list file, according to a preset format, for pipeline use. If a newly added component is not added to the component dictionary in time, it will be output as NULL in the Buildlistfile. Figure 19 This is a schematic diagram of an ordered component list file provided in an embodiment of this application, wherein, Figure 19 yes Figure 6 The unordered component list Buildlistfile is generated by the automatic dependency parsing program. Compared with the unordered component list file, it not only determines the compilation and build level of the components, but also adds many necessary dependent components, thus improving the compilation success rate.

[0161] In some implementations, this embodiment can also upload the files output by the upstream node task to the download center.

[0162] Specifically, 6-downloadCenter is responsible for uploading the files output by upstream node tasks to the download center for viewing and use by R&D and operations personnel. R&D and operations engineers can download the dependency layer file dependencyLayer.csv, the ordered component list file Buildlistfile, and the dependency tree file dependencyTree.log from the download center. Figure 20 This is a schematic diagram of a download center provided in an embodiment of this application. Figure 21 This is a schematic diagram of the log directory of the download center provided in an embodiment of this application.

[0163] Figure 22 This is a schematic diagram of the execution result of the demo-dependency-layer pipeline provided in the embodiment of this application. The time taken for the task node 5:5-getBuildlistfile depends on the service's dependency path and the dependency level of the dependency path. The more dependency paths and the higher the dependency level, the longer the time taken.

[0164] Figure 23 This diagram illustrates the comparison of execution results for the ordered component list provided in this embodiment. Executions #1 to #6 are compilation builds after pulling a new branch. In these builds, the pipeline does not use the ordered component list provided in this embodiment, and the continuous integration pipeline experiences five failures before finally succeeding on the sixth attempt, resulting in a time loss of over one hour. Execution #7 is a compilation build after pulling a new branch. In this build, the pipeline uses the ordered component list provided in this embodiment, and the continuous integration pipeline succeeds on the first execution.

[0165] Another component dependency hierarchy determination method provided in this application embodiment improves the efficiency and effectiveness of determining the component dependency hierarchy in the unordered component list file by creating an automatic dependency resolution pipeline, obtaining an unordered component list file, script files configured in each node step of the automatic dependency resolution pipeline, and a component dictionary, cloning the source code library of the components in the unordered component list file to the pipeline server, generating a dependency tree of all components based on the unordered component list file, parsing all dependency trees into a row table file containing all component dependency paths from left to right, and finally parsing the row table file, traversing the dependency relationships from both the left and right sides of the row table file to output an ordered component list.

[0166] Figure 24 This application provides a schematic diagram of a component dependency hierarchy determination device 240, which includes:

[0167] The generation module 2401 is used to generate a component dependency tree based on the unordered component list and the source code of the components in the unordered component list. The unordered component list represents the list of components corresponding to the target continuous integration pipeline.

[0168] The parsing module 2402 is used to parse the dependency paths of the component relationship dependency tree to obtain a row table file. The row table file includes all dependency paths corresponding to the component relationship dependency tree, and all dependency paths are independent of each other.

[0169] The hierarchy module 2403 is used to obtain the hierarchy of each dependent component based on the positional relationship of each dependent component in the row table file;

[0170] Module 2404 is used to determine the component dependency hierarchy of the target continuous integration pipeline based on the hierarchy of each dependent component.

[0171] In some implementations, the parsing module 2402 is further used for:

[0172] The dependency paths of the component relationship dependency tree are parsed to obtain multiple dependency paths;

[0173] For each dependency path, the dependency path is written into the same line in a preset row table file to obtain the row table file.

[0174] In some embodiments, the hierarchical module 2403 is further used for:

[0175] Based on the row table file, hierarchical files of different levels are obtained. The hierarchical files include dependent components that are at the same level in the row table file.

[0176] Based on the hierarchical files of different levels, the dependent components in each hierarchical file are filtered and migrated to obtain the target hierarchical files of different levels;

[0177] Based on the target hierarchy files at different levels, the hierarchy of each dependent component is obtained.

[0178] In some embodiments, the hierarchical module 2403 is further used for:

[0179] Based on the row table file, extract the leaf nodes of each dependent path in the row table file to obtain the hierarchical file and the remaining row table file;

[0180] Using the remaining row table file as the row table file, the process of extracting the leaf nodes of each dependency path in the row table file to obtain the hierarchical file and the remaining row table file is repeated until all dependency components in the row table file have been extracted, resulting in hierarchical files of different levels and the remaining row table file corresponding to each level.

[0181] In some embodiments, the hierarchical module 2403 is further used for:

[0182] Determine the hierarchy file of the current level in order from low-level file to high-level file. The low-level file is the hierarchy file corresponding to the leaf node in the row table file, and the high-level file is the hierarchy file corresponding to the root node in the row table file.

[0183] Compare all dependent components in the current level's hierarchical file with the dependent components in each dependency path in the row table file. If at least two dependent components in the dependency path are the same as at least two dependent components in the hierarchical file, then determine the higher-level dependent components among the at least two dependent components based on the dependency path.

[0184] Migrate higher-level dependent components from the current level of the hierarchy file to the next higher level of the hierarchy file to obtain the first filtering level file;

[0185] Based on the first filtered hierarchical file of each level, the target hierarchical files of different levels are obtained.

[0186] In some embodiments, the hierarchical module 2403 is further used for:

[0187] Determine the first filtering level file of the current level according to the order from low-level files to high-level files;

[0188] For each first dependency component in the first filtering level file, compare the first dependency component with the dependency components of each dependency path in the row table file to determine the second dependency component in the row table file that is the same as the first dependency component.

[0189] If the second dependent component is not a leaf node in the row table file, then determine the third dependent component that the second dependent component depends on in the dependency path.

[0190] If there is no dependency component identical to the third dependency component in other first filter level files below the current first filter level file, then the second dependency component is moved to a higher-level first filter level file to obtain the second filter level file;

[0191] Based on the second filtering level file of each level, the target level files of different levels are obtained.

[0192] In some embodiments, the hierarchical module 2403 is further used for:

[0193] Determine the second filtering level of the current level according to the order from low-level files to high-level files;

[0194] For each fourth dependency component in the second filtering level file, if there is a dependency component identical to the fourth dependency component in the remaining row table file corresponding to the current level, then the fourth dependency component is migrated to the second filtering level file at the next higher level to obtain the third filtering level file;

[0195] Based on the third-level filtering files of each level, target level files for different levels are obtained.

[0196] Figure 25 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 25 As shown, the electronic device 250 includes:

[0197] The electronic device 250 may include a processor 2501 with one or more processing cores, a memory 2502 with one or more computer-readable storage media, a communication component 2503, and other components. The processor 2501, memory 2502, and communication component 2503 are connected via a bus 2504.

[0198] In the specific implementation process, at least one processor 2501 executes computer execution instructions stored in memory 2502, causing at least one processor 2501 to execute the component dependency hierarchy determination method as described above.

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

[0200] In the above Figure 5In the illustrated 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.

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

[0202] 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.

[0203] In some embodiments, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps in any of the component dependency hierarchy determination methods described above.

[0204] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0205] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0206] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the component dependency level determination methods provided in embodiments of this application.

[0207] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0208] According to one aspect of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium.

[0209] Since the instructions stored in the storage medium can execute the steps in any of the component dependency level determination methods provided in the embodiments of this application, the beneficial effects that any of the component dependency level determination methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

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

[0211] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for determining component dependency hierarchy, characterized in that, include: Based on the unordered component list and the source code of the components in the unordered component list, a component relationship dependency tree is generated, wherein the unordered component list represents the list of components corresponding to the target continuous integration pipeline. The dependency paths of the component relationship dependency tree are parsed to obtain a row table file, which includes all dependency paths corresponding to the component relationship dependency tree, and all dependency paths are independent of each other; Based on the positional relationship of each dependent component in the row table file, the hierarchy of each dependent component is obtained; The component dependency hierarchy of the target continuous integration pipeline is determined based on the hierarchy of each dependent component. The step of obtaining the hierarchy of each dependent component based on the positional relationship of each dependent component in the row table file includes: Based on the row table file, hierarchical files of different levels are obtained, and the hierarchical files include dependent components that are at the same level in the row table file; The hierarchy files of the current level are determined according to the order from low-level files to high-level files. The low-level files are the hierarchy files corresponding to the leaf nodes in the row table file, and the high-level files are the hierarchy files corresponding to the root nodes in the row table file. Compare all dependent components in the current level's hierarchical file with the dependent components in each dependency path of the row table file. If at least two dependent components in the dependency path are the same as at least two dependent components in the hierarchical file, then determine the higher-level dependent component among the at least two dependent components based on the dependency path. The higher-level dependent components are migrated from the current level's hierarchical file to the next higher level's hierarchical file to obtain the first filtering hierarchical file; Based on the first filtered hierarchical file of each level, the target hierarchical files of different levels are obtained; Based on the target hierarchy files at different levels, the hierarchy of each dependent component is obtained.

2. The method according to claim 1, characterized in that, The step of obtaining hierarchical files of different levels based on the row table file includes: Based on the row table file, extract the leaf nodes of each dependent path in the row table file to obtain the hierarchical file and the remaining row table file; Using the remaining row table file as the row table file, the steps of extracting the leaf nodes of each dependency path in the row table file to obtain the hierarchical file and the remaining row table file are repeated until all dependency components in the row table file have been extracted, resulting in hierarchical files of different levels and the remaining row table file corresponding to each level.

3. The method according to claim 1, characterized in that, The process of obtaining target level files for different levels based on the first filtered level files of each level includes: Determine the first filtering level file of the current level according to the order from low-level files to high-level files; For each first dependency component in the first filtering hierarchy file, the first dependency component is compared with the dependency components of each dependency path in the row table file to determine the second dependency component in the row table file that is the same as the first dependency component. If the second dependent component is not a leaf node in the row table file, then determine the third dependent component that the second dependent component depends on in the dependency path; If there is no dependency component identical to the third dependency component in other first filter level files below the current first filter level file, then the second dependency component is migrated to a higher-level first filter level file to obtain a second filter level file; Based on the second filtering level file of each level, the target level files of different levels are obtained.

4. The method according to claim 3, characterized in that, The process of obtaining target level files for different levels based on the second filtering level files of each level includes: Determine the second filtering level of the current level according to the order from low-level files to high-level files; For each fourth dependency component in the second filtering level file, if there is a dependency component identical to the fourth dependency component in the remaining row table file corresponding to the current level, then the fourth dependency component is migrated to the second filtering level file at a higher level to obtain the third filtering level file; Based on the third-level filtering files of each level, target level files for different levels are obtained.

5. The method according to any one of claims 1-4, characterized in that, The process of parsing the dependency paths of the component relationship dependency tree to obtain a row table file includes: The dependency paths of the component relationship dependency tree are parsed to obtain multiple dependency paths; For each dependency path, the dependency path is written into the same line in a preset row table file to obtain the row table file.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: Based on the hierarchy of each dependent component and a preset component dictionary, an ordered list of components is obtained. The component dictionary includes the component GAV information, repository information, project information, build type, and package name of the dependent components.

7. A component dependency hierarchy determination device, characterized in that, include: The generation module is used to generate a component dependency tree based on an unordered component list and the source code of the components in the unordered component list. The unordered component list represents a list of components corresponding to the target continuous integration pipeline. The parsing module is used to parse the dependency paths of the component relationship dependency tree to obtain a row table file. The row table file includes all dependency paths corresponding to the component relationship dependency tree, and all dependency paths are independent of each other. The hierarchy module is used to obtain the hierarchy of each dependent component based on the positional relationship of each dependent component in the row table file; The determination module is used to determine the component dependency hierarchy of the target continuous integration pipeline based on the hierarchy of each dependent component. The hierarchical module is specifically used for: Based on the row table file, hierarchical files of different levels are obtained, and the hierarchical files include dependent components that are at the same level in the row table file; The hierarchy files of the current level are determined according to the order from low-level files to high-level files. The low-level files are the hierarchy files corresponding to the leaf nodes in the row table file, and the high-level files are the hierarchy files corresponding to the root nodes in the row table file. Compare all dependent components in the current level's hierarchical file with the dependent components in each dependency path of the row table file. If at least two dependent components in the dependency path are the same as at least two dependent components in the hierarchical file, then determine the higher-level dependent component among the at least two dependent components based on the dependency path. The higher-level dependent components are migrated from the current level's hierarchical file to the next higher level's hierarchical file to obtain the first filtering hierarchical file; Based on the first filtered hierarchical file of each level, the target hierarchical files of different levels are obtained; Based on the target hierarchy files at different levels, the hierarchy of each dependent component is obtained.

8. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-6.

9. 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-6.

Images