Software item fault locating method, system and electronic device

Abstract

The present disclosure relates to a method and system for locating a fault of a software project and an electronic device. The method comprises: receiving a fault report for a software project, the fault report containing two version identifiers of a first code repository relied on by the software project, the two version identifiers respectively indicating two commit versions relied on when the software project executes successfully and fails; locating a fourth commit version introducing a fault problem in a version interval formed by the two commit versions through dependency testing on candidate commit versions in the version interval; the dependency testing comprises: testing a test object using a test suite to obtain a test result reflecting whether the test object executes successfully, the test object being generated based on a pre-constructed candidate build product of the software project and the corresponding candidate commit version, the pre-construction being triggered by a build event independent of the dependency testing to improve the locating efficiency; and outputting a fault diagnosis report for the software project based on the fourth commit version.

Description

Technical Field

[0001] This disclosure relates to the field of software engineering technology, and more specifically, to a method, system, electronic device, and non-transitory computer-readable storage medium for fault location in software projects. Background Technology

[0002] With the continuous evolution of software development models, Continuous Integration (CI) and Continuous Delivery (CD) have become core practices in modern software engineering. In a typical CI / CD workflow, there are often complex dependencies between multiple code repositories, and changes to upstream code repositories can affect the building, testing, and even operation of downstream software projects.

[0003] When downstream software malfunctions, the current approach primarily relies on manual troubleshooting to locate the problem. This method is not only inefficient, but its accuracy also heavily depends on the engineer's experience and familiarity with the codebase, making it difficult to quickly and reliably trace the root cause of the problem. Therefore, how to quickly and accurately locate the upstream code version causing the malfunction has become a key issue in ensuring software quality and improving development efficiency. Summary of the Invention

[0004] One objective of this disclosure is to provide a scheme for locating the upstream code version that causes downstream software code failures.

[0005] According to a first aspect of this disclosure, a fault location method for a software project includes: Receive a fault report for a software project; wherein the software project depends on an upstream first code repository, and the fault report contains two version identifiers of the first code repository, wherein the first version identifier indicates the first commit version of the first code repository that the software project depends on when it executes successfully, and the second version identifier indicates the second commit version of the first code repository that the software project depends on when it fails to execute. Based on the fault report, the version range formed from the first submission version to the second submission version is determined; By performing dependency testing on candidate commit versions within the version range, adjacent third and fourth commit versions are located within the version range. The dependency testing includes: testing a test object using a test suite to obtain test results reflecting whether the test object executes successfully. The test object is generated based on the software project and pre-built candidate build artifacts corresponding to the candidate commit versions. The pre-built artifacts are triggered by build events independent of the dependency testing. The third commit version is a candidate commit version that enables the generated test object to execute successfully, and the fourth commit version is a candidate commit version that causes the generated test object to fail to execute. Based on the fourth submission, a fault diagnosis report for the software project is output.

[0006] Optionally, the build event is the commit event of the corresponding candidate commit version of the first code repository; the method further includes: Listen for commit events in the first code repository; Based on the monitored current commit event, a pre-build operation is triggered for the current commit version corresponding to the current commit event to obtain the build artifact corresponding to the current commit version; The build artifacts corresponding to the current commit version are stored in a versioned storage system.

[0007] Optionally, the test object is generated based on the software project and the pre-built candidate build artifacts corresponding to the candidate submission version, including: Deploy the software project to a clean test environment; In the test environment, the software project's dependency on the first code repository is updated to the candidate build artifact, and the test object is generated.

[0008] Optionally, updating the software project's dependency on the first code repository to the candidate build artifact includes: By passing the index identifier of the candidate build artifact to the test environment, the software project's dependency on the first code repository is updated to the candidate build artifact; wherein, the index identifier includes the repository name of the first code repository and the commit hash value of the candidate commit version.

[0009] Optionally, the step of performing dependency testing on candidate commit versions within the version range to locate adjacent third and fourth commit versions within the version range includes: Select candidate commit versions within the specified version range for the dependency testing. The version range is updated based on the test results corresponding to the candidate submission versions; Based on the updated version range, the step of selecting candidate commit versions within the version range for dependency testing is performed again until the adjacent third and fourth commit versions are located.

[0010] Optionally, selecting candidate commit versions within the version range for dependency testing includes: Based on the changes made in the submitted versions within the specified version range, submission versions whose changes meet the set filtering criteria are selected as candidate submission versions.

[0011] Optionally, the fault diagnosis report includes at least some of the following information items: the commit hash value of the fourth commit, the code change link corresponding to the fourth commit, the index identifier of the build artifact associated with the fourth commit, the update content of the fourth commit, and the impact scope information of the update content.

