File generation method, device, medium, program, and product

Abstract

The present disclosure relates to the technical field of computer, and particularly provides a file generation method, device, medium, program and product. The method comprises: in response to a manifest.xml file generation request sent by a user terminal, parsing the manifest.xml file generation request to obtain request parameters, wherein the request parameters comprise a plurality of target repository branch identifiers under a target project; requesting a system code storage object to obtain code version metadata of the plurality of target repository branches, wherein after code of any repository branch in the system code storage object is updated, the system code storage object synchronously obtains updated code version metadata of the repository branch, and the target repository branch is a repository branch associated with the target repository branch identifier; generating a target manifest.xml file based on the code version metadata of the plurality of target repository branches, and sending the target manifest.xml file to the user terminal. The present disclosure improves the efficiency of generating a manifest.xml file.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a method, apparatus, medium, program and product for generating files. Background Technology

[0002] In software development projects, source code management, version control, compilation and building, and team collaborative development all heavily rely on the manifest.xml file. This file fully records the remote address, storage path, precise code commit version, and module dependency relationship of all code repository branches under the corresponding project branch in the code repository (git master) server used to store the project code. It is the core file for pulling consistent project source code, ensuring unified configuration of compilation units during parallel compilation, and realizing project version anchoring and traceability.

[0003] In related technologies, when compiling code, it is first necessary to execute the full source code retrieval command based on the repo tool to complete the local download of the complete code set of the entire project. After all the source code of all repository branches has been downloaded to the local machine, the repo manifest-ro command is executed in the project directory of the complete code set to generate the solidified manifest.xml file.

[0004] However, the manifest.xml file provided in the relevant technologies is not only complex and time-consuming, but also requires local storage resources, increasing the difficulty of equipment operation and maintenance. At the same time, when there are many repository branches under the development project, the execution of the repo manifest-ro command will put a lot of load pressure on the code repository server. Summary of the Invention

[0005] This disclosure was made in view of the above problems. This disclosure provides a method, apparatus, medium, program and product for generating a document, and this disclosure improves the efficiency of generating manifest.xml files.

[0006] According to a first aspect of this disclosure, a file generation method is provided, the method being applied to a server, comprising:

[0007] In response to a manifest.xml file generation request sent by a user terminal, the manifest.xml file generation request is parsed to obtain request parameters, which include multiple target repository branch identifiers under the target project; The system requests the code version metadata of multiple target repository branches from the system code storage object. After the code of any repository branch in the system code storage object is updated, the system code storage object synchronously obtains the updated code version metadata of the repository branch. The target repository branch is the repository branch associated with the target repository branch identifier. Based on the code version metadata of the multiple target repository branches, a target manifest.xml file is generated and sent to the user terminal.

[0008] According to a second aspect of this disclosure, a network device is provided, the network device including a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to implement the method of the first aspect.

[0009] According to a third aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.

[0010] According to a fourth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0011] The file generation method, device, medium, program, and product provided in this disclosure have several advantages. Firstly, by using a server-side mechanism, the goal of generating a manifest.xml file is achieved. The user terminal does not need to provide storage space or undergo complex operations; it only needs to send a manifest.xml file generation request to the server. The request parameters in the manifest.xml file generation request, based on the code version metadata of the target repository branch obtained from the system code storage object used to store project source code, generate the required manifest.xml file, reducing the storage pressure on the user terminal and improving the efficiency of manifest.xml file generation. Secondly, since the system code storage object synchronously obtains the code version metadata of any repository branch after its code is updated, the server can request and obtain the code version metadata of multiple target repository branches from the system code storage object at once during the manifest.xml file generation process, without needing to request the corresponding code version metadata from each target repository branch in the system code storage object, not only reduces the request processing pressure on the system code storage object during manifest.xml file generation but also improves the efficiency of obtaining the code version metadata of multiple target repository branches, further enhancing the efficiency of manifest.xml file generation.

[0012] It should be understood that both the foregoing general description and the following detailed description are exemplary and intended to provide further illustration of the claimed technology. Attached Figure Description

[0013] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0014] Figure 1 This is an interactive flowchart of parallel compilation of project source code according to an embodiment of this disclosure. Figure 2 This is a schematic diagram illustrating an application scenario of a file generation scheme according to an embodiment of this disclosure.

