Potential collision modification detection

Abstract

The present disclosure provides methods, apparatus, systems, and computer program products for detecting potential conflicting modifications. A completion of a first request involving a first modification to a first set of items may be identified. A second set of items having a dependency relationship with the first set of items may be obtained. A second request may be determined from the first set of items and the second set of items, where the second request relates to a second modification to at least one item of the first set of items and the second set of items. The second modification may be determined as a potentially conflicting modification.

Description

Background Art

[0001] In software development, multiple developers can work independently and simultaneously on software development. For example, one developer can check out program code from the master branch of a code repository, modify the program code locally, and create a request to check in the modified program code to the master branch. During this time, another developer can check out program code from the master branch or check in the modified program code to the master branch. Summary of the invention

[0002] This summary is provided to introduce a set of concepts that will be further described in the following detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] Embodiments of the present disclosure provide methods, devices, systems, and computer program products for detecting potentially conflicting modifications. Completion of a first request may be identified, the first request involving a first modification to a first set of items. A second set of items having a dependency relationship with the first set of items may be acquired. A second request may be determined based on the first set of items and the second set of items, wherein the second request involves a second modification to at least one item in the first set of items and the second set of items. The second modification may be determined as a potentially conflicting modification.

[0004] It should be noted that one or more of the above aspects include the features specifically pointed out in the following detailed description and claims. The following description and drawings set forth in detail certain illustrative features of the one or more aspects. These features are merely indicative of the various ways in which the principles of various aspects may be implemented, and the present disclosure is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The disclosed aspects will be described below in conjunction with the accompanying drawings, which are provided to illustrate rather than limit the disclosed aspects.

[0006] Figure 1 An exemplary process for implementing aspects of the present disclosure according to an embodiment is shown.

[0007] Figure 2 An exemplary system is shown upon which aspects of the present disclosure may be implemented.

[0008] Figure 3 An exemplary process of dependency determination according to an embodiment is shown.

[0009] Figure 4 An exemplary process of determining dependency information according to an embodiment is shown.

[0010] Figure 5 An exemplary process of determining dependency information according to an embodiment is shown.

[0011] Figure 6 An exemplary dependency relationship according to an embodiment is shown.

[0012] Figure 7 An exemplary process of potentially conflicting modification determination according to an embodiment is shown.

[0013] Figure 8 An example of a collection of items according to an embodiment is shown.

[0014] Fig. 9 An exemplary process of conflicting modification determination according to an embodiment is shown.

[0015] Fig.10 An exemplary process of conflicting modification determination based on static analysis according to an embodiment is shown.

[0016] Fig.11 An exemplary process for conflicting modification determination based on executing a build according to an embodiment is shown.

[0017] Fig.12 An exemplary process for conflicting modification determination based on executing a build according to an embodiment is shown.

[0018] Fig.13 An example of a failed dependent project according to an embodiment is shown.

[0019] Fig.14 A flow chart of an exemplary method for detecting potentially conflicting modifications according to an embodiment is shown.

[0020] Fig.15 An exemplary apparatus for detecting potentially conflicting modifications according to an embodiment is shown. DETAILED DESCRIPTION

[0021] The present disclosure will now be discussed with reference to various exemplary embodiments. It should be understood that the discussion of these embodiments is only for enabling those skilled in the art to better understand and thereby implement the embodiments of the present disclosure, and does not teach any limitation on the scope of the present disclosure.

[0022] In software development, multiple developers successively check out program code from the main branch, modify the program code locally, and create a request for checking the modified program code into the main branch, such as a pull request (PR). There may be conflicts between these modifications. Conflicting modifications may cause serious consequences such as build breaks on the main branch and affect all development work based on the main branch. Existing solutions are usually unable to effectively detect conflicting modifications or potentially conflicting modifications. For example, some existing solutions focus on detecting conflicting modifications in the post-check-in phase, when the conflicting modifications have already entered the main branch; some existing solutions require more time and computing resources to obtain detection results; the detection results of some existing solutions are inaccurate, such as missing a large number of conflicting modifications in the results or including a large number of non-conflicting modifications in the results; and so on.

[0023] Embodiments of the present disclosure propose an effective mechanism for detecting potential conflicting modifications and / or conflicting modifications. Embodiments of the present disclosure may perform dependency determination for a first request to determine a first set of items corresponding to a first modification involved in the first request and a second set of items having a dependency relationship with the first set of items. Embodiments of the present disclosure may perform potential conflicting modification determination relative to the first request based on the determined dependency, for example, by determining a second request involving a second modification to the first set of items and / or the second set of items and determining the second request as involving a potential conflicting modification relative to the first request. Embodiments of the present disclosure may perform conflicting modification determination for the second request, for example, by performing static analysis on the modified project and / or performing a build on the program code including the first modification and the second modification, and then determining whether there is a conflicting modification based on the static analysis result and / or the build result.

[0024] The embodiments of the present disclosure can use the dependencies between projects to determine potential conflicting modifications, which can avoid the following two situations: (1) the detection scale is too large, such as analyzing too many unrelated or low-related projects and / or files, determining too many projects as involving potential conflicting modifications, etc.; and (2) the detection is not comprehensive, such as analyzing too few projects and / or files, so that a comprehensive detection result cannot be obtained, such as the detection can only cover the situation where multiple modifications are directed to the same project and / or file. By performing static analysis on the program code, the embodiments of the present disclosure can quickly detect conflicting modifications. For example, depending on the size of the projects and / or the number of files involved, performing static analysis on the program code may take several minutes or less. By performing static analysis on the program code, the embodiments of the present disclosure can determine potential conflicting modifications and conflicting modifications without compiling the program code, thereby being applicable to various types of program code languages, including programming languages ​​(e.g., C, C++ and Java), scripting languages ​​(e.g., JavaScript and Python), markup languages ​​(e.g., XML and html), etc. By executing a build on a program code including multiple potential conflicting modifications, the embodiment of the present disclosure can determine whether each of the multiple potential conflicting modifications is a conflicting modification by compiling only once, thereby obtaining accurate results with less time and computing resources. The embodiment of the present disclosure can be executed before checking the second modification into the main branch, thereby avoiding or reducing the interruption of the build on the main branch.

