WO2022222626A1 - 一种增量源码获取方法、装置、电子设备及存储介质 - Google Patents

一种增量源码获取方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
WO2022222626A1
WO2022222626A1 PCT/CN2022/079596 CN2022079596W WO2022222626A1 WO 2022222626 A1 WO2022222626 A1 WO 2022222626A1 CN 2022079596 W CN2022079596 W CN 2022079596W WO 2022222626 A1 WO2022222626 A1 WO 2022222626A1
Authority
WO
WIPO (PCT)
Prior art keywords
component
warehouse
source code
code
submission
Prior art date
Application number
PCT/CN2022/079596
Other languages
English (en)
French (fr)
Inventor
谭子敬
王城波
Original Assignee
北京字节跳动网络技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京字节跳动网络技术有限公司 filed Critical 北京字节跳动网络技术有限公司
Publication of WO2022222626A1 publication Critical patent/WO2022222626A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/48—Incremental compilation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/30—Computing systems specially adapted for manufacturing

Definitions

  • the embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method, apparatus, electronic device, and storage medium for acquiring incremental source code.
  • the project source code development process includes the collaborative development of the master branch (develop) and multiple slave branches (feature). Each slave branch corresponds to different development requirements.
  • the merge request (Merge Request, MR ) merges the slave branch into the master branch, thereby generating an application (Application, App) to be released.
  • the incremental problems generated from the creation of the slave branch to the merge into the master branch are obtained based on compiling intermediate products and analyzing and checking.
  • the intermediate product is the product after the source code has been optimized such as desugarization and cannot be associated with the source code. Based on the compilation of the intermediate product and analysis and inspection, the source code detection cannot be covered and the detected problems cannot be accurately traced and located.
  • At least one embodiment of the present disclosure provides a method, apparatus, electronic device, and storage medium for acquiring incremental source code.
  • an embodiment of the present disclosure proposes a method for acquiring incremental source code, the method comprising:
  • the basic submission identifier of the main warehouse code, and the main warehouse code inspection submission identifier determine the main warehouse inspection submission source code and the incremental information of the main warehouse inspection submission source code; and based on the component change information, Determine the component check submitted source code and the incremental information of the component check submitted source code;
  • the main warehouse checks and submits the source code
  • the main warehouse checks and submits the incremental information of the source code
  • the component checks and submits the source code
  • the component checks and submits the source code incremental information as incremental source code files.
  • an embodiment of the present disclosure further provides an incremental source code acquisition device, the device comprising:
  • the acquisition unit is used to respond to the code combination request, obtain the warehouse address of the main warehouse associated with the code combination request, the main warehouse code base submission identification and the main warehouse code inspection submission identification, and based on the main warehouse code basis submit the identification and the main warehouse code.
  • the warehouse code checks the submission identifier, and determines the component change information of the component that the main warehouse depends on;
  • the determining unit is used to determine the main warehouse inspection and submission source code and the incremental information of the main warehouse inspection and submission source code based on the warehouse address of the main warehouse, the main warehouse code base submission identification and the main warehouse code inspection submission identification; Describe the component change information, determine the component check submitted source code and the incremental information of the component check submitted source code;
  • the packaging unit is configured to package the source code submitted by the main warehouse inspection, the incremental information of the source code submitted by the main warehouse inspection, the source code submitted by the component inspection, and the incremental information of the source code submitted by the component inspection as an incremental source code file.
  • an embodiment of the present disclosure further provides an electronic device, including: a processor and a memory; the processor is configured to execute the method described in any embodiment of the first aspect by invoking a program or an instruction stored in the memory. The steps of the incremental source code acquisition method.
  • an embodiment of the present disclosure further provides a non-transitory computer-readable storage medium, where the non-transitory computer-readable storage medium stores a program or an instruction, and the program or instruction causes a computer to execute any one of the first aspect.
  • the component change information of the component that the main warehouse depends on can be determined; Then it can be determined that the main warehouse checks the submitted source code, the main warehouse checks the incremental information of the submitted source code, the component checks the submitted source code, and the component checks the incremental information of the submitted source code; thus, these information are packaged to obtain the incremental source code file. It does not undergo optimization such as desugaring and can be associated with source code. Therefore, incremental source code file analysis is used to detect incremental problems involved in a code combination request, which can cover source code detection, and the detected problems can be accurately traced and located, preventing problematic code from being merged. Join the master branch to avoid problems being brought online.
  • Fig. 1 is a kind of schematic diagram of multi-branch collaborative development
  • Fig. 2 is a kind of schematic diagram of analysis and inspection based on compilation intermediate product
  • FIG. 3 is an exemplary flowchart of a method for acquiring incremental source code provided by an embodiment of the present disclosure
  • Figure 4 is a schematic diagram of a diff (differential) result
  • FIG. 5 is an exemplary flowchart of determining component change information under an Android system provided by an embodiment of the present disclosure
  • Fig. 6 is a kind of schematic diagram of the component dependency tree information of main warehouse
  • FIG. 7 is an exemplary flowchart of determining component change information under an iOS system provided by an embodiment of the present disclosure
  • FIG. 8 is a schematic diagram of a source code diff process of a main warehouse provided by an embodiment of the present disclosure
  • FIG. 9 is a schematic diagram of a source code diff process for updating components provided by an embodiment of the present disclosure.
  • FIG. 10 is a schematic flowchart of obtaining the source code of the update component from the source code of all components in the warehouse where the update component is located under an Android system provided by an embodiment of the present disclosure
  • 11 is a schematic flowchart of obtaining the source code of the update component from the source code of all the components in the warehouse where the update component is located under an iOS system provided by an embodiment of the present disclosure
  • FIG. 12 is a schematic diagram of a source code diff process for newly added components provided by an embodiment of the present disclosure
  • FIG. 13 is an exemplary block diagram of a device for obtaining incremental source code provided by an embodiment of the present disclosure
  • FIG. 14 is an exemplary block diagram of an electronic device provided by an embodiment of the present disclosure.
  • git a free and open source source distributed version control tool
  • the main operations of git are Push (code submission) and MR (Merge Request, combined code request).
  • git supports multi-branch development.
  • a project often has a master branch (develop) and multiple slave branches ( feature) and many other branches are used for multi-person collaborative development.
  • Figure 1 is a schematic diagram of a multi-branch collaborative development.
  • the development of new requirements often pulls a new feature branch from the develop branch.
  • new requirements When the new requirements are developed and tested in the feature branch, they will be merged into the develop branch again through MR.
  • base commit can be understood as the code base commit identifier
  • review commit can be understood as the code check commit identifier.
  • Commit can be understood as a commit identifier.
  • commit When developers use the code version control system, each time they submit code to the code repository, the system will generate a commit record information called commit.
  • the MR is usually associated with a main warehouse.
  • the main warehouse can be understood as the main project of the app, which can be directly built to generate the app released to the outside world.
  • the main warehouse can rely on components (including one-party components and/or two-party components) through maven coordinates.
  • a component can be understood as a module in a library project, and a library project can include multiple modules (possibly mixed Android system components, iOS system components) ), each module corresponds to a component.
  • the first component can be understood as the component developed for this project
  • the second component can be understood as the component developed by other projects, and the source code of the first component and the second component can be obtained directly.
  • MR can be associated with one or more sub-warehouses, or not associated with sub-warehouses.
  • Sub-warehouses can be understood as sub-warehouses that the main warehouse directly relies on through engineering or source code.
  • Figure 2 is a schematic diagram of analysis and inspection based on compiling intermediate products.
  • base commit the node that pulls the feature1 branch will be triggered at the same time (hereinafter collectively referred to as "base commit").
  • node and the nodes to be merged into the develop branch are separately built and packaged, and then the two nodes analyze and check the compilation intermediate products in their respective build and packaging processes, record problems, and build and package
  • the source code corresponding to the compiling intermediate product has undergone a series of optimization processes such as desugarization during the construction and packaging process, not only the original information such as syntactic sugar and precise line numbers involved in the source code file cannot be restored, but also the source code file comment contains the original information. License (license) and other information are also lost. Therefore, the analysis and inspection based on the compilation intermediate product cannot cover the source code inspection.
  • the problems obtained through analysis and inspection based on the compiled intermediate product cannot be directly related to the code repository, component target, source code file, and the number of lines where the problem is located, that is, the detected problem cannot be accurately traced and located.
  • the embodiments of the present disclosure provide an incremental source code acquisition method, device, electronic device, and storage medium, by obtaining the warehouse address of the main warehouse associated with the combined code request, the basic submission identifier of the main warehouse code, and the main warehouse code inspection submission identifier.
  • the incremental source code file analysis is used to detect the incremental problem involved in a combined code request, which can cover the source code detection and detection. The problem can be precisely traced and located.
  • FIG. 3 provides a method for acquiring incremental source code according to an embodiment of the present disclosure.
  • the incremental source code acquisition method may include but not limited to the following steps 301 to 304:
  • the Merge Request (MR) is submitted by the R&D personnel. Since the MR is associated with a main warehouse, the response MR can directly obtain the warehouse address of the main warehouse associated with the MR. For example, the warehouse address of the main warehouse is git (a free open source The source code distributed version control tool) warehouse address.
  • main warehouse code base commit identifier namely the main warehouse base commit
  • main warehouse code check submission identifier main warehouse review commit
  • the warehouse address of the main warehouse, the base commit of the main warehouse and the review commit of the main warehouse can be collectively referred to as the source code change information of an MR process, that is, the source code change information includes: the warehouse address of the main warehouse, the base commit of the main warehouse, and the review commit of the main warehouse.
  • the component change information of the components that the main warehouse depends on can be determined based on the base commit of the main warehouse and the review commit of the main warehouse.
  • the component change information includes component identification and version number.
  • the component identifier is the component ID, and since the component can be understood as a module in the library project, the component identifier can be the module ID.
  • the version number is the component version number, and can also be the module version number.
  • the main warehouse checks the submitted source code, it can be understood as the diff (differential) source file of the main warehouse.
  • the incremental information of the main warehouse checking and submitting the source code can be understood as the line number information of the main warehouse diff file obtained after diff processing and the source code corresponding to the line number information.
  • the component check submission source code can be understood as the diff (differential) source file of the component.
  • the incremental information of the source code submitted by the component inspection can be understood as the source code corresponding to the line number information of the component diff file and the line number information obtained by diff processing.
  • Fig. 4 is a schematic diagram of a diff (difference) result.
  • "-" indicates a deleted code
  • "+” indicates a newly added or updated code.
  • the line number information of the diff file only includes the line number information corresponding to "+”.
  • the incremental information for checking the submitted source code includes: line numbers 26 and 27, the source code corresponding to line number 26, and the source code corresponding to line number 27.
  • the line number information of the main warehouse diff file, the diff source file of the component and the line number information of the component diff file package these information, for example, into a zip (a data compression file format) package, This zip package is the incremental source file.
  • the incremental source code file analysis and detection of the incremental problems involved in an MR can cover the source code detection and the detected problems can be accurately traced to the source. For example, It is possible to determine which warehouse, which component, and which line of which file the problem originated from, reducing the cost of locating the problem to zero for developers.
  • analyzing and detecting the incremental source code files involved in each MR can prevent problematic codes from being merged into the main branch and prevent problems from being brought online.
  • FIG. 5 is an exemplary flowchart of determining component change information under an Android system provided by an embodiment of the present disclosure.
  • the flow shown in FIG. 5 is an implementation manner of step 302 in FIG. 1 .
  • the source code of the main warehouse base commit that is, the project source code of the main warehouse base commit.
  • the source code of the main warehouse review commit can be obtained (for example, downloaded), that is, the project source code of the main warehouse review commit.
  • the first component dependency tree information that is, the component dependency tree information corresponding to the main warehouse base commit, through the gradle tool (an open source tool for project automation construction).
  • the second component dependency tree information that is, the component dependency tree information corresponding to the main warehouse review commit, can be obtained through the gradle tool (an open source tool for automatic project construction).
  • FIG. 6 is a schematic diagram of the component dependency tree information of a main bin, and FIG. 6 shows the component dependency information of the direct dependency and transitive dependency of the main bin.
  • the component change information includes: component ID and version number.
  • the component lists corresponding to the two component dependency tree information can be obtained, and then the two component lists can be diff processed to obtain the maven coordinate set of the changed component.
  • the maven coordinates include groupId, artifactId, and version, and version is the version number.
  • groupid:artifactid is a key (key)
  • the component management module will use this key to store the git repository, component ID and other information of the project where the component is located when publishing the component. Therefore, according to the groupid and artifactid in the maven coordinates, in the Find the component ID and the warehouse address of the project where the component is located in the component management module.
  • the component management module is responsible for the release and upgrade of components, and records the corresponding relationship between the git repository, version number and commit of the project where the component is located.
  • the components that are not recorded in the component management module are third-party components, the third-party components have no source code, and the present disclosure does not consider the processing of the third-party components.
  • FIG. 7 is an exemplary flowchart for determining component change information under an iOS system according to an embodiment of the present disclosure.
  • the flow shown in FIG. 7 is an implementation manner of step 302 in FIG. 3 .
  • the first component version list includes the component name and version number.
  • the component ID can be determined based on the component name.
  • the second component version list includes the component name and version number.
  • the component ID can be determined based on the component name.
  • Incremental source code only needs to focus on new components and updated components.
  • the component change information includes updated component information and/or newly added component information.
  • the updated component information includes: a component identification (ie, a component ID), a version number before updating, and a version number after the component is updated.
  • the newly added component information includes: component identification (ie, component ID) and version number.
  • FIG. 8 is a schematic diagram of a source code diff process of a main bin provided by an embodiment of the present disclosure. The flow shown in FIG. 8 is an implementation manner of step 303 in FIG. 3 involving the main compartment.
  • the incremental information of the source code submitted by the main warehouse can be determined.
  • the incremental information includes the line number information of the main warehouse diff file obtained by diff processing and the source code corresponding to the line number information.
  • the main warehouse base commit and the main warehouse review commit can be directly diff processed, and the incremental information of the main warehouse inspection and submission source code can be obtained, and the incremental information includes the main warehouse diff file obtained by the diff processing. Line number information and the source code corresponding to the line number information.
  • the Android system it is necessary to obtain the base commit source code of the main warehouse through the git clone command based on the warehouse address of the main warehouse and the basic submission identifier of the main warehouse code (ie the main warehouse base commit); and then use the git diff command to
  • the main warehouse basically submits the source code and the main warehouse checks the submitted source code for difference (diff), and obtains the incremental information of the main warehouse check and submits the source code.
  • the incremental information includes the line number information of the main warehouse diff file obtained by diff processing and the corresponding line number information source code.
  • FIG. 9 is a schematic diagram of a source code diff process for an update component provided by an embodiment of the present disclosure.
  • the flow shown in FIG. 9 is an implementation manner of the components involved in step 303 in FIG. 3 .
  • the code base commit identifier of the update component that is, the base commit of the update component
  • the code checks the commit ID (ie, the review commit of the update component).
  • the warehouse where the update component is located includes the update component and other components. Based on the address of the warehouse where the update component is located and the review commit of the update component, the source code of all components in the warehouse can be obtained through the git clone command (which can be understood as checking the submitted source code, and review commit corresponding).
  • the source code of the update component that is, the diff source file of the update component, can be obtained from the source code of all components in the repository.
  • the incremental information of the source code of the update component can be determined.
  • the incremental information includes the line number information of the component diff file obtained by diff processing and the source code corresponding to the line number information.
  • the base commit of the update component and the review commit of the update component can be directly diff processed to obtain incremental information of the source code of the update component, and the incremental information includes the component diff file obtained by the diff processing Line number information and the source code corresponding to the line number information.
  • the base commit source code (referred to as the first source code) of all components in the warehouse needs to be obtained through the git clone command, and based on Update the address of the warehouse where the component is located and the review commit of the update component, and use the git clone command to obtain the checked and submitted source code of all components in the warehouse (referred to as the second source code); then use the git diff command to make a difference between the first source code and the second source code (diff), to obtain the incremental information of the check and submitted source code of the update component, the incremental information includes the line number information of the component diff file obtained by the diff process and the source code corresponding to the line number information.
  • FIG. 10 is a schematic flowchart of obtaining the source code of the update component from the source code of all the components in the warehouse where the update component is located under an Android system provided by an embodiment of the present disclosure.
  • the flow shown in FIG. 10 is an implementation manner in which step 902 in FIG. 9 involves obtaining the source code of the update component.
  • the component identifier (or module identifier) in the repository where the updated component is located is obtained through the component management module, and the custom task (task) of the gradle tool (an open source tool for project automation construction) is injected into the repository.
  • the source code of the update component can be obtained according to the following process, including steps 1005 to 1007 not shown in FIG. 10 :
  • the address of the repository where the update component is located is used as the address (ie the path) of the source code of the update component.
  • FIG. 11 is a schematic flowchart of obtaining the source code of the update component from the source code of all components in the warehouse where the update component is located under the iOS system according to an embodiment of the present disclosure.
  • the flow shown in FIG. 11 is an implementation manner in which step 902 in FIG. 9 involves obtaining the source code of the update component.
  • the address of the warehouse where the update component is located and the component identifier (ie, the module identifier, such as "A") of the update component are obtained through the component management module. Further, the component configuration file (.podspec file) corresponding to the component identifier can be searched in the warehouse, for example, the A.podspec file corresponding to A can be searched.
  • the source configuration information is .source_files, which points to the source file. For example, A's .source_files can be found in the A.podspec file.
  • the source files related to the update component can be filtered out from the warehouse, and the source code of the update component can be obtained.
  • the relative path of each component in the warehouse may also be recorded when the component is released in the component management module, which can further improve the efficiency of acquiring incremental source code.
  • FIG. 12 is a schematic diagram of a source code diff process for a newly added component provided by an embodiment of the present disclosure.
  • the flow shown in FIG. 12 is an implementation manner of the components involved in step 303 in FIG. 3 .
  • the warehouse where the new component is located includes the new component and other components. Based on the address of the warehouse where the new component is located and the review commit of the new component, the source code of all components in the warehouse can be obtained through the git clone command.
  • the source code of the new component that is, the diff source file of the new component, can be obtained from the source code of all the components in the repository.
  • the incremental information of the source code of the new component is essentially all the line number information in the source code of the new component.
  • the combined code request may also be associated with one or more sub-warehouses.
  • the incremental source code acquisition method may also include the following steps 1 and 2:
  • Step 1 Respond to the code combination request, and obtain the warehouse address of the sub-warehouse associated with the code-combination request, the sub-warehouse code base commit identifier (that is, the sub-warehouse base commit), and the sub-warehouse code review commit flag (that is, the sub-warehouse review commit).
  • Step 2 Based on the warehouse address of the sub-warehouse, the basic submission identifier of the sub-warehouse code, and the submission flag of the sub-warehouse code check, determine the incremental information of the source code of the check-and-submit of the sub-warehouse and the source code of the check-off of the sub-warehouse.
  • the main warehouse checks the submitted source code
  • the main warehouse checks the incremental information of the submitted source code
  • the sub-warehouse checks the submitted source code
  • the sub-warehouse checks the incremental information of the submitted source code
  • the component checks the submitted source code
  • the component checks the incremental information of the submitted source code. For incremental source files.
  • step 1 and step 2 For the specific process of step 1 and step 2, reference may be made to the embodiment related to the main compartment, and to avoid repetition, details are not repeated here.
  • FIG. 13 is an exemplary block diagram of an apparatus for obtaining incremental source code according to an embodiment of the present disclosure.
  • the means for obtaining incremental source code may include, but is not limited to: an obtaining unit 131 , a determining unit 132 and a packaging unit 133
  • the obtaining unit 131 is used to respond to the code combination request, obtain the warehouse address of the main warehouse associated with the code combination request, the main warehouse code base submission identification and the main warehouse code inspection submission identification, and based on the main warehouse code basis submission identification and main warehouse code inspection Commit identifier to determine the component change information of the component that the main warehouse depends on.
  • the determining unit 132 is used for determining the main warehouse checking and submitting source code and the incremental information of the main warehouse checking and submitting source code based on the warehouse address of the main warehouse, the main warehouse code base submission identification and the main warehouse code checking submission identification; and based on the component change information, Determine the incremental information of the component check submitted source code and the component check submitted source code.
  • the packaging unit 133 is configured to package the main warehouse checking and submitting source code, the main warehouse checking and submitting source code incremental information, the component checking and submitting source code, and the component checking and submitting source code increment information into incremental source code files.
  • the obtaining unit 131 determines the component change information of the components on which the main warehouse depends, including:
  • the component change information is determined based on the first component dependency tree information and the second component dependency tree information.
  • the obtaining unit 131 determines the component change information of the components on which the main warehouse depends, including:
  • the component change information is determined based on the first component version list and the second component version list.
  • the component change information includes updated component information and/or newly added component information
  • the updated component information includes: component identification, version number before update and version number after component update;
  • the new component information includes: component ID and version number.
  • the determining unit 132 determines, based on the warehouse address of the main warehouse, the main warehouse code base submission identifier, and the main warehouse code inspection submission identifier, to determine the main warehouse inspection and submission source code and the incremental information of the main warehouse inspection and submission source code including:
  • the determining unit 132 determines the incremental information of the main warehouse check and submitted source code based on the main warehouse code base submission identifier and the main warehouse code check submission identifier, including:
  • the source code submitted by the main warehouse and the source code submitted by the main warehouse inspection Differentiate the source code submitted by the main warehouse and the source code submitted by the main warehouse inspection to obtain the incremental information of the source code submitted by the main warehouse inspection, wherein the incremental information includes the line number information and the source code corresponding to the line number information.
  • the determining unit 132 determines, based on the component change information, that the component check submitted source code and the incremental information of the component check submitted source code include:
  • the version number before the update and the version number after the component update obtain the address of the warehouse where the update component is located, the code base submission identifier of the update component, and the code check submission identifier of the update component;
  • the incremental information of the source code of the update component is determined.
  • the determining unit 132 obtains the source code of the update component from the source code of all the components in the repository, including:
  • the determining unit 132 obtains the source code of the update component from the source code of all the components in the repository, including:
  • the source code of the update component is obtained from the source code of all components in the repository.
  • the determining unit 132 is based on the code base submission identifier of the update component and the code check submission identifier of the update component, and determining the incremental information of the component check submission source code of the update component includes:
  • Differences between the first source code and the second source code are performed to obtain incremental information of the component that updates the component to check and submit the source code, where the incremental information includes line number information and source code corresponding to the line number information.
  • the determining unit 132 determines, based on the component change information, that the component check submitted source code and the incremental information of the component check submitted source code include:
  • the incremental information of the source code of the new component is determined.
  • the code combination request is also associated with a sub-warehouse
  • the obtaining unit 131 is further configured to: in response to the code combination request, obtain the warehouse address of the sub-warehouse, the sub-warehouse code base submission identifier and the sub-warehouse code check submission flag associated with the code combination request ;
  • the determining unit 132 is further configured to determine the incremental information of the sub-silo inspection and submission source code and the sub-silo inspection and submission source code based on the sub-silo's warehouse address, the sub-silo code base submission identifier and the sub-silo code inspection submission identifier;
  • the packaging unit 133 is configured to check and submit the source code of the main warehouse, the incremental information of the main warehouse to check the submitted source code, the sub-silo to check the submitted source code, the sub-silo to check the incremental information of the submitted source code, the component to check the submitted source code, and the component to check the increment of the submitted source code.
  • Information is packaged as incremental source files.
  • each unit in the incremental source code acquisition apparatus is only a logical function division, and other division methods may be used in actual implementation.
  • at least two units of each unit in the incremental source code acquisition apparatus may be Implemented as one unit; each unit in the incremental source code acquisition device can also be divided into multiple subunits.
  • each unit or sub-unit can be implemented by electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art may use different methods for implementing the described functionality for each particular application.
  • FIG. 14 is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure.
  • the electronic device includes: at least one processor 1401 , at least one memory 1402 and at least one communication interface 1403 .
  • the various components in the electronic device are coupled together by a bus system 1404 .
  • the communication interface 1403 is used for information transmission with external devices. Understandably, the bus system 1404 is used to implement connection communication between these components.
  • the bus system 1404 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the various buses are labeled as bus system 1404 in FIG. 14 .
  • the memory 1402 in this embodiment may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memory.
  • memory 1402 stores the following elements, executable units or data structures, or subsets thereof, or extended sets of them: operating systems and applications.
  • the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic tasks and processing hardware-based tasks.
  • Applications including various applications, such as media players (Media Player), browsers (Browser), etc., are used to implement various application tasks.
  • a program for implementing the incremental source code acquisition method provided by the embodiment of the present disclosure may be included in an application program.
  • the processor 1401 calls the program or instruction stored in the memory 1402, specifically, the program or instruction stored in the application program, and the processor 401 is configured to execute the incremental source code acquisition provided by the embodiment of the present disclosure Steps of various embodiments of the method.
  • the incremental source code acquisition method provided by the embodiment of the present disclosure may be applied to the processor 1401 or implemented by the processor 1401 .
  • the processor 1401 may be an integrated circuit chip with signal processing capability. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor 1401 or the instructions in the form of software.
  • the above-mentioned processor 1401 can be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), a ready-made programmable gate array (Field Programmable Gate Array, FPGA) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.
  • a general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
  • the steps of the incremental source code acquisition method provided by the embodiment of the present disclosure may be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor.
  • the software unit may be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other storage media mature in the art.
  • the storage medium is located in the memory 1402, and the processor 1401 reads the information in the memory 1402 and completes the steps of the method in combination with its hardware.
  • Embodiments of the present disclosure further provide a non-transitory computer-readable storage medium, where the non-transitory computer-readable storage medium stores programs or instructions, and the programs or instructions cause a computer to execute the methods of each embodiment of the incremental source code acquisition method. Steps, in order to avoid repeated descriptions, are not repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开实施例涉及一种增量源码获取方法、装置、电子设备及存储介质。本公开的至少一个实施例中，通过获取合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，可以确定主仓所依赖组件的组件变更信息；进而可以确定主仓检查提交源码、主仓检查提交源码的增量信息、组件检查提交源码以及组件检查提交源码的增量信息；从而将这些信息进行打包，得到增量源码文件，由于增量源码不经过脱糖等优化处理且可以关联源码，因此利用增量源码文件分析检测一次合码请求涉及的增量问题，可以覆盖源码检测且检出的问题可以精准溯源定位，阻止存在问题的代码合入主分支，避免问题被带到线上。