[0015] Figure 3 This is a flowchart of a file generation method according to an embodiment of the present disclosure.

[0016] Figure 4 This is an interactive flowchart of a file generation method according to an embodiment of this disclosure.

[0017] Figure 5 This is a schematic block diagram of the functional modules of the document generation apparatus according to an embodiment of the present disclosure.

[0018] Figure 6 This is a schematic diagram of a computer program product according to an embodiment of the present disclosure.

[0019] Figure 7 This is a hardware block diagram of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this disclosure more apparent, exemplary embodiments according to this disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this disclosure, and not all embodiments of this disclosure. It should be understood that this disclosure is not limited to the exemplary embodiments described herein.

[0021] In related technologies, after developers complete the project code development, they upload it to the corresponding repository branch on the code repository server. When the project code needs to be compiled, a manifest.xml file needs to be generated on the user's terminal first, and then the project source code is compiled in parallel. Figure 1 As shown, Figure 1This illustration shows an interactive flowchart of parallel compilation of project source code according to an embodiment of the present disclosure. In this flowchart, user terminal 101 can send a task start command to task management server 102. In response to the task start command, task management server 102 requests and obtains the manifest.xml file from user terminal 101, splits the project source code into multiple parallel compilation tasks, and then distributes the multiple parallel compilation tasks to resource management server 103. Multiple service nodes in resource management server 103 can execute the compilation tasks synchronously and return the execution results of the compilation tasks to task management server 102 for combination to obtain the project source code compilation result.

[0022] The generation of the manifest.xml file on the user terminal typically involves multiple code downloads and command issuance operations by the user, a complex process that takes a considerable amount of time, resulting in low efficiency. Furthermore, the need to download the complete project codebase increases local storage resource consumption, potentially threatening the normal operation of the user terminal. Additionally, although the code downloaded locally is from a mirror server of the code repository, the execution of the `repo manifest-ro` command requires querying the repository server for branch status information, which can place a significant load on the repository server, especially when there are many branches.

[0023] To address the aforementioned problems, this disclosure provides a file generation method, such as... Figure 2 As shown, Figure 2 The illustration shows an application scenario diagram of the file generation method provided in this embodiment, including a user terminal 101, a server 201, and a system code storage object 202. The user terminal 101 is a terminal device used by developers, which can be a desktop computer, laptop, or tablet computer, etc. The server 201 is a service system for generating manifest.xml files based on requests from the user terminal; the service system can be deployed on a server or server cluster, etc. The system code storage object 202 is a storage server for storing project source code. The system code storage object 202 can be a code repository server, a mirror server of a code repository server, or an archive storage server. The archive storage server can be an object storage server, a tape library, or a snapshot storage server. The code repository server is used for developers to upload project source code, synchronize the project source code to the mirror server, and periodically transfer the project source code to the archive storage server.

[0024] Wired or wireless connections can be established between the user terminal 101 and the server 201, and between the server 201 and the system code storage object 202, to implement the file generation scheme provided in this embodiment of the disclosure.

[0025] Figure 3 A flowchart illustrating an exemplary embodiment of this disclosure is shown. The file generation method is applied to a server, such as... Figure 3 As shown, the method in this embodiment of the disclosure may include: Step S301: In response to the manifest.xml file generation request sent by the user terminal, parse the manifest.xml file generation request to obtain the request parameters; The request parameters include identifiers of multiple target repository branches under the target project; Step S302: Request the code version metadata of multiple target repository branches from the system code storage object; When the code of any repository branch in the system code storage object is updated, the system code storage object synchronously obtains the updated code version metadata of the repository branch, and the target repository branch is the repository branch associated with the target repository branch identifier. Step S303: Based on the code version metadata of multiple target repository branches, generate the target manifest.xml file and send the target manifest.xml file to the user terminal; In summary, the file generation method provided in this disclosure has two advantages. First, it achieves the goal of generating the manifest.xml file through the server. The user terminal does not need to provide storage space or perform complex operations. It only needs to send a manifest.xml file generation request to the server, and the request parameters in the manifest.xml file generation request can generate the manifest.xml file required by the user based on the code version metadata of the target repository branch obtained from the system code storage object used to store project source code. This reduces the storage pressure on the user terminal and improves the efficiency of generating the manifest.xml file. Second, since the system code storage object synchronously obtains the code version metadata of the repository branch after the code of any repository branch in the system code storage object is updated, the server can request and obtain the code version metadata of multiple target repository branches from the system code storage object at one time during the generation of the manifest.xml file. It does not need to request the corresponding code version metadata of each target repository branch in the system code storage object. This not only reduces the request processing pressure of the system code storage object during the generation of the manifest.xml file, but also improves the efficiency of obtaining the code version metadata of multiple target repository branches, further improving the efficiency of manifest.xml file generation.