[0012] Optionally, the software project depends on multiple upstream code repositories, including the first code repository; the fault report also includes two version identifiers for each of the other code repositories in the multiple code repositories; The test object is generated based on the software project, the pre-built candidate build artifact corresponding to the candidate commit version, and the build artifact pre-built based on the first commit version of other code repositories.

[0013] According to a second aspect of this disclosure, a fault location system for a software project is also provided, comprising: The build artifact management module is used to listen for build events for the first code repository, and trigger pre-build operations for the associated commit versions based on the listened build events, generating and storing the corresponding build artifacts; The location scheduling module is used to receive fault reports for software projects, determine the version range formed by the first commit version to the second commit version of the first code repository based on the fault reports, and output the candidate commit versions located in the version range to the testing module for dependency testing, until the adjacent third commit version and fourth commit version are located in the version range. The testing module is configured to receive candidate submission versions provided by the positioning and scheduling module and perform the dependency testing; wherein, the dependency testing includes: testing the test object using a test suite to obtain test results reflecting whether the test object executes successfully, the test object being generated based on the software project and pre-built candidate build artifacts corresponding to the candidate submission version, the pre-built artifacts being independent of the dependency testing; the third submission version is a candidate submission version that enables the generated test object to execute successfully, and the fourth submission version is a candidate submission version that causes the generated test object to fail to execute; and... The report generation module is used to output a fault diagnosis report for the software project based on the fourth submission version provided by the positioning and scheduling module.

[0014] According to a third aspect of this disclosure, an electronic device is also provided, which deploys the fault location system according to a second aspect of this disclosure; or, the electronic device includes: At least one processor; and A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to the first aspect of this disclosure.

[0015] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is also provided, the non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method according to a first aspect of this disclosure.

[0016] This disclosure embodiment utilizes a pre-built caching mechanism to generate and save versioned build artifacts for each commit of the upstream code repository. This allows for the direct reuse of pre-built artifacts for testing during fault localization, eliminating the need to repeatedly execute build operations during the localization phase. This significantly saves build time and effectively improves fault localization efficiency. Furthermore, the method provided by this disclosure embodiment can be fully automated by the fault localization system without human intervention. This not only ensures the consistency and repeatability of the execution process but also greatly reduces reliance on developer experience, enabling stable, accurate, and reliable fault localization.

[0017] The features and advantages of the embodiments of this specification will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of this specification and, together with their description, serve to explain the principles of these embodiments.

[0019] Figure 1 This is a schematic diagram of an application scenario that can be used to implement the fault location method of the embodiments of this disclosure; Figure 2 This is a flowchart illustrating a fault location method according to some embodiments; Figure 3 This is a flowchart illustrating the process of selecting candidate submission versions according to some embodiments; Figure 4 This is a flowchart illustrating a fault location method according to some other embodiments; Figure 5 This is a schematic diagram of the composition structure of a fault location system according to some embodiments. Detailed Implementation

[0020] Various exemplary embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0021] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the embodiments of this specification or their application or use.

[0022] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0023] It should be noted that all data acquisition actions in this disclosure were carried out in compliance with the relevant data protection laws and policies of the country where the data is located, and with the authorization of the relevant equipment owner.

[0024] This disclosure relates to a technical solution for tracing and locating the specific upstream commit version that caused the failure when a downstream software project experiences a failure due to changes in the upstream code repository.

[0025] In related technologies, when such failures occur in downstream software projects, developers typically rely on experience to select potentially problematic candidate versions from the historical build artifacts released and archived in the upstream code repository. They manually execute test suites and determine whether the version is the root cause of the problem based on the test results. If all released versions are not the root cause or cannot be determined, it is necessary to further search for unreleased intermediate commit versions in the upstream code repository, perform a complete compilation on them to generate build artifacts, and then conduct tests based on these build artifacts until the commit version causing the failure is located. Here, "build" as described in this disclosure refers to the process of generating a distributable, installable, and executable software package based on source code through a series of processing steps such as compilation, linking, packaging, and dependency handling. The software package as the build artifact is, for example, a whl package or a jar package.

[0026] This fault localization solution requires a complete compilation and build of the upstream intermediate commit version. This compilation process is time-consuming, often taking tens of minutes or even hours in large projects. Furthermore, in scenarios involving multiple upstream repositories or complex dependency chains, the complexity of troubleshooting increases dramatically with the number of dependencies, making it difficult to trace the problem within a reasonable timeframe, resulting in low overall localization efficiency. Simultaneously, key steps such as version selection, environment setup, test execution, and result judgment all rely on manual processing, failing to form an automated closed-loop process. This not only increases labor costs but also makes the process prone to inconsistencies or omissions of critical steps due to human error. Moreover, the localization process lacks a systematic analysis method, and its accuracy highly depends on the developers' experience and familiarity with the codebase, making it difficult to guarantee stable and reliable localization results.