[0025] In this article, "conflicting modification" may refer to any second modification that causes a conflict relative to a first modification, and the conflict may include causing errors, inconsistencies, inaccuracies, etc. In this article, "potential conflicting modification" may refer to possible potential conflicting modifications. In this article, "request" may refer to any request related to modification, such as but not limited to a pull request for checking in the modified code into the main branch. Pull request may also be referred to as merge request. In this article, "build" may include compilation, and may further include at least one of the following: unit testing, functional testing, build strategy evaluation, etc. In this article, "static analysis" may refer to code-level analysis performed without performing compilation. In this article, "dependency" may refer to any association known to those skilled in the art, including direct and / or indirect dependencies. For example, in the context of program code, if the correct operation of a piece of code directly and / or indirectly depends on another piece of code, there may be a dependency between the two pieces of code, and there may be a dependency between the files and / or projects containing the two pieces of code. In this article, the meaning of "project" may include "file". In this article, the meaning of "main branch" may include target branch and destination branch.

[0026] In one aspect, embodiments of the present disclosure may determine dependencies before potential conflicting modifications are determined, store the obtained dependency information in a database, and obtain the required dependency information from the database during the determination of potential conflicting modifications. In one aspect, embodiments of the present disclosure may determine dependencies during the determination of potential conflicting modifications.

[0027] Embodiments of the present disclosure may be applied to various application scenarios. For example, in software development, embodiments of the present disclosure may effectively detect potential conflict modifications or conflict modifications, and perform interactive actions accordingly, such as providing notifications about potential conflict modifications or conflict modifications and / or preventing them from being checked into the main branch. It should be understood that embodiments of the present disclosure are not limited to being applied in software development, but may also be applied to any application scenario where potential conflict modifications or conflict modifications need to be detected. For example, in an online collaborative environment, multiple users may request to modify one or more projects in parallel. There may be conflicts between multiple requests from these users. Assume that a first request involves modifying a uniform resource identifier (Uniform Resource Identifier) ​​of a target resource in a first project, while a second request involves referencing the target resource in a second project by an original uniform resource identifier. After the first request and the second request are completed, an error may occur in the second project. Embodiments of the present disclosure may be used to detect such potential conflict modifications and / or conflict modifications to avoid or reduce the occurrence of errors.

[0028] Figure 1 An exemplary process 100 for implementing aspects of the present disclosure is shown, according to an embodiment. The process 100 may be performed automatically.

[0029] At 110, dependency determination may be performed. In one implementation, dependency determination may be performed for a first request involving a first modification to a first set of items. In one implementation, dependency determination may be performed for one or more other requests.

[0030] At 120, a potential conflicting modification determination may be performed. In one implementation, it may be determined for the second request whether the second modification involved is a potential conflicting modification relative to the first modification. In one implementation, such a second request may be searched for a modification involved that is a potential conflicting modification relative to the first modification.

[0031] At 130, a conflicting modification determination may be performed. In one implementation, a conflicting modification determination may be performed for the potential conflicting modification obtained at 120 (eg, the second modification).

[0032] At 140, an interactive action may be performed. In one implementation, the interactive action may include, in the case where the second modification is determined to be a conflicting modification, providing a notification for the second request that the second modification is determined to be a conflicting modification, which notification may be provided to any user who follows the second request, such as a user who creates, subscribes to, and / or watches the request. The notification may be added to the second request in the form of a comment. In one implementation, the interactive action may include preventing the second modification from being checked in to the main branch. Optionally, the interactive action may include providing a notification for the first request that the second modification is determined to be a conflicting modification, which notification may be provided to users who follow the first request.

[0033] It should be understood that all steps and their sequences in process 100 are exemplary, and the embodiments of the present disclosure will also cover any modification of process 100 .

[0034] In one case, the conflicting modification determination step at 130 can be omitted from process 100. For example, when the first request involves a large number of modifications (e.g., hundreds or even thousands of modifications), by omitting the conflicting modification determination step at 130, a large number of requests can be prevented from receiving notifications about potential conflicting modifications. For example, when the second request involves a large number of modifications, by omitting the conflicting modification determination step at 130, the second request can be prevented from frequently receiving notifications about potential conflicting modifications. In such a case, omitting the conflicting modification determination can avoid consuming excessive time and computing resources.

[0035] In one case, a step of performing an interactive action can be added before step 130. For example, if it is determined at step 120 that there are potential conflicting modifications, an interactive action can be performed in response to determining that there are potential conflicting modifications, such as providing a notification about the presence of potential conflicting modifications, which can be provided to a user who is interested in the second request. In one case, step 140 can be omitted from process 100.

[0036] In one case, despite Figure 1 It is shown that step 110 is performed before step 120, but these two steps can also be performed in parallel. For example, during the execution of step 120, when the dependency relationship needs to be used, step 110 can be performed.

[0037] Figure 2 An exemplary system 200 is shown upon which aspects of the present disclosure may be implemented. In one implementation, the system 200 may be implemented as software, portions of which may be used in conjunction with the various hardware described herein. Figure 2Only non-limiting examples of systems for implementing aspects of the present disclosure are given, and it should be understood that other systems for implementing aspects of the present disclosure can be established in various other ways. The system 200 can be executed on hardware such as client devices, local application providers, web servers, server clusters, external services, and other servers. The system 200 can be a distributed system.

[0038] The exemplary system 200 may include a request dependency tracker 210 and a conflicting modification detector 220. The request dependency tracker 210 may be configured to perform dependency determination, e.g. Figure 1 Step 110 in the above. The conflict modification detector 220 may be configured to perform potential conflict modification determination and conflict modification determination, e.g. Figure 1 Optionally, the conflict modification detector 220 may be configured to perform interactive actions, such as Figure 1 Step 140 in .

[0039] Figure 3 FIG. 3 is an exemplary process 300 for determining a dependency relationship according to an embodiment. Figure 1 The process 300 may be performed by Figure 2 The request dependency tracker 210 in the illustrated system 200 performs.

[0040] At 310, an update of a first request may be identified, the first request involving a first modification to a first set of items. The "update" of a request may indicate a change to the request. For example, the creator of the request may create the request through a zeroth update, and include further program code changes in the request through subsequent updates. The projects to which the modified program code belongs may constitute a first set of items. In one implementation, a message may be received from a message service, and the message may include attributes, such as an "event type." It may be identified that a message involves an update to a request by analyzing the value of the "event type." The message service may be any message service known in the art.