Description

一种增量源码获取方法、装置、电子设备及存储介质
相关申请的交叉引用
本申请要求于2021年04月21日提交的，申请号为202110429067.7、发明名称为“一种增量源码获取方法、装置、电子设备及存储介质”的中国专利申请的优先权，该申请的全部内容通过引用结合在本申请中。
技术领域
本公开实施例涉及计算机技术领域，具体涉及一种增量源码获取方法、装置、电子设备及存储介质。
背景技术
目前工程源码开发过程中包括主分支(develop)和多个从分支(feature)的协同开发，每个从分支对应不同的开发需求，在从分支完成开发后，通过合码请求(Merge Request，MR)将从分支合入主分支，进而生成待发布的应用程序(Application，App)。
为了查找从分支由创建到合入主分支过程中产生的增量问题，目前基于编译中间产物并进行分析检查，得到从分支由创建到合入主分支过程中产生的增量问题。
但是，中间产物是源码经过脱糖等优化处理后的产物且无法关联源码，进而基于编译中间产物并进行分析检查，无法覆盖源码检测且检出的问题无法精准溯源定位。
发明内容
为了解决现有技术存在的至少一个问题，本公开的至少一个实施例提供了一种增量源码获取方法、装置、电子设备及存储介质。
第一方面，本公开实施例提出一种增量源码获取方法，所述方法包括：
响应合码请求，获取所述合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识；
基于所述主仓代码基础提交标识和主仓代码检查提交标识，确定所述主仓所依赖组件的组件变更信息；
基于所述主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及所述主仓检查提交源码的增量信息；并基于所述组件变更信息，确定组件检查提交源码及所述组件检查提交源码的增量信息；
将所述主仓检查提交源码、所述主仓检查提交源码的增量信息、所述组件检查提交源 码和所述组件检查提交源码的增量信息打包为增量源码文件。
第二方面，本公开实施例还提出一种增量源码获取装置，所述装置包括：
获取单元，用于响应合码请求，获取所述合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，并基于所述主仓代码基础提交标识和主仓代码检查提交标识，确定所述主仓所依赖组件的组件变更信息；
确定单元，用于基于所述主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及所述主仓检查提交源码的增量信息；并基于所述组件变更信息，确定组件检查提交源码及所述组件检查提交源码的增量信息；
打包单元，用于将所述主仓检查提交源码、所述主仓检查提交源码的增量信息、所述组件检查提交源码和所述组件检查提交源码的增量信息打包为增量源码文件。
第三方面，本公开实施例还提出一种电子设备，包括：处理器和存储器；所述处理器通过调用所述存储器存储的程序或指令，用于执行如第一方面任一实施例所述增量源码获取方法的步骤。
第四方面，本公开实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如第一方面任一实施例所述增量源码获取方法的步骤。
可见，本公开的至少一个实施例中，通过获取合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，可以确定主仓所依赖组件的组件变更信息；进而可以确定主仓检查提交源码、主仓检查提交源码的增量信息、组件检查提交源码以及组件检查提交源码的增量信息；从而将这些信息进行打包，得到增量源码文件，由于增量源码不经过脱糖等优化处理且可以关联源码，因此利用增量源码文件分析检测一次合码请求涉及的增量问题，可以覆盖源码检测且检出的问题可以精准溯源定位，阻止存在问题的代码合入主分支，避免问题被带到线上。
附图说明
为了更清楚地说明本公开实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是一种多分支协同开发的示意图；
图2是一种基于编译中间产物进行分析检查示意图；
图3是本公开实施例提供的一种增量源码获取方法的示例性流程图；
图4是一种diff(差分)结果示意图；
图5是本公开实施例提供的一种安卓系统下确定组件变更信息的示例性流程图；
图6是一种主仓的组件依赖树信息示意图；
图7是本公开实施例提供的一种iOS系统下确定组件变更信息的示例性流程图；
图8是本公开实施例提供的一种主仓的源码diff流程示意图；
图9是本公开实施例提供的一种针对更新组件的源码diff流程示意图；
图10是本公开实施例提供的一种安卓系统下从更新组件所在仓库的所有组件的源码中获取更新组件的源码的流程示意图；
图11是本公开实施例提供的一种iOS系统下从更新组件所在仓库的所有组件的源码中获取更新组件的源码的流程示意图；
图12是本公开实施例提供的一种针对新增组件的源码diff流程示意图；
图13是本公开实施例提供的一种增量源码获取装置的示例性框图；
图14是本公开实施例提供的一种电子设备的示例性框图。
具体实施方式
为了能够更清楚地理解本公开的上述目的、特征和优点，下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。基于所描述的本公开的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本公开保护的范围。
需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
随着互联网技术的高速发展、国内外用户隐私数据相关法律法规日趋完善，用户隐私数据安全意识也在逐步提升，移动应用上线后出现隐私数据安全等问题的风险也越发不可控。在此背景下，需要在应用程序(application，app)发布前检测分析app存在的问题，以降低安全风险。
目前采用git(一款免费开源的源码分布式版本控制工具)对工程源码进行版本控制管理。从git仓库的视角，git的主要操作有Push(代码提交)和MR(Merge Request，合码请求)，同时git支持多分支开发，一个工程往往会有主分支(develop)和多个从分支(feature)等诸多分支用于多人协同开发。
图1是一种多分支协同开发的示意图，新需求的开发往往会从develop分支拉出一个新的feature分支，当新需求在feature分支完成开发测试后会通过MR再次合入develop分支。 在图1中，base commit可以理解为代码基础提交标识，review commit可以理解为代码检查提交标识。
commit可以理解为提交标识，在开发人员使用代码版本控制系统过程中，每次向代码仓库提交代码时，系统会生成一条提交记录信息，称为commit。
MR通常关联一个主仓，主仓可以理解为app主工程，可直接构建生成对外发布的app。主仓可以通过maven坐标依赖组件(包括一方组件和/或二方组件)，组件可以理解为库工程中的一个模块，一个库工程中可以包括多个模块(可能混合Android系统组件、iOS系统组件)，每个模块对应一个组件。其中，一方组件可以理解为本工程开发的组件，二方组件可以理解为其他项目开发的组件，一方组件和二方组件的源码可直接获取。
MR可以关联一个或多个子仓，也可以不关联子仓，子仓可以理解为主仓直接通过工程依赖或源码依赖的子仓。
若改变了主仓或子仓中的代码或者更新了主仓或子仓所依赖组件的信息，就能改变app的功能。而这些改变可能会带有安全问题或bug，因此需要对每一次MR过程中的代码变动进行各项检查、避免安全等问题被带到线上引发应用安全合规等各种风险。
对一个从分支由创建到合入主分支过程(即一次MR过程)中新增的代码进行各项检查，目前基于编译中间产物(通过gradle工具(一种项目自动化构建开源工具)的transform技术拿到编译涉及的所有jar(java archive，一种软件包文件格式)包及class字节码)对字节码使用ASM(一种Java字节码操控框架)进行全量扫描，获取全量问题，如需增量结果则对两个不同版本的全量结果进行差分。
图2是一种基于编译中间产物进行分析检查示意图，在图2中，当feature1分支完成开发测试、准备合入develop分支时，首先会同时触发拉出feature1分支的节点(下文统称为“base commit”节点)和待合入develop分支的节点(下文统称为“review commit”节点)分别进行构建打包，然后两个节点在各自的构建打包过程中分别对编译中间产物进行分析检查并记录问题，构建打包结束即可分别得到图示中的“初始全量问题”和“当前全量问题”，接着再对“初始全量问题”和“当前全量问题”进行diff(差分)，即可得到feature1分支从创建到合入develop分支之间的增量问题，最后对存在增量问题的MR进行管控，阻止该feature1分支代码合入develop分支，直到该feature1分支开发者修复所有增量问题或者对无需修改的增量问题进行报备、审批通过后方可合入。
由于编译中间产物对应的源码，在构建打包过程中已经经过脱糖等一系列优化处理，不仅源码文件中涉及的语法糖、精准行号等原始信息均已无法还原，而且源码文件注释中包含的License(许可)等信息也都丢失。因此，基于编译中间产物进行分析检查，无法覆盖源码检测。
另外，由于中间产物无法关联源码，因此基于编译中间产物进行分析检查得到的问题无法直接与代码仓库、组件目标、源码文件、问题所在行数精准关联，也即检出的问题无法精准溯源定位。
为此，本公开实施例提供一种增量源码获取方法、装置、电子设备及存储介质，通过获取合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，可以确定主仓所依赖组件的组件变更信息；进而可以确定主仓检查提交源码、主仓检查提交源码的增量信息、组件检查提交源码以及组件检查提交源码的增量信息；从而将这些信息进行打包，得到增量源码文件，由于增量源码不经过脱糖等优化处理且可以关联源码，因此利用增量源码文件分析检测一次合码请求涉及的增量问题，可以覆盖源码检测且检出的问题可以精准溯源定位。
图3为本公开实施例提供的一种增量源码获取方法。如图3所示，增量源码获取方法可包括但不限于以下步骤301至304：
301、响应合码请求，获取合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识。
合码请求(Merge Request，MR)由研发人员提交，由于MR关联一个主仓，因此，响应MR可以直接获取MR关联的主仓的仓库地址，主仓的仓库地址例如为git(一款免费开源的源码分布式版本控制工具)仓库地址。
响应MR还可以直接获取主仓代码基础提交标识(即主仓base commit)以及主仓代码检查提交标识(主仓review commit)。
主仓的仓库地址、主仓base commit和主仓review commit可以统称为一次MR过程的源码变更信息，也即源码变更信息包括：主仓的仓库地址、主仓base commit和主仓review commit。
302、基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓所依赖组件的组件变更信息。
在获取主仓base commit和主仓review commit后，可以基于主仓base commit和主仓review commi，确定主仓所依赖组件的组件变更信息。其中，组件变更信息包括组件标识和版本号。
组件标识即组件ID，又由于组件可以理解为库工程中的一个模块，因此组件标识可以为模块ID。版本号为组件版本号，也可以为模块版本号。
303、基于主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及主仓检查提交源码的增量信息；并基于组件变更信息，确定组件检查提交源码及组件检查提交源码的增量信息。
主仓检查提交源码可以理解为主仓的diff(差分)源文件。
主仓检查提交源码的增量信息可以理解为经过diff处理得到的主仓diff文件行号信息和行号信息对应的源码。diff处理为git工具提供的一种功能。
组件检查提交源码可以理解为组件的diff(差分)源文件。
组件检查提交源码的增量信息可以理解为经过diff处理得到的组件diff文件行号信息和行号信息对应的源码。
例如，图4为一种diff(差分)结果示意图，在图4中，“-”表示被删除的代码，“+”表示新增或更新后的代码。diff文件行号信息仅包括“+”对应的行号信息。检查提交源码的增量信息包括：行号26和27、行号26对应的源码和行号27对应的源码。
304、将主仓检查提交源码、主仓检查提交源码的增量信息、组件检查提交源码和组件检查提交源码的增量信息打包为增量源码文件。
在得到主仓的diff源文件、主仓diff文件行号信息、组件的diff源文件和组件diff文件行号信息，将这些信息进行打包，例如打包为zip(一种数据压缩文件格式)包，这个zip包即为增量源码文件。
因此，由于增量源码不经过脱糖等优化处理且可以关联源码，因此利用增量源码文件分析检测一次MR涉及的增量问题，可以覆盖源码检测且检出的问题可以精准溯源定位，例如，可以确定问题源自哪个仓库、哪个组件、哪个文件的哪一行，将研发人员定位问题的成本降至零。
另外，对每一次MR涉及的增量源码文件进行分析检测，可以阻止存在问题的代码合入主分支，避免问题被带到线上。
图5是本公开实施例提供的一种安卓系统下确定组件变更信息的示例性流程图。图5所示的流程为图1中步骤302的一种实现方式。
501、基于主仓的仓库地址和主仓代码基础提交标识，获取主仓基础提交源码。
基于主仓的仓库地址和主仓base commit，可以获取(例如下载)主仓基础提交源码，也即主仓base commit的工程源码。
502、基于主仓的仓库地址和主仓代码检查提交标识，获取主仓检查提交源码。
基于主仓的仓库地址和主仓review commit，可以获取(例如下载)主仓检查提交源码，也即主仓review commit的工程源码。
503、基于主仓基础提交源码获取第一组件依赖树信息，并基于主仓检查提交源码获取第二组件依赖树信息。
基于主仓base commit的工程源码，可以通过gradle工具(一种项目自动化构建开源工具)获取第一组件依赖树信息，也即主仓base commit对应的组件依赖树信息。
基于主仓review commit的工程源码，可以通过gradle工具(一种项目自动化构建开源工具)获取第二组件依赖树信息，也即主仓review commit对应的组件依赖树信息。
例如，图6是一种主仓的组件依赖树信息示意图，在图6中示出了主仓直接依赖与传递依赖的组件依赖信息。
504、基于第一组件依赖树信息和第二组件依赖树信息确定组件变更信息。其中，组件变更信息包括：组件ID和版本号。
本实施例中，解析这两个组件依赖树信息，可以得到这两个组件依赖树信息分别对应的组件列表，进而可以对这两个组件列表进行diff处理，得到有变更的组件的maven坐标集合，其中，maven坐标包括groupId、artifactId和version三种信息，version即为版本号。
在确定有变更的组件的maven坐标集合后，可以根据maven坐标中的groupid和artifactid确定组件ID和组件所在的仓库地址，具体地：
“groupid:artifactid”是一个key(键)，组件管理模块在发布组件时会以这个key存储这个组件所在工程的git仓库、组件ID等信息，因此，可根据maven坐标中的groupid和artifactid，在组件管理模块中查找组件ID和组件所在工程的仓库地址。
需要说明的是，组件管理模块负责组件的发布、升级，会记录组件所在工程的git仓库、版本号与commit的对应关系。组件管理模块没有记录的组件为三方组件，三方组件无源码，本公开不考虑对三方组件的处理。
图7是本公开实施例提供的一种iOS系统下确定组件变更信息的示例性流程图。图7所示的流程为图3中步骤302的一种实现方式。
701、基于主仓代码基础提交标识获取第一组件版本列表。
在获取主仓base commit后，可以下载工程源码、通过解析podfile(组件依赖配置文件)可以获取主仓base commit对应的第一组件版本列表，第一组件版本列表中包括组件名称和版本号。基于组件名称可以确定组件ID。
702、基于主仓代码检查提交标识获取第二组件版本列表。
在获取主仓review commit后，可以下载工程源码、通过解析podfile(组件依赖配置文件)可以获取主仓review commit对应的第二组件版本列表，第二组件版本列表中包括组件名称和版本号。基于组件名称可以确定组件ID。
703、基于第一组件版本列表和第二组件版本列表确定组件变更信息。
由于两个组件版本列表中均包括组件名称和版本号，因此，可以对这两个组件版本列表进行diff处理，得到组件变更信息。需要说明的是，iOS系统中没有maven坐标的概念，iOS中组件名称等价于maven坐标中的groupid和artifactid构成的key，即“groupid：artifactid”。
需要说明的是，组件变更存在新增组件、更新组件和删除组件，增量源码只需关注新增组件和更新组件。
在一些实施例中，组件变更信息包括更新组件信息和/或新增组件信息。
更新组件信息包括：组件标识(即组件ID)、更新前的版本号和组件更新后的版本号。
新增组件信息包括：组件标识(即组件ID)和版本号。
在一些实施例中，获取主仓的源码变更信息(包括：主仓的仓库地址、主仓base commit和主仓review commit)之后，可通过主仓的源码diff流程来获取主仓的diff源文件及主仓diff文件行号信息和行号信息对应的源码。图8是本公开实施例提供的一种主仓的源码diff流程示意图。图8所示的流程为图3中步骤303涉及主仓的一种实现方式。
801、基于主仓的仓库地址和主仓代码检查提交标识，获取主仓检查提交源码。
基于主仓的仓库地址和主仓review commit，可以通过git clone命令获取主仓检查提交源码，即主仓的diff源文件。
802、基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码的增量信息。
基于主仓base commit和主仓review commit，可以确定主仓检查提交源码的增量信息，增量信息包括经过diff处理得到的主仓diff文件行号信息和行号信息对应的源码。
在一些实施例中，对于iOS系统，可以直接对主仓base commit和主仓review commit进行diff处理，得到主仓检查提交源码的增量信息，增量信息包括经过diff处理得到的主仓diff文件行号信息和行号信息对应的源码。
在另一些实施例中，对于安卓系统，需要基于主仓的仓库地址和主仓代码基础提交标识(即主仓base commit)，通过git clone命令获取主仓基础提交源码；进而通过git diff命令对主仓基础提交源码和主仓检查提交源码进行差分(diff)，得到主仓检查提交源码的增量信息，增量信息包括经过diff处理得到的主仓diff文件行号信息和行号信息对应的源码。
图9是本公开实施例提供的一种针对更新组件的源码diff流程示意图。图9所示的流程为图3中步骤303涉及组件的一种实现方式。
901、基于更新组件信息中的组件标识、更新前的版本号和组件更新后的版本号，获取更新组件所在仓库的地址、更新组件的代码基础提交标识和更新组件的代码检查提交标识。
基于更新组件信息中的组件ID、更新前的版本号和组件更新后的版本号，可以获取更新组件所在仓库的地址、更新组件的代码基础提交标识(即更新组件的base commit)和更新组件的代码检查提交标识(即更新组件的review commit)。
902、基于更新组件所在仓库的地址和更新组件的代码检查提交标识，获取该仓库中所有组件的源码；并从该仓库中所有组件的源码中获取更新组件的源码。
更新组件所在仓库中包括该更新组件和其他组件，基于更新组件所在仓库的地址和更新组件的review commit，可以通过git clone命令获取该仓库中所有组件的源码(可以理解为检查提交源码，与review commit相对应)。从该仓库中所有组件的源码中可以获取更新组件的源码，也即更新组件的diff源文件。
903、基于更新组件的代码基础提交标识和更新组件的代码检查提交标识，确定更新组件的源码的增量信息。
基于更新组件的base commit和更新组件的review commit，可以确定更新组件的源码的增量信息，增量信息包括经过diff处理得到的组件diff文件行号信息和行号信息对应的源码。
在一些实施例中，对于iOS系统，可以直接对更新组件的base commit和更新组件的review commit进行diff处理，得到更新组件的源码的增量信息，增量信息包括经过diff处理得到的组件diff文件行号信息和行号信息对应的源码。
在另一些实施例中，对于安卓系统，需要基于更新组件所在仓库的地址和更新组件的base commit，通过git clone命令获取该仓库中所有组件的基础提交源码(记为第一源码)，并基于更新组件所在仓库的地址和更新组件的review commit，通过git clone命令获取该仓库中所有组件的检查提交源码(记为第二源码)；进而通过git diff命令对第一源码和第二源码进行差分(diff)，得到更新组件的检查提交源码的增量信息，增量信息包括经过diff处理得到的组件diff文件行号信息和行号信息对应的源码。
图10是本公开实施例提供的一种安卓系统下从更新组件所在仓库的所有组件的源码中获取更新组件的源码的流程示意图。图10所示的流程为图9中步骤902涉及获取更新组件的源码的一种实现方式。
1001、在该仓库中注入自定义任务，自定义任务用于获取该仓库中所有组件的组件标识和组件路径。
通过组件管理模块获取更新组件所在仓库中的组件标识(或模块标识)，通过将gradle工具(一种项目自动化构建开源工具)自定义任务(task)注入该仓库。
1002、执行自定义任务，得到该仓库中所有组件的组件标识和组件路径。
1003、基于该仓库中所有组件的组件标识和组件路径，查找与更新组件的组件标识对应的组件路径。
1004、基于更新组件的组件标识对应的组件路径，获取更新组件的源码。
在一些实施例中，若图10所示的流程未获取到更新组件的源码，则可以按以下流程获取更新组件的源码，包括图10中未示出的步骤1005至1007：
1005、获取更新组件所在仓库(可以理解为库工程或git工程)的配置文件(settings.gradle 或settings.gradle.kts)。
1006、解析配置文件，获取仓库中所有的组件标识(或模块标识)以及对应的相对路径，并基于更新组件的组件名称查找更新组件的相对路径；
1007、基于更新组件的相对路径得到更新组件的源码。
更进一步地，如果未查找到更新组件的相对路径，则以更新组件所在仓库的地址作为更新组件的源码的地址(即路径)。
图11是本公开实施例提供的一种iOS系统下从更新组件所在仓库的所有组件的源码中获取更新组件的源码的流程示意图。图11所示的流程为图9中步骤902涉及获取更新组件的源码的一种实现方式。
1101、基于更新组件的组件标识，在该仓库中查找与更新组件的组件标识对应的组件配置文件。
通过组件管理模块获取更新组件所在仓库的地址和更新组件的组件标识(即模块标识，如“A”)。进而可以在该仓库中查找组件标识对应的组件配置文件(.podspec文件)，例如查找A对应的A.podspec文件。
1102、从组件配置文件中查找更新组件的源码配置信息。
其中，源码配置信息为.source_files，该信息指向源文件。例如，从A.podspec文件中可以查找到A的.source_files。
1103、基于源码配置信息获得更新组件的源码的相对路径。
解析.source_files信息，可以获取更新组件相关的所有源码文件(即源文件)的相对路径。可以将相对路径保存到一个相对路径列表中。
1104、基于更新组件的源码的相对路径，从该仓库中所有组件的源码中获取更新组件的源码。
通过相对路径列表即可从仓库中将更新组件相关的源文件过滤出来，得到更新组件的源码。
在一些实施例中，还可以在组件管理模块中通过组件发布时记录每个组件在仓库中的相对路径，可以进一步提升获取增量源码的效率。
图12是本公开实施例提供的一种针对新增组件的源码diff流程示意图。图12所示的流程为图3中步骤303涉及组件的一种实现方式。
1201、基于新增组件信息中的组件标识和版本号，获取新增组件所在仓库的地址和新增组件的代码检查提交标识。
基于新增组件信息中的组件ID和版本号，可以获取新增组件所在仓库的地址和新增组件的代码检查提交标识(即新增组件的review commit)。
1202、基于新增组件所在仓库的地址和新增组件的代码检查提交标识，获取该仓库中所有组件的源码；并从该仓库中所有组件的源码中获取新增组件的源码。
新增组件所在仓库中包括该新增组件和其他组件，基于新增组件所在仓库的地址和新增组件的review commit，可以通过git clone命令获取该仓库中所有组件的源码。从该仓库中所有组件的源码中可以获取新增组件的源码，也即新增组件的diff源文件。
从该仓库中所有组件的源码中获取新增组件的源码可参考更新组件的源码获取的相关实施例的步骤，为避免重复，不再赘述。
1203、基于新增组件的源码中所有行号信息，确定新增组件的源码的增量信息。
由于新增组件没有base commit，因此，新增组件的源码的增量信息实质上是新增组件的源码中所有行号信息。
在一些实施例中，合码请求还可以关联一个或多个子仓，增量源码获取方法除了包括图3所示的步骤，还可以包括如下步骤1和2：
步骤1、响应合码请求，获取合码请求关联的子仓的仓库地址、子仓代码基础提交标识(即子仓base commit)和子仓代码检查提交标识(即子仓review commit)。
步骤2、基于子仓的仓库地址、子仓代码基础提交标识和子仓代码检查提交标识，确定子仓检查提交源码及子仓检查提交源码的增量信息。
相应地，将主仓检查提交源码、主仓检查提交源码的增量信息、子仓检查提交源码、子仓检查提交源码的增量信息、组件检查提交源码和组件检查提交源码的增量信息打包为增量源码文件。
步骤1和步骤2的具体过程可参考主仓相关的实施例，为避免重复，不再赘述。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员能够理解，本公开实施例并不受所描述的动作顺序的限制，因为依据本公开实施例，某些步骤可以采用其他顺序或者同时进行。另外，本领域技术人员能够理解，说明书中所描述的实施例均属于可选实施例。
图13为本公开实施例提供的一种增量源码获取装置的示例性框图。增量源码获取装置可以包括但不限于：获取单元131、确定单元132和打包单元133
获取单元131，用于响应合码请求，获取合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，并基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓所依赖组件的组件变更信息。
确定单元132，用于基于主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及主仓检查提交源码的增量信息；并基于组件变更信息，确定组件检查提交源码及组件检查提交源码的增量信息。
打包单元133，用于将主仓检查提交源码、主仓检查提交源码的增量信息、组件检查提交源码和组件检查提交源码的增量信息打包为增量源码文件。
在一些实施例中，获取单元131基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓所依赖组件的组件变更信息包括：
基于主仓的仓库地址和主仓代码基础提交标识，获取主仓基础提交源码；
基于主仓的仓库地址和主仓代码检查提交标识，获取主仓检查提交源码；
基于主仓基础提交源码获取第一组件依赖树信息；
基于主仓检查提交源码获取第二组件依赖树信息；
基于第一组件依赖树信息和第二组件依赖树信息确定组件变更信息。
在一些实施例中，获取单元131基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓所依赖组件的组件变更信息包括：
基于主仓代码基础提交标识获取第一组件版本列表；
基于主仓代码检查提交标识获取第二组件版本列表；
基于第一组件版本列表和第二组件版本列表确定组件变更信息。
在一些实施例中，组件变更信息包括更新组件信息和/或新增组件信息；
更新组件信息包括：组件标识、更新前的版本号和组件更新后的版本号；
新增组件信息包括：组件标识和版本号。
在一些实施例中，确定单元132基于主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及主仓检查提交源码的增量信息包括：
基于主仓的仓库地址和主仓代码检查提交标识，获取主仓检查提交源码；
基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码的增量信息。
在一些实施例中，确定单元132基于主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码的增量信息包括：
基于主仓的仓库地址和主仓代码基础提交标识，获取主仓基础提交源码；
将主仓基础提交源码和主仓检查提交源码进行差分，得到主仓检查提交源码的增量信息，其中，增量信息包括行号信息和行号信息对应的源码。
在一些实施例中，确定单元132基于组件变更信息，确定组件检查提交源码及组件检查提交源码的增量信息包括：
基于更新组件信息中的组件标识、更新前的版本号和组件更新后的版本号，获取更新组件所在仓库的地址、更新组件的代码基础提交标识和更新组件的代码检查提交标识；
基于更新组件所在仓库的地址和更新组件的代码检查提交标识，获取该仓库中所有组 件的源码；并从该仓库中所有组件的源码中获取更新组件的源码；
基于更新组件的代码基础提交标识和更新组件的代码检查提交标识，确定更新组件的源码的增量信息。
在一些实施例中，确定单元132从该仓库中所有组件的源码中获取更新组件的源码包括：
在该仓库中注入自定义任务，自定义任务用于获取该仓库中所有组件的组件标识和组件路径；
执行自定义任务，得到该仓库中所有组件的组件标识和组件路径；
基于该仓库中所有组件的组件标识和组件路径，查找与更新组件的组件标识对应的组件路径；
基于更新组件的组件标识对应的组件路径，获取更新组件的源码。
在一些实施例中，确定单元132从该仓库中所有组件的源码中获取更新组件的源码包括：
基于更新组件的组件标识，在该仓库中查找与更新组件的组件标识对应的组件配置文件；
从组件配置文件中查找更新组件的源码配置信息；
基于源码配置信息获得更新组件的源码的相对路径；
基于更新组件的源码的相对路径，从该仓库中所有组件的源码中获取更新组件的源码。
在一些实施例中，确定单元132基于更新组件的代码基础提交标识和更新组件的代码检查提交标识，确定更新组件的组件检查提交源码的增量信息包括：
基于更新组件所在仓库的地址和更新组件的代码基础提交标识，获取该仓库中所有组件的第一源码；并基于更新组件所在仓库的地址和更新组件的代码检查提交标识，获取该仓库中所有组件的第二源码；
将第一源码和第二源码进行差分，得到更新组件的组件检查提交源码的增量信息，增量信息包括行号信息和行号信息对应的源码。
在一些实施例中，确定单元132基于组件变更信息，确定组件检查提交源码及组件检查提交源码的增量信息包括：
基于新增组件信息中的组件标识和版本号，获取新增组件所在仓库的地址和新增组件的代码检查提交标识；
基于新增组件所在仓库的地址和新增组件的代码检查提交标识，获取该仓库中所有组件的源码；并从该仓库中所有组件的源码中获取新增组件的源码；
基于新增组件的源码中所有行号信息，确定新增组件的源码的增量信息。
在一些实施例中，合码请求还关联子仓，获取单元131还用于：响应合码请求，获取合码请求关联的子仓的仓库地址、子仓代码基础提交标识和子仓代码检查提交标识；
确定单元132还用于基于子仓的仓库地址、子仓代码基础提交标识和子仓代码检查提交标识，确定子仓检查提交源码及子仓检查提交源码的增量信息；
打包单元133用于将主仓检查提交源码、主仓检查提交源码的增量信息、子仓检查提交源码、子仓检查提交源码的增量信息、组件检查提交源码和组件检查提交源码的增量信息打包为增量源码文件。
在一些实施例中，增量源码获取装置中各单元的划分仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如增量源码获取装置中各单元中的至少两个单元可以实现为一个单元；增量源码获取装置中各单元也可以划分为多个子单元。可以理解的是，各个单元或子单元能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。
图14是本公开实施例提供的一种电子设备的结构示意图。如图14所示，电子设备包括：至少一个处理器1401、至少一个存储器1402和至少一个通信接口1403。电子设备中的各个组件通过总线系统1404耦合在一起。通信接口1403，用于与外部设备之间的信息传输。可理解地，总线系统1404用于实现这些组件之间的连接通信。总线系统1404除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但为了清楚说明起见，在图14中将各种总线都标为总线系统1404。
可以理解，本实施例中的存储器1402可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。
在一些实施方式中，存储器1402存储了如下的元素，可执行单元或者数据结构，或者他们的子集，或者他们的扩展集：操作系统和应用程序。
其中，操作系统，包含各种系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础任务以及处理基于硬件的任务。应用程序，包含各种应用程序，例如媒体播放器(Media Player)、浏览器(Browser)等，用于实现各种应用任务。实现本公开实施例提供的增量源码获取方法的程序可以包含在应用程序中。
在本公开实施例中，处理器1401通过调用存储器1402存储的程序或指令，具体的，可以是应用程序中存储的程序或指令，处理器401用于执行本公开实施例提供的增量源码获取方法各实施例的步骤。
本公开实施例提供的增量源码获取方法可以应用于处理器1401中，或者由处理器1401实现。处理器1401可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述 方法的各步骤可以通过处理器1401中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器1401可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
本公开实施例提供的增量源码获取方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件单元组合执行完成。软件单元可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器1402，处理器1401读取存储器1402中的信息，结合其硬件完成方法的步骤。
本公开实施例还提出一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如增量源码获取方法各实施例的步骤，为避免重复描述，在此不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本公开的范围之内并且形成不同的实施例。
本领域的技术人员能够理解，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
虽然结合附图描述了本公开的实施方式，但是本领域技术人员可以在不脱离本公开的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (15)

  1. 一种增量源码获取方法，所述方法包括：
    响应合码请求，获取所述合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识；
    基于所述主仓代码基础提交标识和主仓代码检查提交标识，确定所述主仓所依赖组件的组件变更信息；
    基于所述主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及所述主仓检查提交源码的增量信息；并基于所述组件变更信息，确定组件检查提交源码及所述组件检查提交源码的增量信息；
    将所述主仓检查提交源码、所述主仓检查提交源码的增量信息、所述组件检查提交源码和所述组件检查提交源码的增量信息打包为增量源码文件。
  2. 根据权利要求1所述的方法，其中，所述基于所述主仓代码基础提交标识和主仓代码检查提交标识，确定所述主仓所依赖组件的组件变更信息包括：
    基于所述主仓的仓库地址和所述主仓代码基础提交标识，获取主仓基础提交源码；
    基于所述主仓的仓库地址和所述主仓代码检查提交标识，获取主仓检查提交源码；
    基于所述主仓基础提交源码获取第一组件依赖树信息；
    基于所述主仓检查提交源码获取第二组件依赖树信息；
    基于所述第一组件依赖树信息和所述第二组件依赖树信息确定组件变更信息。
  3. 根据权利要求1所述的方法，其中，所述基于所述主仓代码基础提交标识和主仓代码检查提交标识，确定所述主仓所依赖组件的组件变更信息包括：
    基于所述主仓代码基础提交标识获取第一组件版本列表；
    基于所述主仓代码检查提交标识获取第二组件版本列表；
    基于所述第一组件版本列表和所述第二组件版本列表确定组件变更信息。
  4. 根据权利要求1至3任一项所述的方法，其中，所述组件变更信息包括更新组件信息和/或新增组件信息；
    所述更新组件信息包括：组件标识、更新前的版本号和组件更新后的版本号；
    所述新增组件信息包括：组件标识和版本号。
  5. 根据权利要求1所述的方法，其中，所述基于所述主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及所述主仓检查提交源码的增量信息包括：
    基于所述主仓的仓库地址和所述主仓代码检查提交标识，获取主仓检查提交源码；
    基于所述主仓代码基础提交标识和所述主仓代码检查提交标识，确定所述主仓检查提交源码的增量信息。
  6. 根据权利要求5所述的方法，其中，所述基于所述主仓代码基础提交标识和所述主仓代码检查提交标识，确定所述主仓检查提交源码的增量信息包括：
    基于所述主仓的仓库地址和所述主仓代码基础提交标识，获取主仓基础提交源码；
    将所述主仓基础提交源码和所述主仓检查提交源码进行差分，得到所述主仓检查提交源码的增量信息，其中，所述增量信息包括行号信息和所述行号信息对应的源码。
  7. 根据权利要求4所述的方法，其中，所述基于所述组件变更信息，确定组件检查提交源码及所述组件检查提交源码的增量信息包括：
    基于所述更新组件信息中的组件标识、更新前的版本号和组件更新后的版本号，获取更新组件所在仓库的地址、更新组件的代码基础提交标识和更新组件的代码检查提交标识；
    基于所述更新组件所在仓库的地址和所述更新组件的代码检查提交标识，获取该仓库中所有组件的源码；并从该仓库中所有组件的源码中获取所述更新组件的源码；
    基于所述更新组件的代码基础提交标识和所述更新组件的代码检查提交标识，确定所述更新组件的源码的增量信息。
  8. 根据权利要求7所述的方法，其中，所述从该仓库中所有组件的源码中获取所述更新组件的源码包括：
    在该仓库中注入自定义任务，所述自定义任务用于获取该仓库中所有组件的组件标识和组件路径；
    执行所述自定义任务，得到该仓库中所有组件的组件标识和组件路径；
    基于该仓库中所有组件的组件标识和组件路径，查找与所述更新组件的组件标识对应的组件路径；
    基于所述更新组件的组件标识对应的组件路径，获取所述更新组件的源码。
  9. 根据权利要求7所述的方法，其中，所述从该仓库中所有组件的源码中获取所述更新组件的源码包括：
    基于所述更新组件的组件标识，在该仓库中查找与所述更新组件的组件标识对应的组件配置文件；
    从所述组件配置文件中查找所述更新组件的源码配置信息；
    基于所述源码配置信息获得所述更新组件的源码的相对路径；
    基于所述更新组件的源码的相对路径，从该仓库中所有组件的源码中获取所述更新组件的源码。
  10. 根据权利要求7所述的方法，其中，所述基于所述更新组件的代码基础提交标识和所述更新组件的代码检查提交标识，确定所述更新组件的组件检查提交源码的增量信息包括：
    基于所述更新组件所在仓库的地址和所述更新组件的代码基础提交标识，获取该仓库中所有组件的第一源码；并基于所述更新组件所在仓库的地址和所述更新组件的代码检查提交标识，获取该仓库中所有组件的第二源码；
    将所述第一源码和所述第二源码进行差分，得到所述更新组件的检查提交源码的增量信息，所述增量信息包括行号信息和所述行号信息对应的源码。
  11. 根据权利要求4所述的方法，其中，基于所述组件变更信息，确定组件检查提交源码及所述组件检查提交源码的增量信息包括：
    基于所述新增组件信息中的组件标识和版本号，获取新增组件所在仓库的地址和新增组件的代码检查提交标识；
    基于所述新增组件所在仓库的地址和所述新增组件的代码检查提交标识，获取该仓库中所有组件的源码；并从该仓库中所有组件的源码中获取所述新增组件的源码；
    基于所述新增组件的源码中所有行号信息，确定所述新增组件的源码的增量信息。
  12. 根据权利要求1所述的方法，其中，所述合码请求还关联子仓，所述方法还包括：
    响应合码请求，获取所述合码请求关联的子仓的仓库地址、子仓代码基础提交标识和子仓代码检查提交标识；
    基于所述子仓的仓库地址、子仓代码基础提交标识和子仓代码检查提交标识，确定子仓检查提交源码及所述子仓检查提交源码的增量信息；
    相应地，将所述主仓检查提交源码、所述主仓检查提交源码的增量信息、所述子仓检查提交源码、所述子仓检查提交源码的增量信息、所述组件检查提交源码和所述组件检查提交源码的增量信息打包为增量源码文件。
  13. 一种增量源码获取装置，所述装置包括：
    获取单元，用于响应合码请求，获取所述合码请求关联的主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，并基于所述主仓代码基础提交标识和主仓代码检查提交标识，确定所述主仓所依赖组件的组件变更信息；
    确定单元，用于基于所述主仓的仓库地址、主仓代码基础提交标识和主仓代码检查提交标识，确定主仓检查提交源码及所述主仓检查提交源码的增量信息；并基于所述组件变更信息，确定组件检查提交源码及所述组件检查提交源码的增量信息；
    打包单元，用于将所述主仓检查提交源码、所述主仓检查提交源码的增量信息、所述组件检查提交源码和所述组件检查提交源码的增量信息打包为增量源码文件。
  14. 一种电子设备，包括：处理器和存储器；
    所述处理器通过调用所述存储器存储的程序或指令，用于执行如权利要求1至12任一项所述方法的步骤。
  15. 一种非暂态计算机可读存储介质，其中，所述非暂态计算机可读存储介质存储程序或指令，所述程序或指令使计算机执行如权利要求1至12任一项所述方法的步骤。