[0027] Therefore, this disclosure proposes an automated fault location scheme for downstream software projects. This scheme is implemented by pre-building and storing the corresponding build artifacts for each commit to the upstream code repository. From the perspectives of automated execution and eliminating the need for compilation build artifacts during the testing phase, it significantly improves the efficiency and accuracy of fault location.

[0028] Figure 1 A schematic diagram illustrating an application scenario that can be used to implement the methods of embodiments of this disclosure is shown. For example... Figure 1 As shown, the application scenarios of this disclosure include a fault location system 1000, an upstream code repository storage system 2000, a versioned storage system 3000, and a downstream system 5000. These systems can be deployed on different physical devices, or some or all of the systems can be deployed on the same physical device; this disclosure does not limit this.

[0029] The upstream code repository storage system 2000 is used to store upstream code repositories and can be deployed on a single server or a server cluster.

[0030] This versioned storage system 3000 is used to store the build artifacts generated by pre-building each commit version in the upstream code repository, and it can be deployed on a single server or a server cluster.

[0031] The fault location system 1000 can be deployed on any type of electronic device 100 with processing capabilities. The electronic device 100 can be a server, a terminal device such as a computer, or a local server or a cloud server. The electronic device 100 includes at least... Figure 1 The processor 110 and memory 120 may further include interface device 130, communication device 140, etc., and may also have other hardware structures. This disclosure does not limit them.

[0032] The processor 110 of the electronic device 100 is used to execute computer programs, which can be written using instruction sets of architectures such as x86, Arm, RISC, and MIPS. The memory 120 includes, for example, ROM (Read-Only Memory), RAM (Random Access Memory), and non-volatile memory such as a hard disk. The interface device 130 includes, for example, a network interface and a bus interface. The communication device 140 is capable of wired or wireless communication. The communication device 140 may include a remote communication module, such as any module for WLAN, GPRS, 2G / 3G / 4G / 5G remote communication. The communication device 140 may also include at least one short-range communication module, such as any module for short-range wireless communication based on short-range wireless communication protocols such as Hilink, WiFi (IEEE 802.11), Mesh, Bluetooth, ZigBee, Thread, Z-Wave, NFC, UWB, and LiFi.

[0033] The memory 120 of the electronic device 100 is used to store a computer program for controlling the processor 110 to operate in order to perform a fault location method according to an embodiment of the present disclosure.

[0034] The following is combined Figure 1 The illustrated application environment illustrates various embodiments of this disclosure.

[0035] <First Embodiment> Figure 2 A flowchart illustrating a fault location method for a software project according to some embodiments is shown. The method consists of... Figure 1 The fault location system 1000 is implemented, or rather, it is implemented by... Figure 1 The electronic device 100 is implemented therein. For example... Figure 2 As shown, the method of this embodiment may include the following steps S210 to S240.

[0036] Step S210: Receive a fault report for the software project.

[0037] In this embodiment, the software project is a downstream software project, and its source code is stored in the second code repository. The software project depends on the upstream first code repository. The software project can be a build project that builds a software package (such as a whl package or jar package) based on the second code repository, or it can be a test instance or application instance generated by the second code repository. Its execution environment includes, but is not limited to, a chip, controller, virtual machine, or container.

[0038] In this embodiment, the first code repository can be a distributed code repository, capable of maintaining various versions of code based on developers' update operations. In the first code repository, each change commit by a developer generates a corresponding commit version (i.e., a complete snapshot of this commit in the first code repository) and its associated information, which are then saved.

[0039] Submission information may include metadata such as commit hash, author, timestamp, and commit message, as well as derived information such as modified files and changed code (diff).

[0040] In this embodiment, when a software project experiences build failure, test failure, or application failure during the continuous integration process, the downstream system 5000 generates a fault report for the software project. This fault report contains two key version identifiers: a first version identifier of the first code repository and a second version identifier of the first code repository. The first version identifier indicates the first commit version of the first code repository that the software project depends on when it executes successfully. This first commit version is, for example, the commit version of the first code repository that caused the software project to execute successfully the most recent time (last_good_commit). The second version identifier indicates the second commit version of the first code repository that the software project depends on when it fails to execute. This second commit version is, for example, the commit version of the first code repository that caused the software project to fail for the first time (first_bad_commit).