[0041] At 320, dependency information of the first set of items may be determined. The dependency information may be any information that can indicate a second set of items that has a dependency relationship with the first set of items, such as identification information or an item path of each item in the second set of items. In one implementation, the dependency information may indicate the first set of items and the second set of items. Depending on the circumstances, the second set of items may include zero, one, or more items.

[0042] At 330, the dependency information may be stored in a database for use in subsequent steps. In one implementation, identification information of the first message, the first request, the first modification, and / or the first item set may be stored in a database together with the dependency information.

[0043] It should be understood that all steps and their order in process 300 are exemplary, and the embodiments of the present disclosure will also cover any modification of process 300. For example, in some implementations, process 300 may omit step 330. For example, dependency determination is performed only when the dependency is needed, thereby eliminating the need to store dependency information in a database in advance.

[0044] Figure 4 FIG. 4 is an exemplary process 400 for determining dependency information according to an embodiment. Figure 3 An exemplary implementation of step 320 in FIG.

[0045] At 410, a log file associated with the first request may be obtained. In one implementation, a build log file (build log) generated when the first request is updated may be obtained. In some cases, when the first request is updated, the reference relationship between the projects may be analyzed for the first project set involved in the first request and recorded in the log file. For example, the log file may include, for each project in the first project set, the project path of the project and the project paths of all parent projects and child projects of the project. The log file may be referred to as a ParserDump file, etc.

[0046] At 420, dependency information of the first project set can be extracted from the log file. The dependency information can indicate a direct dependency. For example, for each project in the first project set, information indicating the parent project and / or child project of the project can be extracted from the log file as information indicating a direct dependency. The dependency information can also indicate an indirect dependency. For example, the parent project of the parent project can be further determined for each parent project, and / or the child project of the child project can be determined for each child project, and the corresponding identification information can be included in the dependency information, so that the dependency information indicates a two-level dependency of the first project set. Optionally, information indicating more than two levels of dependencies of the first project set can be extracted. Optionally, information indicating all dependencies of the first project set can be extracted. Optionally, only information indicating a first-level dependency of the first project set can be extracted.

[0047] Figure 5 An exemplary process 500 for determining dependency information according to an embodiment is shown. Process 500 is Figure 3An exemplary implementation of step 320 in FIG.

[0048] At 510, for each project in the first project set, a description file corresponding to the project may be obtained, wherein the description file may include information associated with the dependency relationship of the project. The project description file may be stored locally or remotely relative to the project. For example, the description file of the project may be stored in the same folder as the corresponding project, or in a lower-level folder of the corresponding project.

[0049] At 520, dependency information of the first project set may be formed based on information associated with the dependency of each project in the first project set. In one implementation, information indicating the parent project and / or child project of each project may be extracted from each acquired project description file, and the dependency information of the first project set may be formed by integrating the information corresponding to each project. In one implementation and when the content of the project description file includes information indicating multi-level dependency, the information indicating multi-level dependency may be extracted from the project description file.

[0050] It should be understood that all steps in process 500 and their order are exemplary, and the embodiments of the present disclosure will also cover modifications to process 300 in any manner. For example, one or more steps in process 500 may be performed multiple times or iteratively. In one implementation, the parent project and / or child project B of project A may be determined through the project description file, and the parent project and / or child project C of project B may be determined through the description file of project B, and so on. In this way, the multi-level dependencies of project A may be determined, thereby obtaining the multi-level dependencies of the first project set. In one implementation, only the first-level dependencies of the first project set may be obtained.

[0051] Figure 6 An exemplary dependency relationship 600 is shown according to an embodiment. Figure 6 Items 601 and 602 in can be exemplary items in the first item set in an embodiment of the present disclosure. Item 601 is shown to have parent items 603 and 604 and child items 608, 609 and 610. Item 602 is shown to have parent items 605, 606 and 607 and child item 611.

[0052] Taking project 601 and its parent project 603 as an example, the dependency relationship between parent project 603 and project 601 may refer to project 601 referencing parent project 603. As an example of project 601 referencing parent project 603, a function defined in parent project 603 may be called in project 601, a class defined in parent project 603 may be instantiated in project 601, and so on. The dependency relationship between project 601 and its parent project 603 may be referred to as a direct dependency relationship. In some implementations, if parent project 603 and parent project 604 have no other associations except that they are both parent projects of project 601, it can be considered that there is no dependency relationship between parent project 603 and parent project 604.

[0053] Similarly, the dependency relationship between project 601 and subproject 608 may mean that subproject 608 references project 601. The dependency relationship between project 601 and subproject 608 may be referred to as a direct dependency relationship. In some implementations, if subproject 608 and subproject 609 have no other associations except that they are both subprojects of project 601, it may be considered that there is no dependency relationship between subproject 608 and subproject 609.

[0054] In some implementations, there is also a dependency relationship, ie, an indirect dependency relationship, between the sub-project 608 and the parent project 603. The dependency relationship between the sub-project 608 and the parent project 603 may be based on the fact that the sub-project 608 references the project 601, and the project 601 references the parent project 603.

[0055] It should be understood that Figure 6 The dependency relationship in is exemplary, and the embodiments of the present disclosure will also cover other forms of dependency relationships. For example, although Figure 6 Only the direct dependency between projects 601 and 602, i.e., the first-level dependency, is shown in FIG. 6 , but in some implementations, there may also be multiple levels of dependency. For example, project 601 may have a parent project, a grandfather project, ..., etc., and may have a child project, a grandchild project, ..., etc.

[0056] In some implementations, the dependency relationship only includes direct dependency relationships. For example, it can be considered that there is no dependency relationship between the sub-project 608 and the parent project 603.

[0057] It should be understood that although Figure 6 Two items 601 and 602 and a certain number of parent items and child items are shown in FIG. 1 , but the first item set may include more or fewer items, and each item in the first item set may have zero, one or more parent items and / or child items.

[0058] Figure 7FIG. 7 is an exemplary process 700 for determining potentially conflicting modifications according to an embodiment. Figure 1 Process 700 may be performed to determine whether there are potential conflicting modifications for a first request.