[0026] The following are Figure 3 The specific implementation methods of each step in the illustrated embodiment are described in detail below: In step S301, the server responds to the manifest.xml file generation request sent by the user terminal by parsing the manifest.xml file generation request to obtain the request parameters.

[0027] In this embodiment of the disclosure, a project can consist of multiple project branches. In the system code storage object, the source code of each project branch can be stored in different project branches. The manifest.xml file generation request is used to instruct the server to generate the manifest.xml file of the target project. The request parameters include at least multiple target repository branch identifiers under the target project. The target project is the project that needs to generate the manifest.xml file. The target project can be determined based on actual needs, and this embodiment of the disclosure does not limit it. The multiple target repository branch identifiers are the identifiers of at least two repository branches among all repository branches under the target project.

[0028] It is understood that, in this embodiment of the disclosure, when it is necessary to generate the manifest.xml file of the target project, the developer can perform configuration operations on the user terminal to generate a manifest.xml file generation request; wherein, the configuration operation can be used to configure the identification information of multiple target repository branches of the target project; the configuration operation can also be used to configure time parameters, code storage object identification parameters and / or, verification parameters of at least one target repository branch to be verified, etc.

[0029] The time parameter in this document instructs the server to generate a manifest.xml file based on the code version metadata of the target repository branch at the corresponding time. The time parameter can be determined based on actual needs, and this embodiment does not limit it. The code storage object identifier parameter instructs the server to generate a manifest.xml file using the code version metadata stored in a specific code storage object. The verification parameter instructs the server to verify the code version metadata of the multiple target repository branches. The verification parameter can be determined based on actual needs, and this embodiment does not limit it. For example, the verification parameter can be a code file filtering condition parameter for sensitive code file identifiers in the target repository branch to be verified, or a code file filtering condition parameter for target code files in the target repository branch to be verified. The code file filtering condition parameter can be included or not included.

[0030] The code version metadata is data generated after the code version under the repository branch is updated, which is used to represent the attributes and relationships of the code version itself. The code version metadata may include information such as repository identifier, code version identifier (commit-id), HEAD header information, and the mapping relationship between code files and file hash values ​​within the repository branch. The HEAD header information is used to identify the project branch where the repository branch is located and the corresponding code version, and the file hash value is the identification information of the code file.

[0031] It should be noted that, in this embodiment of the disclosure, when the request parameters other than the multiple target repository branch identifiers in the manifest.xml file generation request are set to default values, the latest code version metadata of multiple target repository branches can be obtained from the code repository server by default.

[0032] In one optional implementation, the process of the server responding to the manifest.xml file generation request sent by the user terminal and parsing the manifest.xml file generation request to obtain request parameters may include: responding to the manifest.xml file generation request sent by the user terminal and parsing the manifest.xml file generation request to obtain request parameters, wherein the request parameters include at least multiple target repository branch identifiers of the target project.

[0033] Optionally, if the manifest.xml file generation request also includes a time parameter, a code storage object identifier parameter, and / or a verification parameter for at least one target repository branch to be verified, the request parameters obtained by the server after parsing the manifest.xml file to generate the request may also include a time parameter, a code storage object identifier parameter, and / or a verification parameter for at least one target repository branch to be verified.

[0034] It should also be noted that, in this embodiment of the disclosure, the server can concurrently respond to manifest.xml file generation requests. The number of manifest.xml file generation requests that the server can concurrently respond to can be determined based on actual needs. This embodiment of the disclosure does not limit this, thereby preventing server overload and ensuring the reliability of the server's manifest.xml file generation request response.