[0041] The first version identifier can be the commit count or commit hash of the first commit version, or it can be a unique index identifier for the build artifact generated based on the first commit version. This index identifier is used to find the associated build artifact. The index identifier can include the repository name of the first code repository and the commit hash value of the first commit version. For example, the repository name of the first code repository can be represented as upstream_lib1, and the commit hash value of the first commit version can consist of 40 or 7 hexadecimal characters, such as f9d5e8a. Similarly, the second version identifier can be the commit count or commit hash value of the second commit version, or it can be an index identifier for the build artifact generated based on the second commit version, etc. For example, a software project builds successfully when it depends on upstream_lib1_commit_50 (the 50th commit of the first upstream code repository lib1), but fails to build when it depends on upstream_lib1_commit_100 (the 100th commit of the first upstream code repository lib1). The first version identifier can be, but is not limited to, upstream_lib1_f9d5e8a, and the second version identifier can be, but is not limited to, upstream_lib1_f1c3d9b.

[0042] Here, because the software project needs to resolve its dependencies on the first code repository during the build process, it can obtain the specific commit version of the first code repository it depends on. When the execution is successful or fails, the system can record the corresponding first version identifier and second version identifier respectively, and generate a fault report accordingly.

[0043] Step S220: Based on the fault report, determine the version range formed from the first submission version to the second submission version.

[0044] In this embodiment, the fault location system 1000 can determine the location of the version range as [first commit version, second commit version] based on the first version identifier and the second version identifier in the fault report. The version range is represented, for example, as [lib1_commit_50, lib1_commit_100].

[0045] Step S230: By performing dependency testing on candidate commit versions within the version range, the adjacent third and fourth commit versions are located within the determined version range.

[0046] In this embodiment, the candidate commit version can be any commit version of the first code repository within that version range.

[0047] In this embodiment, dependency testing includes: testing the test object using a test suite to obtain test results reflecting whether the test object has been successfully executed. The test object is generated based on the software project and the pre-built candidate build artifacts corresponding to the candidate submission version. In other words, a dependency relationship is established between the software project and the specified candidate build artifacts to form a test object used to test whether the candidate build artifacts will cause the software project to fail.

[0048] The aforementioned pre-build is based on a build event triggered independently of dependency tests. This can be understood as the pre-build process / operation being decoupled from the dependency test process / operation, and it can be completed before dependency tests.

[0049] For example, the build event could be the commit event of the corresponding candidate commit version in the first code repository. That is, the pre-build can be triggered based on the commit event of the corresponding candidate commit version in the first code repository. When a developer saves the candidate commit version by committing changes, the pre-build operation based on the candidate commit version is triggered, and the corresponding candidate build artifacts can be saved in the versioned storage system 3000 for direct use during dependency testing.

[0050] For example, the build event can also be a scheduled start event based on a preset build cycle. The fault location system 1000 can be configured to periodically pull commit versions generated in the first code repository between the current build start event and the previous build start event, according to the preset build cycle. If a commit version that meets the pull criteria is pulled, a pre-build operation is performed on each pulled commit version, and the generated build artifacts are saved in the versioned storage system 3000 for direct use during dependency testing. This build cycle can be set according to the activity level of the first code repository. If the first code repository is frequently updated, a shorter build cycle can be set; conversely, a longer build cycle can be set.

[0051] In this embodiment, the third commit is a candidate commit that enables the generated test object to execute successfully, and the fourth commit is a candidate commit that causes the generated test object to fail. Here, since the fourth commit is the first commit that causes the software project to fail, it is the commit that introduces the software project failure problem.

[0052] In this embodiment, the fault location system 1000 can locate the third and fourth commit versions by performing dependency tests on multiple candidate commit versions within the version range.

[0053] In some examples, the fault location system 1000 may employ a sequential traversal strategy, starting with the version following the first commit and sequentially selecting one commit as a candidate for dependency testing until the third and fourth commits are located. For instance, within the version range [lib1_commit_50, lib1_commit_100], the fault location system 1000 first selects lib1_commit_51 as a candidate commit, with the corresponding candidate build artifact being lib1_commit_51.whl. Alternatively, the fault location system 1000 may start with the commit preceding the second commit and sequentially select one commit as a candidate for dependency testing until the third and fourth commits are located.

[0054] In other examples, the fault location system 1000 can also use binary search to select candidate commit versions, thereby improving the efficiency of locating the third and fourth commit versions.

[0055] In these examples, such as Figure 3 As shown, step S230, by performing dependency testing on candidate commit versions within the version range, locates the adjacent third and fourth commit versions within the determined version range, and can further include the following steps S231 to S233: Step S231: Select candidate commit versions within the version range for dependency testing.