PCT/CN2022/079596 2021-04-21 2022-03-07 一种增量源码获取方法、装置、电子设备及存储介质 WO2022222626A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110429067.7 2021-04-21
CN202110429067.7A CN113126998B (zh) 2021-04-21 2021-04-21 一种增量源码获取方法、装置、电子设备及存储介质

Publications (1)

Publication Number Publication Date
WO2022222626A1 true WO2022222626A1 (zh) 2022-10-27

Family

ID=76778508

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/079596 WO2022222626A1 (zh) 2021-04-21 2022-03-07 一种增量源码获取方法、装置、电子设备及存储介质

Country Status (2)

Country Link
CN (1) CN113126998B (zh)
WO (1) WO2022222626A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113126998B (zh) * 2021-04-21 2023-11-07 北京字节跳动网络技术有限公司 一种增量源码获取方法、装置、电子设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105404519A (zh) * 2015-12-07 2016-03-16 青岛海信电器股份有限公司 一种版本控制方法、代码测试方法及系统
US20160299835A1 (en) * 2015-04-08 2016-10-13 Opshub, Inc. Method and system for providing delta code coverage information
CN106484606A (zh) * 2015-09-01 2017-03-08 阿里巴巴集团控股有限公司 一种代码提交方法和设备
CN106886445A (zh) * 2016-06-23 2017-06-23 阿里巴巴集团控股有限公司 Java数据包生成方法及设备和信息提取方法及设备
CN108776643A (zh) * 2018-06-04 2018-11-09 腾讯科技（武汉）有限公司 一种基于版本控制流程的目标代码合并控制方法及系统
CN111796855A (zh) * 2020-07-22 2020-10-20 大箴(杭州)科技有限公司 一种增量版本更新方法、装置、存储介质及计算机设备
CN113126998A (zh) * 2021-04-21 2021-07-16 北京字节跳动网络技术有限公司 一种增量源码获取方法、装置、电子设备及存储介质

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7761863B2 (en) * 2004-06-08 2010-07-20 Covia Labs, Inc. Method system and data structure for content renditioning adaptation and interoperability segmentation model
US8826222B2 (en) * 2011-08-02 2014-09-02 International Business Machines Corporation Pre-merge conflict avoidance
CN106528071B (zh) * 2015-09-15 2019-08-13 阿里巴巴集团控股有限公司 目标代码的选取方法及装置
CN105302554B (zh) * 2015-10-23 2018-11-30 深圳市创维电器科技有限公司 一种Android系统自动化程序构建方法及系统
US10754761B2 (en) * 2016-11-11 2020-08-25 Atlassian Pty Ltd Systems and methods for testing source code
CN107247601B (zh) * 2017-07-04 2021-01-01 武汉斗鱼网络科技有限公司 开发流程优化方法、装置及存储介质
GB2567427B (en) * 2017-10-06 2020-10-07 Imagination Tech Ltd Data compression
CN111414302A (zh) * 2020-02-28 2020-07-14 天津车之家数据信息技术有限公司 用于持续集成过程中的静态代码质量分析方法及计算设备
CN111475196B (zh) * 2020-03-30 2023-12-12 杭州迪普信息技术有限公司 编译告警溯源方法、装置、电子设备及计算机可读介质
CN112486567B (zh) * 2020-11-30 2024-06-14 上海瑞家信息技术有限公司 代码的合并请求发送方法、装置、电子设备及存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160299835A1 (en) * 2015-04-08 2016-10-13 Opshub, Inc. Method and system for providing delta code coverage information
CN106484606A (zh) * 2015-09-01 2017-03-08 阿里巴巴集团控股有限公司 一种代码提交方法和设备
CN105404519A (zh) * 2015-12-07 2016-03-16 青岛海信电器股份有限公司 一种版本控制方法、代码测试方法及系统
CN106886445A (zh) * 2016-06-23 2017-06-23 阿里巴巴集团控股有限公司 Java数据包生成方法及设备和信息提取方法及设备
CN108776643A (zh) * 2018-06-04 2018-11-09 腾讯科技（武汉）有限公司 一种基于版本控制流程的目标代码合并控制方法及系统
CN111796855A (zh) * 2020-07-22 2020-10-20 大箴(杭州)科技有限公司 一种增量版本更新方法、装置、存储介质及计算机设备
CN113126998A (zh) * 2021-04-21 2021-07-16 北京字节跳动网络技术有限公司 一种增量源码获取方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CN113126998B (zh) 2023-11-07
CN113126998A (zh) 2021-07-16