[0035] In step S302, a request is made to the system code storage object to obtain the code version metadata of multiple target repository branches; In this embodiment of the disclosure, after the code of any repository branch in the system code storage object is updated, the code version metadata of the repository branch will be updated. The system code storage object synchronously obtains the updated code version metadata of the repository branch. The target repository branch is the repository branch in the system code storage object that is associated with the target repository branch identifier.

[0036] In one optional implementation, the request parameters also include a default time parameter. The process of the server requesting the system code storage object to obtain code version metadata of multiple target repository branches includes: sending a first data retrieval request to the system code storage object; then, receiving the latest code version metadata of the multiple target repository branches returned by the system code storage object, thus obtaining the code version metadata of the multiple target repository branches. The first data retrieval request is used to instruct the system code storage object to return the latest code version metadata of the multiple target repository branches. When the time parameter in the request parameters for generating the manifest.xml file is a default parameter, the server can directly instruct the system code storage object to return the latest code version metadata of the multiple target repository branches, thus meeting the common requirement of generating a manifest.xml file from the latest code version metadata of the multiple target repository branches.

[0037] It is understood that in this embodiment of the disclosure, the first data acquisition request includes multiple target repository branch identifiers and a default time parameter; after receiving the first data acquisition request, the system code storage object reads the latest code version metadata of the target repository branches corresponding to the multiple target repository branch identifiers from the database used to store the updated code version metadata of the repository branches, and sends the latest code version metadata of the multiple target repository branches to the server.

[0038] In one optional implementation, the request parameters include a historical time parameter. The process of the server requesting code version metadata of multiple target repository branches from the system code storage object includes: sending a second data retrieval request to the system code storage object; then, receiving the historical code version metadata of the multiple target repository branches returned by the system code storage object, thus obtaining the code version metadata of the multiple target repository branches. The second data retrieval request includes a historical time parameter and is used to instruct the system code storage object to return the historical code version metadata of the multiple target repository branches corresponding to the historical time parameter. If the time parameter in the request parameters for generating the manifest.xml file is a historical time parameter, the server can directly instruct the system code storage object to return the historical code version metadata of the multiple target repository branches corresponding to the historical time parameter, thus meeting the specific requirement of generating the manifest.xml file from the historical code version metadata of the multiple target repository branches.

[0039] It is understood that in this embodiment of the disclosure, the second data acquisition request includes multiple target repository branch identifiers and historical time parameters; after receiving the second data acquisition request, the system code storage object reads the historical code version metadata of the target repository branches corresponding to the multiple target repository branch identifiers at the historical time parameters in the database used to store the updated code version metadata of the repository branches, and sends the historical code version metadata of the multiple target repository branches to the server.

[0040] In one optional implementation, when the request parameters include a default code storage object identifier parameter, the process of the server requesting code version metadata for multiple target repository branches from the system code storage object may include: requesting the code repository branch server to obtain the code version metadata for multiple target repository branches. By default, the code version metadata for multiple target repository branches can be obtained directly from the code repository branch server used to store the source project code. This relies on the code repository branch server as the core and authoritative storage carrier for code version metadata, ensuring accurate and reliable acquisition of the code version metadata corresponding to each target repository branch. This guarantees that the acquired code version metadata is compliant, authentic, and complete baseline data under the project branch, ensuring the accuracy and reliability of the code version metadata from the data source.

[0041] It should be noted that in traditional techniques where a manifest.xml file is generated via a user terminal, the user terminal downloads code from a mirror server of the code repository server. Since it takes time for the code repository server to synchronize project code with the mirror server, the code downloaded from the mirror server during the generation of the latest manifest.xml file is not the latest project code uploaded by the developers from the code repository server. As a result, the latest manifest.xml file generated by the user terminal is not the actual latest manifest.xml file.