[0056] For example, the fault location system 1000 can directly select the commit version at the midpoint of the version range as a candidate commit version. For example, if the current version range is [lib1_commit_50, lib1_commit_100], lib1_commit_75 can be selected as a candidate commit version.

[0057] For example, the fault location system 1000 can also select submissions whose modifications meet the set filtering conditions as candidate submissions based on the modifications of each submission within the version range. These filtering conditions can be set based on the dependency parts that are likely to cause software project faults. For example, the filtering conditions include modifications to core modules, modifications to public interfaces, inclusion of destructive change markers, modifications to dependency declarations, etc., to further reduce the number of tests and improve the efficiency of fault location.

[0058] For example, the fault location system 1000 can also select submissions whose changes meet preset filtering criteria as candidate submissions based on the changes made in each submission within a version range. These preset filtering criteria can be configured based on dependency change types that are likely to cause software project failures, and exemplarily include: modifications to core modules, modifications to public interfaces, inclusion of destructive change flags, and modifications to dependency declarations. This filtering mechanism can effectively reduce the number of tests and improve fault location efficiency.

[0059] Step S232: Update the version range based on the test results of the corresponding candidate commit version, and return to step S231 to select candidate commit versions again for dependency testing based on the updated version range until the adjacent third and fourth commit versions are located.

[0060] If the test result is successful, it indicates that the current candidate commit version has not introduced any issues. In this case, the starting point of the version range can be updated to the current candidate commit version to form an updated version range. If the test result is unsuccessful, it indicates that the current candidate commit version has introduced any issues. In this case, the ending point of the version range can be updated to the current candidate commit version to form an updated version range.

[0061] For example, the current version range is [lib1_commit_50, lib1_commit_100], and the current candidate commit version is lib1_commit_75. If the test result is successful, the updated version range will be [lib1_commit_75, lib1_commit_100]; if the test result is unsuccessful, the updated version range will be [lib1_commit_50, lib1_commit_75], thus narrowing down the version range.

[0062] Based on the updated version range, the fault location system 1000 selects candidate commit versions again for dependency testing, iteratively executing steps S231 and S232 until the version range converges to two adjacent commit versions, namely the third and fourth commit versions. For example, the initial version range [lib1_commit_50, lib1_commit_100] converges to [lib1_commit_62, lib1_commit_63] after iteration, then lib1_commit_62 is the third commit version and lib1_commit_63 is the fourth commit version.

[0063] Based on steps S231 and S232 above, compared to the sequential traversal strategy, this example uses binary search to locate the commit, which helps reduce the number of tests and further improves the efficiency of the location. For example, in the initial version range [lib1_commit_50, lib1_commit_100], there are 49 commits. Sequential traversal would require a maximum of 49 tests, while binary search would only require a maximum of about 5 tests.

[0064] In some examples, dependency testing may further include the following steps: deploying the software project to a clean test environment; updating the software project's dependencies on a first code repository to selected candidate build artifacts in the test environment to generate a test object; and testing the test object based on a test suite to obtain test results indicating successful or unsuccessful execution.

[0065] In this example, the clean test environment is an isolated runtime environment, which avoids dependency conflicts and environmental contamination.

[0066] For example, the fault location system 1000 can execute this dependency test in a containerized isolated environment. After determining the index identifier of the candidate build artifact, the fault location system 1000 creates a containerized isolated environment and starts a new container instance based on container technologies such as Docker. The container instance is pre-configured with the operating system, runtime environment, dependency libraries, etc. required for the software project to run. The software project is deployed in the container instance, the dependencies are replaced with the candidate build artifacts, the test suite is run, logs and results are recorded, and the container instance is destroyed and resources are released after the test is completed. The containerized environment can ensure complete isolation between different test tasks, high environment consistency, and accurate and reproducible test results.

[0067] Updating the software project's dependency on the first code repository to a candidate build artifact can further include: passing the index identifier of the candidate build artifact to the test environment. This index identifier, for example, includes the repository name of the first code repository and the commit hash value of the corresponding candidate commit version. In other words, the software project's original dependency on the first code repository (e.g., the build artifact corresponding to the second commit version of the first code repository) is replaced with the candidate build artifact. For example, the index identifier of the candidate build artifact can be passed to the test environment via command line. For instance, modifying "upstream_lib1>=upstream_lib1_f1c3d9b.whl" in the software project's dependency configuration file to "upstream_lib1>=upstream_lib1_3f7d92c.whl" via command line, and then downloading the candidate build artifact from the versioned storage system and installing it into the test environment using a package manager command.

[0068] This dependency update method allows for dependency replacement without modifying the software project, maintaining the independence of the testing process from the business code. Furthermore, relying on a versioned storage system and package manager for artifact download and installation ensures automated execution of the dependency replacement process and environmental consistency, improving the reliability and efficiency of dependency testing.