[0059] At 710, the completion of a first request can be identified, wherein the first request involves a first modification to a first set of projects. The "completion" of a request can indicate that the program code changes involved in the request have been checked in to a main branch. The project to which the modified program code belongs can constitute the first set of projects. In one implementation, a message can be received from a message service, and the message can include an attribute, such as an "event type". The completion of a request that the message involves can be identified by analyzing the value of the "event type". The message service can be any message service known in the art.

[0060] At 720, dependency information of the first project set may be obtained. In one implementation, if by executing Figure 3 If the optional step 330 in the first project set has stored the dependency information of the first project set in the database, then step 720 can obtain the dependency information by querying the database. In one implementation, step 720 can be performed by executing Figure 3 Step 320 in the example is used to obtain dependency information.

[0061] At 730, a second item set having a dependency relationship with the first item set may be acquired according to the dependency information. In the case where the dependency information indicates an n-level dependency relationship of the first item set, a second item set having an m-level dependency relationship with the first item set may be acquired, where n≥m, so that the second item set may include items having 1 to m-level dependencies with the first item set.

[0062] At 740, a second request can be determined based on the first item set and the second item set, wherein the second request involves a second modification of at least one item in the first item set and the second item set. In one implementation, the second request can be determined by querying a database. For example, the modification item involved in the second request has been determined previously (for example, when the second request is updated), and the modification item is stored in the database. Then, if the modification item is in the first item set or the second item set, that is, the second request modifies the same item as the first request or the two requested items to be modified have a dependency relationship, then since the database includes the association between the modification item and the second request, the second request can be obtained based on the first item set and the second item set by querying the database. In one implementation, the modification item involved in each request can be determined for one or more requests, and if the modification item involved in a request is included in the first item set or the second item set, the request is determined as the second request.

[0063] In 750, the second request may be screened or verified. In the case where the second request includes one request, the second request may be verified. In the case where the second request includes multiple requests, the second request may be screened.

[0064] In one implementation, screening or verifying the second request may include determining whether the second request is in an active state. The active state of the request may indicate that the request is ready for review and that the modifications involved in the request are expected to be checked into the main branch (e.g., in the future). If it is determined that the second request is in an active state, the second request may be considered to have passed screening or verification.

[0065] In one implementation, screening or verifying the second request may include determining whether a build strategy evaluation for the second request has been approved, is running, or is in a queue. The build strategy evaluation for the request may include an evaluation of the results of a build, wherein the build is performed on program code including the modifications involved in the request. Performing a build strategy evaluation may include determining whether the request meets the requirements of the main branch for the request. For example, the main branch may require that the request must be built successfully, reviewed by a specific reviewer, etc. before completion. If the build strategy evaluation for the request has been approved, is running, or is in a queue, it may indicate that the build strategy evaluation has not returned a failure result or has not yet returned a failure result. By determining that the build strategy evaluation for the request has been approved, is running, or is in a queue, requests that fail to pass the build strategy evaluation can be eliminated because such requests themselves are problematic and are generally not allowed to be completed before being updated, that is, the modifications to the request will not be checked in to the main branch.

[0066] In one implementation, screening or verifying the second request may include determining whether the second request has passed a unit test. The meaning of a unit test is known in the art. Passing a unit test may indicate that the behavior of the program code targeted by the test is consistent with the developer's expectations.

[0067] In one implementation, screening or verifying the second request may include determining whether the second request has passed a functional test. The meaning of a functional test is known in the art. Passing a functional test may indicate that the program code targeted by the test is able to provide normal functionality for the target user.

[0068] In 760, it may be determined whether there is a potential conflicting modification relative to the first modification. In one implementation, if any second request passes the screening or verification in step 750, the corresponding second request is determined to involve a potential conflicting modification, that is, the corresponding second modification is determined to be a potential conflicting modification. Otherwise, it may be determined that there is no potential conflicting modification.

[0069] It should be understood that all steps and their order in process 700 are exemplary, and embodiments of the present disclosure will also cover any modification of process 700. For example, process 700 may omit step 710, or perform step 720 in response to other conditions, such as the update of the first request or the receipt of any information associated with the first request. For example, process 700 may omit step 750, that is, determine the second request determined at step 740 as involving a potential conflict modification.

[0070] In some cases, executing step 740 may return zero second requests, that is, no second request involves modification of the first item set or the second item set. At this time, it can be determined that there are no conflicting modifications.

[0071] Figure 8 An example of a collection of items 800 is shown, according to an embodiment. Figure 8 Items 801-811 in Figure 6 , and the items 601-611 in the project 801 correspond one to one. That is, project 801 has parent projects 803 and 804 and child projects 808, 809 and 810, and project 802 has parent projects 805, 806 and 807 and child project 811. The first project set 820 includes projects 801 and 802, and the second project set 830 includes projects 803-811. In combination with some embodiments of the present disclosure, the first request involves modifications to projects 801 and 802. The first project set 820 including projects 801 and 802 has a dependency relationship with the second project set 830 including projects 803-811. The dependency information of the first project set 820 can indicate the second project set 830, and optionally indicates the first project set 820.

[0072] It should be understood that Figure 8 The project collection in is exemplary, and the embodiments of the present disclosure will also cover project collections of other forms and sizes. For example, although Figure 8 It is shown in FIG. 1 that the second project set includes the parent project and the child project of the first project set, but the second project set may include only the parent project or only the child project, or may include multiple levels of dependencies, for example, grandparent projects and / or grandchild projects, etc.

[0073] Fig. 9 An exemplary process 900 for conflicting modification determination according to an embodiment is shown. Process 900 is Figure 1 The process 900 may be performed to determine whether there is a conflict between a first modification involved in a first request and a second modification 902 involved in a second request, that is, whether the second modification is a conflicting modification with respect to the first modification.