[0042] In one optional implementation, when the request parameters include a default time parameter and a default code storage object identifier parameter, the process of the server requesting code version metadata of multiple target repository branches from the system code storage object includes: sending a first data retrieval request to the code repository branch server; and receiving the latest code version metadata of the multiple target repository branches returned by the code repository branch server, thereby obtaining the code version metadata of the multiple target repository branches. When it is necessary to generate a target manifest.xml file using the latest code version metadata of the multiple target repository branches, the latest code version metadata of the multiple target repository branches can be directly obtained from the code repository branch server, ensuring consistency between the latest code version metadata used to generate the multiple target repository branches and the latest code version metadata uploaded by the developers, thereby improving the reliability of the generated latest target manifest.xml file of the target project.

[0043] It should be noted that, in this embodiment of the disclosure, when the request parameters include a mirror server identifier parameter, the process of the server requesting code version metadata of multiple target repository branches from the system code storage object includes: requesting the mirror server of the code repository branch server to obtain the code version metadata of multiple target repository branches; or, when the request parameters include an archive storage server identifier parameter, the process of the server requesting code version metadata of multiple target repository branches from the system code storage object includes: requesting the archive storage server to obtain the code version metadata of multiple target repository branches. This is to meet the control requirements of server-accessible objects under special business scenarios and improve the adaptability of the target manifest.xml file generated from the server to the diversity of business scenarios.

[0044] In an optional implementation, when the request parameters include verification parameters, before generating the target manifest.xml file based on the code version metadata of multiple target repository branches, the server can further: verify the code version metadata of multiple target repository branches based on the verification parameters to obtain a verification result; wherein, if the verification result indicates that the verification passed, then it is determined that the target manifest.xml file will be generated based on the code version metadata of multiple target repository branches. Verifying the code version metadata of multiple target repository branches based on the verification parameters, and generating the target manifest.xml file only after the verification passes, allows for pre-verification of the compliance and validity of the code version metadata. This ensures from the source that the version data on which the target manifest.xml file is based is accurate, compliant, and consistent, guaranteeing the correctness of the content and the consistency of special requirements in the target manifest.xml file.

[0045] It is understood that in this embodiment of the disclosure, if the verification result indicates that the verification failed, it is determined to return verification failure information to the user terminal, wherein the verification failure information may include detailed content of the verification result.

[0046] In one optional implementation, the verification parameters include a target code file identifier associated with at least one target repository branch identifier to be verified, and a code file filtering condition parameter associated with the target code file identifier. The process by which the server verifies the code version metadata of multiple target repository branches based on the verification parameters to obtain the verification result includes: identifying the target repository branches that are associated with at least one target repository branch identifier to be verified as the target repository branches to be verified; then, for each target repository branch to be verified, extracting the code file identifier from the code version metadata associated with the target repository branch to be verified to obtain the code file identifier to be verified; and finally, determining the verification result of the target repository branch to be verified based on the code file identifier to be verified and the code file filtering condition parameter of the target code file identifier corresponding to the target repository branch to be verified. By accurately locating the target repository branch to be verified and extracting the identifier of the code file to be verified from the target repository branch, and combining the code file filtering condition parameters corresponding to the target code file identifier of the target repository branch, as well as the code file identifier to be verified, the verification result of the target repository branch to be verified can be determined. Based on the verification parameters, the compliance of the code file of the target repository branch to be verified can be accurately verified, ensuring that the metadata used to generate the target manifest.xml file is compliant and accurate.

[0047] In one optional implementation, when the code file filtering condition parameter is included, the process by which the server determines the verification result of the target repository branch to be verified based on the code file identifier to be verified and the code file filtering condition parameter associated with the target code file identifier corresponding to the target repository branch to be verified may include: determining that the verification result of the target repository branch to be verified is verified as passed when the code file identifier to be verified contains the target code file identifier; or determining that the verification result of the target repository branch to be verified is failed when the code file identifier to be verified does not contain the target code file identifier.

[0048] In one optional implementation, when the code file filtering condition parameter is "not included", the process of the server determining the verification result of the target repository branch to be verified based on the code file identifier to be verified and the code file filtering condition parameter associated with the target code file identifier corresponding to the target repository branch to be verified may include: if the code file filtering condition parameter is "included", then if the target code file identifier is included in the code file identifier to be verified, the verification result of the target repository branch to be verified is determined to be "verification failed"; or, if the target code file identifier is not included in the code file identifier to be verified, the verification result of the target repository branch to be verified is determined to be "verification passed".