[0069] Step S240: Output a fault diagnosis report for the software project based on the fourth submission version.

[0070] The fault location system 1000 can generate a fault diagnosis report based on the identified fourth commit. The fault diagnosis report includes, for example, at least some of the following information items: the commit hash of the fourth commit, the code change link corresponding to the fourth commit, the index identifier of the build artifact associated with the fourth commit, the updated content of the fourth commit, and the scope of impact of the updated content. This allows testers to quickly identify the fault problem based on the content of the fault diagnosis report.

[0071] For example, the report content could include: "Fault location completed. Upstream repository: upstream_lib1, issue submission: upstream_lib1_3f7d92c, submission time: 2024-01-15 10:30:00, submission author: developer_A, code change link: https: / / gitlab.com / upstream_lib / commit / commit_53, scope of impact: core interface module of the software project."

[0072] Fault diagnosis reports can be output in a structured format and notified to relevant subscribers via email or instant messaging tools.

[0073] Based on steps S210 to S240 above, this embodiment pre-builds and stores the committed versions in the first code repository, avoiding repeated time-consuming build operations during the problem localization process, which can significantly shorten the time spent on fault localization.

[0074] <Second Embodiment> In this embodiment, the fault location system listens to the commit events of the first code repository and initiates a pre-build process for the corresponding commit version. Figure 4 A flowchart illustrating the fault location method according to this embodiment is shown. Figure 4 As shown, in this embodiment, the pre-construction process and Figure 2 The dependency testing processes shown are executed independently of each other, and the pre-build process may include the following steps S410 to S430: Step S410: Listen for commit events in the first code repository.

[0075] Step S420: Based on the monitored current commit event, trigger a pre-build operation for the current commit version corresponding to the current commit event to obtain the build artifact corresponding to the current commit version.

[0076] The fault location system 1000 includes a build artifact management module, which is implemented using automated build tools such as Jenkins. The build artifact management module can listen for commit events in the first code repository by configuring a webhook in the first code repository. The webhook points the callback address of the commit event to the trigger interface of the build artifact management module. When a new commit version is generated in the first code repository, the webhook sends a commit event notification containing information such as the repository name and commit hash value to the build artifact management module.

[0077] After receiving a commit event notification, the build artifact management module automatically triggers a pre-build task, pulls the commit version indicated by the commit event notification from the first code repository, executes the build script, completes build processing such as compilation, linking, and packaging, and builds the corresponding build artifact based on the commit version.

[0078] Step S430: Store the build artifacts corresponding to the current commit version in the versioned storage system.

[0079] After the build is completed, the build artifact management module can name the build artifacts according to the standardized naming rule of repository name_commit hash value. The name of the build artifact serves as an index identifier for the build artifact and can be used to find the associated build artifact. For example, the build artifact corresponding to a commit version in the first code repository is named upstream_lib1_3f7d92c.whl.

[0080] The build artifact management module can upload named build artifacts to a pre-defined versioned storage system (such as a file server, NFS storage, or artifact repository) for storage. Simultaneously, the build artifact management module can be configured to automatically record and store the build metadata corresponding to this build. This metadata may include: build time, build artifact name, commit hash value, code repository address, versions of dependent libraries used in the build, build parameter configuration, and build execution results. This metadata is stored in association with the build artifact for quick retrieval and retrieval during subsequent fault location.

[0081] According to the method in this embodiment, automated building and artifact storage can be completed simultaneously with code submission. Compared to the pre-built method that periodically pulls artifacts according to a preset build cycle, this embodiment can generate corresponding build artifacts in real time when the code is submitted, ensuring that the build artifacts are strictly synchronized with the code version, covering all submitted versions, eliminating delays and version omissions caused by the build cycle, and further improving the timeliness and completeness of fault location.

[0082] <Third Embodiment> In this embodiment, the software project may depend on multiple upstream code repositories, including the first code repository in the first embodiment. Based on the first and second embodiments, this embodiment further describes a step-by-step troubleshooting scheme when the software project depends on multiple upstream code repositories.

[0083] In this embodiment, the fault report includes two version identifiers for each upstream code repository it depends on. That is, the fault report includes not only the first and second commit versions of the first code repository in the first embodiment, but also two version identifiers for each other code repository in the multiple code repositories. One version identifier indicates the commit version of the other code repository that the software project depends on when it executes successfully, and the other version identifier indicates the commit version of the other code repository that the software project depends on when it fails to execute.