[0074] At 910, in response to determining the second modification as a potential conflict modification, static analysis can be performed on at least one project involved in the first modification and the second modification. In one implementation, assuming that the first modification involves project A in the first project set, and the second modification also involves project A, the at least one project can include project A. In one implementation, assuming that the first modification involves project B in the first project set, and the second modification involves project C in the second project set that has a dependency relationship with project B, the at least one project can include projects B and C. In one implementation, performing static analysis can include determining the functions defined in each class and the classes instantiated and the functions called in each function for at least one project. In one implementation, performing static analysis can further include determining the dependency relationship between classes and / or functions in at least one project. For example, by determining that a first function is defined in a first class and the first function is called in a second function of a second class, it can be determined that the second function of the second class depends on the first function of the first class. In one implementation, performing static analysis can further include determining whether the definition and instantiation of a class and / or the definition and call of a function are consistent. For example, you can determine whether the number and types of arguments provided when calling a function are consistent with the function's definition.

[0075] At 920, the second modification may be determined as a conflicting modification or a non-conflicting modification based on the result of the static analysis. In the case where the second modification includes multiple modifications, one or more of the modifications may be determined as a conflicting modification or a non-conflicting modification. Assuming that the result of the static analysis indicates that the definition of the first function is inconsistent with the call to the first function in the second function, and it is determined that the two functions are modified in the first modification and a second modification, respectively, the second modification may be determined as a conflicting modification, and other second modifications may be optionally determined as non-conflicting modifications.

[0076] At 930, in response to determining the second modification as a potential conflicting modification, a build for a program code comprising at least the first modification and the second modification may be performed. The build may include compiling, and may further include at least one of: unit testing, functional testing, building strategy evaluation, etc. In one implementation, performing the build may include tentatively merging the second modification with a current main branch comprising the first modification, and then performing the build on the merged program code. In one implementation, a build for a program code comprising at least the first modification and a plurality of second modifications may be performed.

[0077] At 940, the build results can be analyzed. In one implementation, the build results can include one or more of the following results for each project related to the first modification and the second modification: compilation results, unit test results, functional test results, or build strategy evaluation results. The compilation results of the project can indicate whether the project is successfully compiled. The unit test results of the project can indicate whether the project has passed the unit test, for example, whether the value returned by the program code in the project in the test is consistent with the developer's expectations. The functional test results of the project can indicate whether the project has passed the functional test, for example, whether the function that the project expects to provide to the target user works properly. The build strategy evaluation results of the project can determine whether the request corresponding to the project meets specific requirements. Assuming that the main branch requires that the request must be reviewed by a specific reviewer before completion, executing the build strategy evaluation can determine whether the request has been reviewed by a specific reviewer. In one implementation, the analysis results can determine each project that caused the build to fail. For example, it can be determined for each project whether the project fails to compile.

[0078] At 950, it may be determined whether there is a conflicting modification based on the analysis result. In one implementation, it may be determined whether the second modification corresponding to each project is a conflicting modification based on the analysis result of each project. For example, if the analysis result indicates that a certain project causes a build failure, such as a build failure caused by a compilation failure of the project, it may be determined that the second modification corresponding to the project is a conflicting modification.

[0079] It should be understood that process 900 includes two branches, namely, a first branch corresponding to steps 910 to 920 and a second branch corresponding to steps 930 to 950. Process 900 can execute any one or both of the two branches, and can execute the two branches in parallel or sequentially. For example, steps 930 to 950 can be executed for the second modification in response to step 920 determining that the second modification is a non-conflicting modification. For example, steps 930 to 950 can be omitted in response to step 920 determining that the second modification is a conflicting modification.

[0080] It should be understood that all steps and their order in process 900 are exemplary, and embodiments of the present disclosure will also cover modifications to process 900 in any manner. For example, although not explicitly shown in process 900, in response to a build failure performed at step 930, the second modification can be prevented from being checked in to the main branch, and a notification that the second modification will cause the main branch build to be interrupted is provided to notify users who are concerned about the corresponding second request. For example, although not explicitly shown in process 900, the final determination can be made by combining the determination results of steps 920 and 950. For example, only when the second modification is determined to be a conflicting modification at both steps 920 and 950, the second modification is determined to be a conflicting modification. For example, only when the second modification is determined to be a non-conflicting modification at both steps 920 and 950, the second modification is determined to be a non-conflicting modification.

[0081] In an implementation where only the first branch is executed, conflicting modifications can be determined without compiling the program code, so that the embodiments of the present disclosure are applicable to various types of program code languages, including programming languages ​​(e.g., C, C++, and Java), scripting languages ​​(e.g., JavaScript and Python), markup languages ​​(e.g., XML and html), and the like.

[0082] In an implementation where only the first branch is executed, execution of a build may be avoided, thereby quickly detecting potentially conflicting modifications.

[0083] In the implementation of executing the second branch, a build can be performed for the program code including the first modification and multiple potential conflicting modifications, so that only one compilation is required to determine whether each of the multiple potential conflicting modifications is a conflicting modification, thereby obtaining accurate results using less time and computing resources.

[0084] Fig.10 FIG. 1 shows an exemplary process 1000 for determining conflicting modifications based on static analysis according to an embodiment. The process 1000 is Fig. 9The process 1000 may be executed to determine whether there is a conflict between a first modification involved in a first request and a second modification involved in a second request 1002 by static analysis, that is, whether the second modification is a conflicting modification relative to the first modification.

[0085] At 1010, the classes and / or functions included in at least one project involved in the first modification and the second modification may be analyzed. In one implementation, the at least one project may be at least one project involved in step 910. In one implementation, public classes and / or functions may be analyzed. In one implementation, private classes and / or functions may not be analyzed. In one implementation, analyzing the classes and / or functions included in at least one project may include determining, for at least one project, the functions defined in each class and the classes instantiated and the functions called in each function.

[0086] At 1020, the dependencies between classes and / or functions can be determined by analyzing the classes and / or functions included in at least one project. In one implementation, the relationship between the definition and instantiation of a class and / or the relationship between the definition and call of a function can be determined. For example, if class B is instantiated and function TestB() of class B is called in constructor A() of class A, then AA (i.e., function A() of class A) can be considered to be dependent on B.TestB. Alternatively, class A can be considered to be dependent on class B. For example, if function TestD() of class D is called in function E() of class B, then BE can be considered to be dependent on D.TestD. Optionally, a directed graph can be generated based on the dependencies between classes and / or functions. For example, in the example where BE depends on D.TestD, the directed graph can include node BE pointing to node D.TestD.