[0049] It should be noted that, in this embodiment of the disclosure, when the verification parameter is the code file filtering condition parameter for the sensitive code file identifier in the target repository branch to be verified, the process by which the server verifies the code version metadata of multiple target repository branches based on the verification parameter to obtain the verification result is similar to the process in the above embodiment where the verification parameter is the code file filtering condition parameter for the target code file in the target repository branch to be verified, and the process by which the server verifies the code version metadata of multiple target repository branches based on the verification parameter to obtain the verification result is not described in detail in this embodiment of the disclosure.

[0050] In step S303, the server generates a target manifest.xml file based on the code version metadata of multiple target repository branches and sends the target manifest.xml file to the user terminal.

[0051] In this embodiment of the disclosure, the server can periodically obtain global common configuration metadata for each project from the code repository server, so that when generating the target manifest.xml file, it can directly generate the target manifest.xml file required by the user based on the target global common configuration metadata associated with the target project. The period at which the server obtains global common configuration metadata for each project from the code repository server can be determined based on actual needs, and this embodiment of the disclosure does not limit this.

[0052] Among them, global common configuration metadata refers to structured configuration data that corresponds one-to-one with a specified project. It is a unified set of configuration information shared by all repository branches under the project. It records the global common configuration rules, general parameters and basic association information of the project branches, including but not limited to the remote code repository access address, the branch default version baseline, the global synchronization control strategy, and the branch basic identifier.

[0053] In one optional implementation, the process of the server generating a target manifest.xml file based on the code version metadata of multiple target repository branches includes: reading the target global common configuration metadata associated with the target project; and then generating the target manifest.xml file based on the code version metadata of multiple target repository branches and the target global common configuration metadata. By reading the target global common configuration metadata corresponding to the target project and combining it with the code version metadata of multiple target repository branches to generate the target manifest.xml file, the project's globally unified common configuration is combined with the version data of each repository branch. This ensures that the generated target manifest.xml file has a unified configuration specification and accurate repository version information, ensuring both file version consistency and content compliance and accuracy, while also meeting the core requirement of parallel compilation for unified manifest file versions, effectively avoiding compilation exceptions.

[0054] Optionally, before generating the target manifest.xml file based on the code version metadata of multiple target repository branches and the target global common configuration metadata, the server can send a target global common configuration metadata retrieval request to the system code storage object. If the target global common configuration metadata currently returned by the system code storage object differs from the target global common configuration metadata already stored on the server, the server determines whether to generate the target manifest.xml file based on the code version metadata of the multiple target repository branches and the updated target global common configuration metadata. The updated target global common configuration metadata is the target global common configuration metadata currently returned by the system code storage object. This allows the server to generate the target manifest.xml file using the latest target global common configuration metadata if the target global common configuration metadata has been updated, further improving the reliability of the generated target manifest.xml file.

[0055] Optionally, in this embodiment of the disclosure, if the code version metadata of multiple target repository branches returned by the system code storage object is not arranged in accordance with the format requirements for generating the target manifest.xml file, the server also needs to arrange the code version metadata of multiple target repository branches in accordance with the format requirements for generating the target manifest.xml file before generating the target manifest.xml file based on the code version metadata of multiple target repository branches and the target global public configuration metadata.

[0056] It is understood that, in this embodiment of the disclosure, the server can process the code version metadata of multiple target repository branches and the target global public configuration metadata based on the pre-configured format requirements of the target manifest.xml file to generate the target manifest.xml file.

[0057] For example, such as Figure 4 As shown, Figure 4 An interactive flowchart of a file generation method provided in an embodiment of this disclosure is shown, including: In step S401, the user terminal responds to the configuration operation by generating a manifest.xml file generation request and sending the manifest.xml file generation request to the server. Step S402: The server responds to the manifest.xml file generation request sent by the user terminal, and parses the manifest.xml file generation request to obtain the request parameters; Step S403: Request the code version metadata of multiple target repository branches from the system code storage object; Step S404: Verify the code version metadata of multiple target repository branches based on the verification parameters in the request parameters to obtain the verification results; Step S405: If the verification result indicates that the verification is successful, generate a target manifest.xml file based on the code version metadata of multiple target repository branches, and send the target manifest.xml file to the user terminal.