[0084] When a downstream software project depends on multiple upstream code repositories, a failure may be caused by changes in one or more upstream repositories. This embodiment employs a step-by-step troubleshooting mechanism. While troubleshooting one code repository, the dependencies of the remaining code repositories are fixed to the versions that execute successfully. For example, when troubleshooting the first code repository, the dependencies of other code repositories are first fixed to the versions that execute successfully to locate the first code repository.

[0085] Therefore, in this embodiment, when performing dependency testing on the first code repository, the test object will be generated based on the software project, the candidate build artifacts pre-built based on the candidate commit versions of the corresponding first code repository, and the build artifacts pre-built based on the first commit versions of other code repositories; wherein, the first commit version of other code repositories is: the commit version of the corresponding other code repository that enables the software project to execute successfully.

[0086] For example, a software project depends on both upstream_lib1 and upstream_lib2. The first commits that allow the project to execute successfully are upstream_lib1_commit_50 and upstream_lib2_commit_50, while the second commits that cause execution failure are upstream_lib1_commit_100 and upstream_lib2_commit_100. The first round of investigation focuses on the build artifacts corresponding to upstream_lib2_commit_50 in the second repository, locating the problem in the first repository (lib1), resulting in the problematic commit version lib1_commit_80. The second round of investigation focuses on the build artifacts corresponding to upstream_lib1_commit_50 in the first repository, locating the problem in the second repository (lib2), resulting in the problematic commit version lib2_commit_60, or verifying that the problem is unrelated to the second repository.

[0087] In this embodiment, the fault location module summarizes the test results of multiple upstream code repositories and generates a comprehensive diagnostic report containing all the submitted issues to guide developers in fixing the problems.

[0088] In this embodiment, the fault location system 1000 can be configured to perform location tasks in parallel on multiple upstream code repositories through multiple processes. The location tasks of different repositories run simultaneously in independent containerized environments without interfering with each other. After the location is completed, all results are summarized to generate a comprehensive report, thereby improving the location efficiency in complex dependency scenarios.

[0089] This embodiment uses a step-by-step troubleshooting mechanism to accurately identify the commit version that introduces the fault in each upstream warehouse in a multi-warehouse dependency scenario, ensuring accurate location results.

[0090] <Fourth Embodiment> This embodiment provides a fault location system. For example... Figure 5 As shown, the fault location system 1000 includes: a construction product management module 510, a location scheduling module 520, a testing module 530, and a report generation module 540.

[0091] The build artifact management module 510 is used to listen for build events of the first code repository, and trigger a pre-build operation for the associated commit version based on the listened-up build event, generating and storing the corresponding build artifacts. For example, the build event is a commit event of the first code repository. The build artifact management module 510 listens for the commit event of the first code repository, and based on the listened-up current commit event, triggers a pre-build operation for the current commit version corresponding to the current commit event, obtaining and storing the build artifacts for the corresponding current commit version.

[0092] The location scheduling module 520 receives fault reports for the software project, determines the version range formed by the first and second commit versions of the first code repository based on the fault reports, outputs candidate commit versions located within this version range to the testing module 530 for dependency testing, and receives the test results from the testing module 530, until the adjacent third and fourth commit versions are located within the version range. For example, the location scheduling module 520 can select candidate commit versions and provide them to the testing module 530 for dependency testing using a binary search method.

[0093] The testing module 530 is used to receive candidate submission versions provided by the positioning and scheduling module 520 for dependency testing; wherein, the dependency testing includes: testing the test object using a test suite to obtain test results reflecting whether the test object is successfully executed, the test object is generated based on the software project and the pre-built candidate build artifacts corresponding to the candidate submission version, the pre-building is triggered by a build event independent of the dependency testing; the third submission version is a candidate submission version that enables the generated test object to execute successfully, and the fourth submission version is a candidate submission version that enables the generated test object to fail to execute.

[0094] The report generation module 540 is used to output a fault diagnosis report for the software project based on the fourth submission version provided by the positioning and scheduling module 520.

[0095] In this embodiment, the fault location system adopts a modular architecture design. The modules interact through standardized interfaces to collaboratively complete the automated fault location process. The modular design facilitates independent optimization, upgrades, and maintenance of each module, while also supporting plug-and-play expansion, allowing for flexible expansion of the fault location system's functionality and applicable scenarios.

[0096] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0097] Embodiments of this specification may be devices, methods, and / or computer program products. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of the embodiments of this specification.

[0098] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination thereof. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0099] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0100] Computer program instructions used to perform the operations of the embodiments described herein may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the embodiments described herein.

[0101] Various aspects of embodiments of this specification are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of this specification. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0102] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0103] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this specification. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions. It will be well known to those skilled in the art that implementation in hardware, implementation in software, and implementation using a combination of software and hardware are equivalent.