[0087] At 1030, it can be determined whether the definition and instantiation of a class and / or the definition and call of a function are consistent based on the dependency relationship between the classes and / or functions. For example, if it is determined at step 1020 that AA depends on B.TestB, it can be determined whether the call to B.TestB in AA is consistent with the definition of B.TestB. Assuming that a function is called in the form of B.TestB() in AA, i.e., no parameters are passed in, and the corresponding function definition in class B is public void TestB(intb), i.e., an integer type parameter is required, it can be determined that the call to B.TestB in AA is inconsistent with the definition of B.TestB. Similarly, in the case where BE depends on D.TestD, if the TestD function does not exist in class D, for example, the TestD function is renamed to TestD1 in the first modification or the second modification, it can be determined that there is an inconsistency. Any class definition and instantiation method and function definition and call method that may cause program code compilation or runtime errors can be considered inconsistent.

[0088] If it is determined at 1030 that the definition and instantiation of a class and / or the definition and invocation of a function are inconsistent, then it may be determined at 1040 that there are conflicting modifications.

[0089] If it is determined at 1030 that the definition and instantiation of the class and / or the definition and call of the function are consistent, it may be determined at 1050 that there are no conflicting modifications.

[0090] It should be understood that all steps in process 1000 and their order are exemplary, and the embodiments of the present disclosure will also cover modifications to process 1000 in any manner. For example, although not explicitly shown in process 1000, after determining that the result of step 1030 is inconsistent, one or more modifications and / or requests that cause the inconsistency can be further determined. For example, after determining that the call to B.TestB in AA is inconsistent with the definition of B.TestB, it can be further determined that the call to B.TestB in AA is newly added in the first modification, and the definition of B.TestB is changed in one of the multiple second modifications, and then it can be determined that the modification is a conflicting modification relative to the first modification. That is, one of the multiple second requests involves a conflicting modification relative to the first request.

[0091] Fig.11 An exemplary process 1100 for determining conflicting modifications based on executing a build according to an embodiment is shown. The process 1100 is Fig. 91100 is an exemplary implementation of steps 940 to 950 in . Process 1100 can be executed to determine whether the second modification involved in the second request is a conflicting modification relative to the first modification involved in the first request based on the build result 1102. In one implementation, process 1100 is applicable to the case where there is only one second request.

[0092] At 1110, it may be determined whether the build result indicates a build failure. For example, it may be determined whether the compilation of the project involved in the build failed, whether the unit test passed, etc. In one implementation, the build is performed for the program code that includes at least the first modification and the second modification. In one implementation, the build is performed according to step 930.

[0093] If it is determined at 1110 that the build is successful, it may be determined at 1150 that there are no conflicting modifications.

[0094] If the build fails at 1110, the project causing the build failure may be determined at 1120. For example, the build result may list the identification information of each project and the compilation result of the project, from which the identification information of one or more projects that failed to compile may be determined.

[0095] At 1130 , it may be determined whether the project causing the build failure is included in the first project set or the second project set. In one implementation, step 1130 may include determining whether at least one of the projects causing the build failure is included in the first project set or the second project set.

[0096] If it is determined at 1130 that the project causing the build failure is included in the first project set or the second project set, it may be determined at 1140 that there are conflicting modifications.

[0097] If it is determined at 1130 that the project causing the build failure is not included in the first project set or the second project set, then at 1150 it may be determined that there are no conflicting modifications.

[0098] Fig.12 An exemplary process 1200 for determining conflicting modifications based on executing a build according to an embodiment is shown. The process 1200 is Fig. 9 The process 1200 is an exemplary implementation of steps 940 to 950 in FIG. The process 1200 can be executed to determine whether the second modification involved in the second request is a conflicting modification relative to the first modification involved in the first request based on the build result 1202. The process 1200 is applicable to the case where there are one or more second requests.

[0099] At 1210, it may be determined whether the build result indicates a build failure. For example, it may be determined whether the compilation of the project involved in the build failed, whether the unit test passed, etc. In one implementation, the build is performed for the program code including at least the first modification and the second modification. In one implementation, the build is performed according to step 930.

[0100] If it is determined at 1210 that the build is successful, then at 1260 it is determined that there are no conflicting modifications.

[0101] If it is determined at 1210 that the build fails, then the project that caused the build failure may be determined at 1220. For example, the build result may list the identification information of each project and the compilation result of the project, and the identification information of one or more projects that failed to compile may be determined from the build result. Fig.13 At step 1220 , what is obtained may be a project set 1330 , including projects 1304 , 1305 , 1307 , and 1308 that cause the build failure.

[0102] At 1230, a project included in the first project set or the second project set may be determined from the project that caused the build failure, which may be referred to as a failed dependent project. Fig.13 , which shows a first project set 1310 and a second project set 1320. The first project set 1310 includes projects 1301-1304, and the second project set 1320 includes projects 1306-1307. At step 1230, it can be determined from the project set 1330 that project 1304 is included in the first project set 1310 and project 1307 is included in the second project set 1320. That is, projects 1304 and 1307 can be determined as failed dependent projects.

[0103] At 1240, one or more modifications associated with the failed dependent project can be determined. Fig.13 , one or more modifications associated with items 1304 and 1307 may be determined. For example, if request A and request B involve modifications to items 1304 and 1307, respectively, modification A and modification B may be determined as modifications associated with the failed dependent item.

[0104] At 1250, the one or more modifications determined at 1240 may be determined as conflicting modifications. For example, modification A and modification B in the above example are determined as conflicting modifications.

[0105] It should be understood that all steps and their order in process 1200 are exemplary, and embodiments of the present disclosure will also cover any modification of process 1200. For example, although not explicitly shown, at step 1240, one or more requests associated with the failed dependent project may be additionally or alternatively determined, such as a request involving modification of projects 1307 and 1307, and at step 1250, it may be additionally or alternatively determined that the one or more requests involve conflicting modifications.

[0106] Fig.14 A flow chart 1400 is shown of an exemplary method for detecting potentially conflicting modifications according to an embodiment.

[0107] At 1410, completion of a first request involving a first modification to a first set of items can be identified.

[0108] At 1420 , a second item set having a dependency relationship with the first item set may be obtained.