Similar Documents

Publication Publication Date Title
US10942734B2 (en) Software dependency shading
US8151247B2 (en) Test data management
US9152731B2 (en) Detecting a broken point in a web application automatic test case
Hassan et al. Rudsea: recommending updates of dockerfiles via software environment analysis
US9442717B2 (en) Techniques for automatically identifying input files used to generate output files in a software build process
US9311077B2 (en) Identification of code changes using language syntax and changeset data
US10275236B2 (en) Generating related templated files
US20190196946A1 (en) Software testing systems and methods
US20150339219A1 (en) Resilient mock object creation for unit testing
WO2022222626A1 (zh) 一种增量源码获取方法、装置、电子设备及存储介质
US9658845B2 (en) Generating a where-used objects list for updating data
CN112650526A (zh) 版本一致性的检测方法、装置、电子设备和介质
US20160253157A1 (en) Software refactoring
CN115292197A (zh) 一种软件测试方法、装置、电子设备及存储介质
Carr et al. Automatic contract insertion with ccbot
US20200097260A1 (en) Software application developer tools platform
CN108595656B (zh) 一种数据的处理方法及系统
US20080172659A1 (en) Harmonizing a test file and test configuration in a revision control system
WO2022257588A1 (zh) 代码处理方法、系统、计算机集群、介质及程序产品
CN112748905A (zh) 基础库的初始化调用方法、装置、电子设备及存储介质
US11449412B2 (en) Automated unit testing in a mainframe CICS environment
US11256602B2 (en) Source code file retrieval
CN113504904A (zh) 用户定义函数实现方法、装置、计算机设备和存储介质
Trier Gitpython documentation
Hinkula Hands-on Full Stack Development with Spring Boot 2.0 and React: Build Modern and Scalable Full Stack Applications Using the Java-based Spring Framework 5.0 and React

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22790735

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 150224)

122 Ep: pct application non-entry in european phase

Ref document number: 22790735

Country of ref document: EP

Kind code of ref document: A1