[0058] An exemplary embodiment of this disclosure provides a file generation apparatus, which can be a server. Figure 5 A schematic block diagram of the functional modules of a document generation apparatus according to an exemplary embodiment of the present disclosure is shown. Figure 5 As shown, the document generation device 500 includes: The parsing module 501 is configured to respond to a manifest.xml file generation request sent by a user terminal, parse the manifest.xml file generation request to obtain request parameters, the request parameters containing multiple target repository branch identifiers under the target project; The request module 502 is configured to request code version metadata of multiple target repository branches from the system code storage object. After the code of any repository branch in the system code storage object is updated, the system code storage object synchronously obtains the updated code version metadata of the repository branch. The target repository branch is a repository branch associated with the target repository branch identifier. The generation module 503 is configured to generate a target manifest.xml file based on the code version metadata of the multiple target repository branches, and send the target manifest.xml file to the user terminal.

[0059] Optionally, the request parameters include a default time parameter, and the request module 502 is configured as follows: Send a first data retrieval request to the system code storage object, the first data retrieval request being used to instruct the system code storage object to return the latest code version metadata in multiple target repository branches; Receive the latest code version metadata from multiple target repository branches returned by the system code storage object, and obtain the code version metadata of the multiple target repository branches.

[0060] Optionally, the request parameters include historical time parameters, and the request module 502 is configured as follows: Send a second data retrieval request to the system code storage object. The second data retrieval request includes the historical time parameter. The second data retrieval request is used to instruct the system code storage object to return the historical code version metadata corresponding to the historical time parameter in multiple target repository branches. Receive the historical code version metadata from multiple target repository branches returned by the system code storage object, and obtain the code version metadata of the multiple target repository branches.

[0061] Optionally, the request parameters include verification parameters, and the device further includes a verification module 504 configured to: Based on the verification parameters, the code version metadata of the multiple target repository branches is verified to obtain the verification result: If the verification result indicates that the verification is successful, then the target manifest.xml file is generated based on the code version metadata of the multiple target repository branches.

[0062] Optionally, the verification parameters include a target code file identifier associated with at least one target repository branch identifier to be verified, and code file filtering condition parameters associated with the target code file identifier. The verification module 504 is configured as follows: Among multiple target warehouse branches, the target warehouse branch that is associated with the at least one target warehouse branch identifier to be verified is identified as the target warehouse branch to be verified. For each target repository branch to be verified, extract the code file identifier from the code version metadata associated with the target repository branch to obtain the code file identifier to be verified. Based on the identifier of the code file to be verified, and the code file filtering condition parameters associated with the identifier of the target code file corresponding to the target repository branch to be verified, the verification result of the target repository branch to be verified is determined.

[0063] Optionally, the request parameters include a default code storage object identifier parameter, and the request module 502 is configured as follows: Request code version metadata for multiple target repository branches from the code repository branch server.

[0064] Optionally, the generation module 503 is configured as follows: Read the target global public configuration metadata associated with the target project; Based on the code version metadata of the multiple target repository branches and the target global public configuration metadata, the target manifest.xml file is generated.

[0065] Exemplary embodiments of this disclosure also provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this disclosure.

[0066] Exemplary embodiments of this disclosure also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to embodiments of this disclosure.

[0067] like Figure 6 As shown, an exemplary embodiment of this disclosure also provides a computer program product 600, including a computer program 601, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this disclosure.

[0068] refer to Figure 7The present invention describes a structural block diagram of an electronic device 700 that can serve as a server for this disclosure, which is an example of a hardware device that can be applied to various aspects of this disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the disclosure described and / or claimed herein.

[0069] like Figure 7 As shown, the electronic device 700 includes a computing unit 701, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 702 or a computer program loaded from a storage unit 708 into a random access memory (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the electronic device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0070] Multiple components in electronic device 700 are connected to I / O interface 705, including: input unit 706, output unit 707, storage unit 708, and communication unit 709. Input unit 706 can be any type of device capable of inputting information to electronic device 700. Input unit 706 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 707 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 708 may include, but is not limited to, disk and optical disk. Communication unit 709 allows electronic device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0071] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above. For example, in some embodiments, the methods of the exemplary embodiments of this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 700 via ROM 702 and / or communication unit 709. In some embodiments, the computing unit 701 can be configured to perform the methods of the exemplary embodiments of this disclosure by any other suitable means (e.g., by means of firmware).