[0109] At 1430 , a second request may be determined based on the first set of items and the second set of items, wherein the second request involves a second modification of at least one item in the first set of items and the second set of items.

[0110] At 1440, the second modification can be determined as a potentially conflicting modification.

[0111] In one implementation, completion of the first request is identified based on a message received from a messaging service, the message being used to indicate completion of the first request.

[0112] In one implementation, the method may further include: receiving a first message from a message service, the first message indicating an update of the first request; determining dependency information of the first set of items; and storing the dependency information in a database.

[0113] The acquiring of the second item set having a dependency relationship with the first item set may include: acquiring the dependency relationship information from the database; and determining the second item set according to the dependency relationship information.

[0114] In one implementation, the method may further include: determining dependency information of the first item set. Wherein, acquiring a second item set having a dependency relationship with the first item set may include: determining the second item set according to the dependency information.

[0115] Determining the dependency information of the first item set may include: acquiring a log file associated with the first request; and extracting the dependency information of the first item set from the log file.

[0116] Determining the dependency information of the first project set may include: for each project in the first project set, obtaining a description file corresponding to the project, wherein the description file contains information associated with the dependency of the project; and forming the dependency information of the first project set based on the information associated with the dependency of each project in the first project set.

[0117] In one implementation, obtaining a second set of items that has a dependency relationship with the first set of items may include: determining, for each item in the first set of items, a set of dependent items that has a direct dependency relationship with the item; and forming the second set of items based on the dependent item sets corresponding to each item in the first set of items.

[0118] In one implementation, determining the second modification as a potentially conflicting modification can be performed in response to at least one of: determining that the second request is active; determining that a build strategy evaluation for the second request has been approved, is running, or is queued; determining that the second request has passed unit testing; and determining that the second request has passed functional testing.

[0119] In one implementation, the method may further include: in response to determining that the second modification is a potential conflicting modification, providing a notification that the second request involves a potential conflicting modification.

[0120] In one implementation, the method may also include: in response to determining the second modification as a potential conflicting modification, performing static analysis on at least one item involved in the first modification and the second modification; and determining the second modification as a conflicting modification or a non-conflicting modification based on the result of the static analysis.

[0121] The method may further include, in response to determining that the second modification is a conflicting modification, providing a notification that the second modification includes a conflicting modification.

[0122] The static analysis may include: determining the dependency relationship between the classes and / or the functions by analyzing the classes and / or functions contained in at least one project involved in the first modification and the second modification; and determining whether the definition and instantiation of the class and / or the definition and call of the function are consistent based on the dependency relationship between the classes and / or the functions.

[0123] In one implementation, the first request and the second request may be pull requests, and the pull requests are used to check in modifications to the program code into the main branch after the program code is checked out from the main branch.

[0124] The method may further include: in response to determining that the second modification is a potential conflicting modification, executing a build for program code including at least the first modification and the second modification; and in response to failure of the build, preventing the second modification from being checked in to the main branch.

[0125] The method may also include: in response to determining the second modification as a potentially conflicting modification, performing static analysis on at least one project involved in the first modification and the second modification; based on the result of the static analysis, determining the second modification as a non-conflicting modification; in response to determining the second modification as a non-conflicting modification, executing a build for program code including at least the first modification and the second modification; and in response to failure of the build, preventing the second modification from being checked in to the main branch.

[0126] The method may also include, in response to the build failure, performing the following operations: determining the project that caused the build failure; in response to determining that the project that caused the build failure is included in the first project set or the second project set, determining the second modification as a conflicting modification; and providing a notification that the second modification includes a conflicting modification.

[0127] Fig.15 An exemplary apparatus 1500 for detecting potentially conflicting modifications is shown according to an embodiment.

[0128] The device 1500 may include at least one processor 1510. The device 1500 may also include a memory 1520 connected to the at least one processor 1510. The memory 1520 may store computer executable instructions, which, when executed, enable the at least one processor 1510 to: identify the completion of a first request, wherein the first request involves a first modification to a first set of items, obtain a second set of items having a dependency relationship with the first set of items, determine a second request based on the first set of items and the second set of items, wherein the second request involves a second modification to at least one item in the first set of items and the second set of items, and determine the second modification corresponding to the second request as a potentially conflicting modification. In addition, the at least one processor 1510 may also be configured to perform any other operations for detecting potentially conflicting modifications according to the above-mentioned embodiments of the present disclosure.

[0129] An embodiment of the present disclosure proposes a computer program product for detecting potentially conflicting modifications. The computer program product includes a computer program, which is executed by at least one processor to: identify the completion of a first request, wherein the first request involves a first modification to a first set of items; obtain a second set of items that has a dependency relationship with the first set of items; determine a second request based on the first set of items and the second set of items, wherein the second request involves a second modification to at least one item in the first set of items and the second set of items; and determine the second modification as a potentially conflicting modification. In addition, the computer program can also be executed by the at least one processor to perform any other operations of the method for detecting potentially conflicting modifications according to the above-mentioned embodiment of the present disclosure.

[0130] The embodiments of the present disclosure may be implemented in a non-transitory computer-readable medium. The non-transitory computer-readable medium may include instructions, which, when executed, cause one or more processors to perform any step / process of the method for detecting potential conflicting modifications according to the above embodiments of the present disclosure.

[0131] It should be understood that all operations in the method described above are merely exemplary, and the present disclosure is not limited to any operation in the method or the order of these operations, but should cover all other equivalent transformations under the same or similar concept.

[0132] In addition, the articles "a" and "an" as used in this specification and the appended claims should generally be construed to mean "one" or "one or more" unless specified otherwise or clear from context to be directed to a singular form.

[0133] It should also be understood that all modules in the above described device can be implemented in various ways. These modules can be implemented as hardware, software, or a combination thereof. In addition, any module in these modules can be further divided into submodules or combined together functionally.

[0134] Processors have been described in conjunction with various devices and methods. These processors can be implemented using electronic hardware, computer software or any combination thereof. Whether these processors are implemented as hardware or software will depend on specific application and the overall design constraints imposed on the system. As an example, the processor provided in the present disclosure, any part of the processor or any combination of processors can be implemented as a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic device (PLD), a state machine, a gate logic, a discrete hardware circuit, and other suitable processing components configured to perform the various functions described in the present disclosure. The function of the processor provided in the present disclosure, any part of the processor or any combination of processors can be implemented as software performed by a microprocessor, a microcontroller, a DSP or other suitable platforms.