[0105] Various embodiments of this specification have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for fault location in a software project, characterized in that, include: Receive a fault report for a software project; wherein the software project depends on an upstream first code repository, and the fault report contains two version identifiers of the first code repository, wherein the first version identifier indicates the first commit version of the first code repository that the software project depends on when it executes successfully, and the second version identifier indicates the second commit version of the first code repository that the software project depends on when it fails to execute. Based on the fault report, the version range formed from the first submission version to the second submission version is determined; By performing dependency testing on candidate commit versions within the version range, adjacent third and fourth commit versions are located within the version range. The dependency testing includes: testing a test object using a test suite to obtain test results reflecting whether the test object executes successfully. The test object is generated based on the software project and pre-built candidate build artifacts corresponding to the candidate commit versions. The pre-built artifacts are triggered by build events independent of the dependency testing. The third commit version is a candidate commit version that enables the generated test object to execute successfully, and the fourth commit version is a candidate commit version that causes the generated test object to fail to execute. Based on the fourth submission, a fault diagnosis report for the software project is output.

2. The method according to claim 1, characterized in that, The build event is the commit event of the corresponding candidate commit version of the first code repository; the method further includes: Listen for commit events in the first code repository; Based on the monitored current commit event, a pre-build operation is triggered for the current commit version corresponding to the current commit event to obtain the build artifact corresponding to the current commit version; The build artifacts corresponding to the current commit version are stored in a versioned storage system.

3. The method according to claim 1, characterized in that, Based on the software project and the pre-built candidate build artifacts corresponding to the candidate submission version, the test object is generated, including: Deploy the software project to a clean test environment; In the test environment, the software project's dependency on the first code repository is updated to the candidate build artifact, and the test object is generated.

4. The method according to claim 3, characterized in that, The step of updating the software project's dependency on the first code repository to the candidate build artifact includes: By passing the index identifier of the candidate build artifact to the test environment, the software project's dependency on the first code repository is updated to the candidate build artifact; wherein, the index identifier includes the repository name of the first code repository and the commit hash value of the candidate commit version.

5. The method according to claim 1, characterized in that, The step of performing dependency testing on candidate commit versions within the version range to locate adjacent third and fourth commit versions within the version range includes: Select candidate commit versions within the specified version range for the dependency testing. The version range is updated based on the test results corresponding to the candidate submission versions; Based on the updated version range, the step of selecting candidate commit versions within the version range for dependency testing is performed again until the adjacent third and fourth commit versions are located.

6. The method according to claim 5, characterized in that, The step of selecting candidate commit versions within the version range for dependency testing includes: Based on the changes made in the submitted versions within the specified version range, submission versions whose changes meet the set filtering criteria are selected as candidate submission versions.

7. The method according to claim 1, characterized in that, The fault diagnosis report includes at least some of the following information items: the commit hash value of the fourth commit, the code change link corresponding to the fourth commit, the index identifier of the build artifact associated with the fourth commit, the update content of the fourth commit, and the impact scope information of the update content.

8. The method according to any one of claims 1 to 7, characterized in that, The software project relies on multiple upstream code repositories, including the first code repository; the fault report also includes two version identifiers for each of the other code repositories in the multiple code repositories. The test object is generated based on the software project, the pre-built candidate build artifact corresponding to the candidate commit version, and the build artifact pre-built based on the first commit version of other code repositories.

9. A fault location system for software projects, characterized in that, include: The build artifact management module is used to listen for build events for the first code repository, and trigger pre-build operations for the associated commit versions based on the listened build events, generating and storing the corresponding build artifacts; The location scheduling module is used to receive fault reports for software projects, determine the version range formed by the first commit version to the second commit version of the first code repository based on the fault reports, and output the candidate commit versions located in the version range to the testing module for dependency testing, until the adjacent third commit version and fourth commit version are located in the version range. The testing module is configured to receive candidate submission versions provided by the positioning and scheduling module and perform the dependency testing; wherein, the dependency testing includes: testing the test object using a test suite to obtain test results reflecting whether the test object executes successfully, the test object being generated based on the software project and pre-built candidate build artifacts corresponding to the candidate submission version, the pre-built artifacts being independent of the dependency testing; the third submission version is a candidate submission version that enables the generated test object to execute successfully, and the fourth submission version is a candidate submission version that causes the generated test object to fail to execute; and... The report generation module is used to output a fault diagnosis report for the software project based on the fourth submission version provided by the positioning and scheduling module.

10. An electronic device, characterized in that, Deploy the fault location system as described in claim 9; or, the electronic device includes: At least one processor; and A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

11. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions for causing the computer to perform the method of any one of claims 1-8.

Images