[0072] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0073] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0074] As used in this disclosure, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0075] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0076] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0077] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this disclosure are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a terminal, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disc (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0078] Although this disclosure has been described in conjunction with specific features and embodiments, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of this disclosure. Accordingly, this specification and drawings are merely exemplary illustrations of the disclosure as defined by the appended claims and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this disclosure. It is obvious that those skilled in the art can make various alterations and modifications to this disclosure without departing from its spirit and scope. Thus, this disclosure is also intended to include any such modifications and modifications that fall within the scope of the claims of this disclosure and their equivalents.

Claims

1. A method for generating a file, characterized in that, The method is applied to the server side and includes: In response to a manifest.xml file generation request sent by a user terminal, the manifest.xml file generation request is parsed to obtain request parameters, which include multiple target repository branch identifiers under the target project; The system requests the code version metadata of multiple target repository branches from the system code storage object. After the code of any repository branch in the system code storage object is updated, the system code storage object synchronously obtains the updated code version metadata of the repository branch. The target repository branch is the repository branch associated with the target repository branch identifier. Based on the code version metadata of the multiple target repository branches, a target manifest.xml file is generated and sent to the user terminal.

2. The method according to claim 1, characterized in that, The request parameters include a default time parameter. The request to obtain code version metadata for multiple target repository branches from the system code storage object includes: Send a first data retrieval request to the system code storage object, the first data retrieval request being used to instruct the system code storage object to return the latest code version metadata in multiple target repository branches; Receive the latest code version metadata from multiple target repository branches returned by the system code storage object, and obtain the code version metadata of the multiple target repository branches.

3. The method according to claim 1, characterized in that, The request parameters include historical time parameters, and the request to obtain code version metadata of multiple target repository branches from the system code storage object includes: Send a second data retrieval request to the system code storage object. The second data retrieval request includes the historical time parameter. The second data retrieval request is used to instruct the system code storage object to return the historical code version metadata corresponding to the historical time parameter in multiple target repository branches. Receive the historical code version metadata from multiple target repository branches returned by the system code storage object, and obtain the code version metadata of the multiple target repository branches.

4. The method according to claim 1, characterized in that, The request parameters include verification parameters. Before generating the target manifest.xml file based on the code version metadata of the multiple target repository branches, the method further includes: Based on the verification parameters, the code version metadata of the multiple target repository branches is verified to obtain the verification result: If the verification result indicates that the verification is successful, then the target manifest.xml file is generated based on the code version metadata of the multiple target repository branches.

5. The method according to claim 4, characterized in that, The verification parameters include target code file identifiers associated with at least one target repository branch identifier to be verified, and code file filtering condition parameters associated with the target code file identifiers. The verification result obtained by verifying the code version metadata of the multiple target repository branches based on the verification parameters includes: Among multiple target warehouse branches, the target warehouse branch that is associated with the at least one target warehouse branch identifier to be verified is identified as the target warehouse branch to be verified. For each target repository branch to be verified, extract the code file identifier from the code version metadata associated with the target repository branch to obtain the code file identifier to be verified. Based on the identifier of the code file to be verified, and the code file filtering condition parameters associated with the identifier of the target code file corresponding to the target repository branch to be verified, the verification result of the target repository branch to be verified is determined.

6. The method according to claim 1, characterized in that, The request parameters include a default code storage object identifier parameter, and the request to the system code storage object to obtain code version metadata for multiple target repository branches includes: Request code version metadata for multiple target repository branches from the code repository branch server.

7. The method according to claim 1, characterized in that, The step of generating a target manifest.xml file based on the code version metadata of the multiple target repository branches includes: Read the target global public configuration metadata associated with the target project; Based on the code version metadata of the multiple target repository branches and the target global public configuration metadata, the target manifest.xml file is generated.

8. An electronic device, the electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images