[0135] Software should be broadly considered to represent instructions, instruction sets, codes, code segments, program codes, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, running threads, processes, functions, etc. Software can reside in a computer-readable medium. A computer-readable medium can include, for example, a memory, which can be, for example, a magnetic storage device (e.g., a hard disk, a floppy disk, a magnetic stripe), an optical disk, a smart card, a flash memory device, a random access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, or a removable disk. Although the memory is shown as being separated from the processor in the various aspects provided in the present disclosure, the memory can also be located inside the processor (e.g., a cache or a register).

[0136] The above description is provided to enable any person skilled in the art to implement the various aspects described herein. Various modifications to these aspects are apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein. All structural and functional equivalents of the elements of the various aspects described in this disclosure that are known or to be known to those skilled in the art will be covered by the claims.

Claims

1. A method for detecting potentially conflicting modifications, include: identifying a completion of a first request involving a first modification to a first set of items; Acquire a second item set having a dependency relationship with the first item set; Determining a second request based on the first set of items and the second set of items, wherein the second request involves a second modification of at least one item in the first set of items and the second set of items; as well as The second modification is determined as a potential conflicting modification.

2. The method according to claim 1, in, Completion of the first request is identified based on a message received from a messaging service, the message being used to indicate completion of the first request.

3. The method according to claim 1, further comprising: include: receiving a first message from a messaging service, the first message indicating an update to the first request; Determining dependency information of the first project set; as well as The dependency information is stored in a database.

4. The method according to claim 3, in, The acquiring of a second set of items having a dependency relationship with the first set of items comprises: Acquire the dependency information from the database; and The second item set is determined according to the dependency information.

5. The method according to claim 1, further comprising: include: Determining dependency information of the first project set, The acquiring of a second set of items having a dependency relationship with the first set of items includes: The second item set is determined according to the dependency information.

6. The method according to claim 3 or 5, in, The determining of the dependency information of the first project set includes: Obtaining a log file associated with the first request; and Dependency information of the first project set is extracted from the log file.

7. The method according to claim 3 or 5, in, The determining of the dependency information of the first project set includes: For each project in the first project set, obtaining a description file corresponding to the project, wherein the description file contains information associated with a dependency relationship of the project; and Dependency information of the first item set is formed according to information associated with the dependency of each item in the first item set.

8. The method according to claim 1, in, The acquiring of a second set of items having a dependency relationship with the first set of items comprises: For each item in the first item set, determine a dependent item set having a direct dependency relationship with the item; and The second item set is formed according to a dependent item set corresponding to each item in the first item set.

9. The method according to claim 1, in, Determining the second modification as a potentially conflicting modification is performed in response to at least one of: determining that the second request is active; determining that a build strategy evaluation for the second request has been approved, is running, or is queued; Determining that the second request has passed the unit test; as well as It is determined that the second request has passed the functional test.

10. The method of claim 1, further comprising: include: In response to determining that the second modification is a potentially conflicting modification, providing a notification that the second request involves a potentially conflicting modification.

11. The method of claim 1, further comprising: include: In response to determining that the second modification is a potential conflicting modification, performing static analysis on at least one item involved in the first modification and the second modification; as well as According to the result of the static analysis, the second modification is determined to be a conflict modification or a non-conflict modification.

12. The method according to claim 11, further comprising: include: In response to determining that the second modification is a conflicting modification, providing a notification that the second modification includes a conflicting modification.

13. The method according to claim 11, in, The static analysis includes: Determine the dependency relationship between the classes and / or the functions by analyzing the classes and / or functions included in at least one item involved in the first modification and the second modification; and Based on the dependency relationship between the classes and / or the functions, it is determined whether the definition and instantiation of the class and / or the definition and calling of the function are consistent.

14. The method of claim 1, in, The first request and the second request are pull requests, and the pull requests are used to check in modifications to the program code into the main branch after the program code is checked out from the main branch.

15. The method of claim 14, further comprising: include: In response to determining that the second modification is a potentially conflicting modification, executing a build for program code including at least the first modification and the second modification; as well as In response to the build failing, checking the second modification into the main branch is prevented.

16. The method of claim 14, further comprising: include: In response to determining that the second modification is a potential conflicting modification, performing static analysis on at least one item involved in the first modification and the second modification; According to the result of the static analysis, determining the second modification as a non-conflicting modification; In response to determining that the second modification is a non-conflicting modification, executing a build for a program code including at least the first modification and the second modification; as well as In response to the build failing, checking the second modification into the main branch is prevented.

17. The method according to claim 15 or 16, further comprising, in response to the build failure, performing the following operations: Identify the project that caused the build failure; In response to determining that the project causing the build failure is included in the first project set or the second project set, determining the second modification as a conflicting modification; and A notification is provided that the second modification includes a conflicting modification.

18. An apparatus for detecting potentially conflicting modifications, include: at least one processor; as well as a memory storing computer executable instructions that, when executed, cause the at least one processor to: identifying a completion of a first request involving a first modification to a first set of items, Obtain a second set of items that has a dependency relationship with the first set of items, determining a second request based on the first set of items and the second set of items, wherein the second request involves a second modification of at least one item in the first set of items and the second set of items, and The second modification is determined as a potential conflicting modification.

19. A system for detecting potentially conflicting modifications, include: Request dependency tracker, configured to: In response to completion of a first request involving a first modification to a first set of items, obtaining a second set of items having a dependency relationship with the first set of items; as well as The conflicting modification detector is configured to: determining a second request based on the first set of items and the second set of items, wherein the second request involves a second modification of at least one item in the first set of items and the second set of items, and The second modification is determined as a potential conflicting modification.

20. A computer program product for detecting potentially conflicting modifications, comprising a computer program, the computer program being executed by at least one processor for: identifying a completion of a first request involving a first modification to a first set of items; Acquire a second item set having a dependency relationship with the first item set; A second request is determined according to the first set of items and the second set of items, wherein: The second request relates to a second modification of at least one item in the first set of items and the second set of items; as well as The second modification is determined as a potential conflicting modification.

Images