Method for assembling multi-branch products and electronic device

Abstract

The application discloses an assembly method of a multi-branch product and an electronic device, and relates to the technical field of computers, and comprises the following steps: obtaining a construction request; wherein the construction request comprises product information, version information and branch information; according to the construction request, a plurality of target branches corresponding to the same product are determined, and baseline snapshots corresponding to the plurality of target branches are obtained; wherein the baseline snapshot is a read-only source code directory determined from a code repository; according to the baseline snapshot and the construction request, difference files of the target branches are determined; according to the baseline snapshot and the difference files, a complete construction view of the target branches is generated; according to the difference files, construction tasks of the target branches are generated; and according to the complete construction view, the construction tasks are executed in parallel to generate assembly products of the target branches, so that efficient and safe product assembly can be realized.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to assembly methods and electronic devices for multi-branch products. Background Technology

[0002] Large software products such as server management platforms, operation and maintenance software, and enterprise-level business systems typically require the simultaneous maintenance of multiple stable versions, maintenance versions, and development versions. The same product may have multiple long-term coexisting target branches in the code repository. In related technologies, the assembly of multi-branch products usually employs either a single-environment serial assembly scheme or a multi-environment parallel assembly scheme. The former involves sequentially switching between different branches and executing assembly tasks serially within a single build environment, resulting in lower disk usage but lacking parallel processing capabilities; it also provides isolation, but disk and environment maintenance costs increase significantly with the number of branches. Therefore, how to securely and efficiently assemble multi-branch products is a pressing technical problem that needs to be solved. Summary of the Invention

[0003] This application provides a method for assembling multi-branch products and an electronic device to at least address the problem of how to safely and efficiently assemble multi-branch products in related technologies.

[0004] This application provides a method for assembling a multi-branch product, including:

[0005] Obtain the build request; the build request includes product information, version information, and branch information.

[0006] Based on the build request, identify multiple target branches corresponding to the same product and obtain baseline snapshots for the multiple target branches; wherein, the baseline snapshot is a read-only source code directory determined from the code repository;

[0007] Based on the baseline snapshot and build request, determine the difference files for the target branch;

[0008] Generate a complete build view of the target branch based on the baseline snapshot and diff files;

[0009] Based on the difference file, generate a build task for the target branch;

[0010] Based on the complete build view, build tasks are executed in parallel to generate the assembly artifacts of the target branch.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the assembly method of any of the above-described multi-branch products.

[0012] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the assembly method of any of the above-described multi-branch products.

[0013] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of assembling any of the above-described multi-branch products.

[0014] This application provides an efficient and secure assembly scheme for multi-branch products. In response to a build request, multiple target branches corresponding to the same product are identified. A read-only source code directory is obtained from the code repository as a baseline snapshot of the product, allowing multiple target branches to share the same read-only source code base. Then, a difference file is built for each target branch. Finally, a complete build view of the target branch is generated using the baseline snapshot and the difference file. This allows each target branch to obtain a complete build environment by storing only the difference file, further reducing redundant storage. Build tasks for each target branch are generated based on the difference files, and these tasks are executed in parallel based on the complete build view. This allows the assembly tasks of multiple target branches to be executed concurrently without interference within the same build environment. Through this method, while achieving parallel assembly of multiple branches, disk resource consumption is effectively reduced, assembly efficiency is improved, and secure and efficient multi-branch product assembly is realized. Attached Figure Description

[0015] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram of an assembly system architecture for a multi-branch product is provided as an embodiment of this application;

[0017] Figure 2 This application provides a schematic diagram of the structure of an assembly process.

[0018] Figure 3 A schematic flowchart illustrating the assembly method for a multi-branch product provided in this application embodiment;

[0019] Figure 4 A schematic diagram illustrating the relationship between a branch construction view and a writable overlay layer provided in an embodiment of this application;

[0020] Figure 5 A schematic diagram illustrating the process of generating a build manifest from a difference file, as provided in an embodiment of this application;

[0021] Figure 6 This is a schematic diagram of the structure of the assembly apparatus for multi-branch products provided in the embodiments of this application;

[0022] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0023] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the embodiments of this application.

[0024] It should be noted that, in the description of the embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in the embodiments of this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0025] First, the terms used in the embodiments of this application will be explained:

[0026] Assembly plant: A set of automated build tools and execution environments used to receive product versions, code branches, build parameters, and output installation packages, patch packages, or module packages.

[0027] Baseline snapshot: A read-only source code directory generated from a selected stable commit or stable branch in the code repository, serving as the file base for reuse by multiple target branches.

[0028] Build View: A temporary source code directory presented for a specific target branch. This directory consists of the baseline snapshot and the difference files for that target branch; the build tool sees the complete source code tree.

[0029] Writable overlay: A writable directory allocated separately for each target branch, used to store newly added files, modified files, deleted markers, build output, and temporary files, without writing back to the baseline snapshot.

[0030] Shared dependency repository: A read-only or quasi-read-only cache pool for dependencies, plugins, and internal components of build and dependency management tools. Multiple build tasks reuse existing dependencies through independent write layers.

[0031] Build manifest: A structured record consisting of the difference files of the target branch relative to the baseline snapshot, affected build and dependency management tool modules, dependency closures, build commands, and output artifact checksums.

[0032] Module dependency graph: A directed graph generated by the parent and child project object models (POM) of the build and dependency management tools, module tags, artifact identifiers (artifactId), dependencies, and plugin configurations, used to determine the affected modules and their dependencies.

[0033] Temporary isolation directories: Each build task has its own dedicated build artifact directory (target), temporary directory (tmp), working directory (workdir), and log directory, used to isolate intermediate files during concurrent build processes.

[0034] Product verification list: A file that records the build product package, configuration package, patch package, version number, commit number, Secure Hash Algorithm (SHA) verification value and build environment fingerprint, as a basis for subsequent tracing and evidence collection.

[0035] Low redundancy disk usage: This does not mean that no new files are generated at all, but rather that the source code and dependencies are not copied in full for each branch. Only diff files, build outputs and necessary metadata are used for additional space.

[0036] Server management platforms, operations and maintenance software, and enterprise-level business systems typically maintain multiple stable, maintenance, and development versions simultaneously. Related technologies mainly fall into two categories: The first is to sequentially switch between different branches and build serially within a single build environment. This approach minimizes disk duplication but cannot achieve full parallelism, and build outputs, temporary files, and configurations left over from previous branches may contaminate subsequent branches. The second approach involves configuring a complete working directory, independent executor, virtual machine, or container for each branch for parallel building. This approach achieves a certain degree of isolation and parallelism but requires repeatedly saving source code, dependency repositories, build outputs, and runtime environments, increasing disk and environment maintenance costs with the number of branches. The challenge lies in providing complete and isolated build contexts for multiple target branches within the same build environment, without fully copying the source code directory and dependency repositories for each target branch, and executing multiple build tasks in parallel. Therefore, how to securely and efficiently assemble multi-branch products is a pressing technical problem that needs to be solved.

[0037] Furthermore, the embodiments of this application can also address issues such as concurrent write conflicts to shared dependency caches, lack of automatic mapping between difference files and affected modules, and lack of structured traceability records for build results.

[0038] To address the aforementioned technical issues, embodiments of this application provide a method for assembling multi-branch products and an electronic device. The method identifies multiple target branches corresponding to the same product, obtains a read-only source code directory from a code repository as a baseline snapshot of the product, constructs a difference file for each target branch, generates a complete build view of the target branches using the baseline snapshot and the difference file, generates build tasks for each target branch based on the difference file, and executes the build tasks in parallel based on the complete build view. This allows the assembly tasks of multiple target branches to be executed concurrently without interference within the same build environment.

[0039] The specific application environment architecture or hardware architecture upon which the assembly method for multi-branch products depends is described here. (References) Figure 1 , Figure 1 This is a schematic diagram of an assembly system architecture for a multi-branch product provided in an embodiment of this application. The assembly system for this multi-branch product is a computer device. Figure 1 As shown, the above architecture includes at least one of a data acquisition device 101, a processing device 102, and a display device 103.

[0040] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the assembly system architecture of multi-branch products. In other feasible implementations of the embodiments of this application, the above architecture may include more or fewer components than illustrated, or combine some components, or split some components, or arrange different components, which can be determined according to the actual application scenario and is not limited here. Figure 1 The components shown can be implemented in hardware, software, or a combination of both.

[0041] In the specific implementation process, the data acquisition device 101 may include an input / output interface or a communication interface, and the data acquisition device 101 can be connected to the processing device through the input / output interface or the communication interface.

[0042] The processing device 102 can identify multiple target branches corresponding to the same product, obtain a read-only source code directory from the code repository as a baseline snapshot of the product, build a difference file for each target branch, generate a complete build view of the target branch through the baseline snapshot and difference file, generate build tasks for each target branch based on the difference file, and execute the build tasks in parallel based on the complete build view, so that the assembly tasks of multiple target branches can be executed concurrently without interference in the same build environment.

[0043] The display device 103 can also be a touch screen or the screen of a terminal device, used to receive user commands while displaying the above-mentioned content, so as to realize interaction with the user.

[0044] It should be understood that the aforementioned processing device can be implemented by a processor reading instructions from memory and executing those instructions, or it can be implemented by a chip circuit.

[0045] Optionally, Figure 2 This application provides a schematic diagram of the structure of an assembly process, as shown in the embodiment of the present application. Figure 2 As shown, this embodiment of the application sets up a baseline snapshot manager, a branch difference resolver, a build view generator, a shared dependency repository, a parallel build scheduler, an artifact merging and validating unit, and a cleanup and recycling unit in the assembly plant. The baseline snapshot manager maintains a read-only source code directory; the branch difference resolver calculates the added, modified, deleted, and renamed files between the target branch and the baseline snapshot; the build view generator uses the baseline snapshot as the lower layer and the target branch difference as the upper layer, attaching a complete build view to each build task; the parallel build scheduler executes build and dependency management tool commands in different build views; and the artifact merging and validating unit collects build artifact packages, configuration files, and patch manifests and writes them to the artifact validation manifest.

[0046] It should be noted that the baseline snapshot manager, branch difference resolver, build view generator, shared dependency repository, parallel build scheduler, artifact merging and verification unit, and cleanup and recycling unit mentioned in the embodiments of this application are all software functional modules running on the build server. Each software functional module implements its corresponding function when the processor of the build server executes the computer program, and no dedicated hardware circuitry is required. Among them, the shared dependency repository refers to a storage directory managed by the operating system's file system, whose access permissions and concurrent write isolation are controlled by software logic, and is not an independent hardware storage device.

[0047] In this architecture, baseline snapshots are not written, and multiple target branches do not share the upper layer. The build task sees the complete source tree, but only one copy of the baseline source code and several branch difference directories are on disk. After the build is complete, temporary files in the upper layer, except for target artifacts and necessary logs, can be deleted, thereby reducing long-term disk usage.

[0048] Furthermore, the network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0049] Figure 3 A flowchart illustrating the assembly method for multi-branch products provided in this application embodiment is shown below. Figure 3 As shown, an embodiment of this application provides a method for assembling a multi-branch product. The executing entity can be the aforementioned processing device 102. The method is described in detail below:

[0050] S301: Get build request.

[0051] The build request includes product information, version information, and branch information.

[0052] Optionally, a build request may at least identify the product or project, target version, target branch, and target commit number, and may also include information such as build parameters, output type, and resource limits.

[0053] Optionally, the build request serves as input data for the entire assembly process, triggering subsequent target branch identification, baseline snapshot acquisition, difference file extraction, full build view generation, and build task execution.

[0054] Optionally, product information is used to identify the specific software product to be assembled, such as an enterprise management platform, server management program, or a product line in an application system consisting of multiple modules; version information is used to identify the version range, version number, or version tag corresponding to this build, so that the assembly process is limited to the specified version semantics; branch information is used to indicate the set of branches, branch filtering rules, or branch identifier list that need to participate in this assembly, so that the system can determine the target branch accordingly.

[0055] Optionally, a build request can be generated by the user submitting build parameters in the build interface, or it can be automatically generated by a preset scheduling strategy after detecting a version release node, patch merge event, or the arrival of a scheduled build cycle.

[0056] When receiving a build request, the request message can be obtained through the Hypertext Transfer Protocol (HTTP) interface, message queue, command line call, or repository event callback. The product information, version information, and branch information in the request are parsed into a unified internal object and written into the task context.

[0057] In some embodiments, to ensure the execution of subsequent steps, an integrity check is performed on the build request upon receipt. The check includes verifying that the product identifier is not empty, the version identifier conforms to a preset format, and the branch information points to at least one valid branch range. Further checks are performed to verify whether there is an association configuration between the product and the version, and whether the branch information belongs to the repository namespace corresponding to the product. If the build request uses a structured data format, it can be organized into data records containing corresponding product information, version information, and branch information. After successful verification, the build request is persisted to the build task database or caching system, and an acceptance result is returned to the scheduling engine, thereby triggering subsequent processing flows for multiple branches of the same product.

[0058] S302: Based on the build request, determine multiple target branches corresponding to the same product, and obtain baseline snapshots corresponding to the multiple target branches.

[0059] The baseline snapshot is a read-only source code directory determined from the code repository.

[0060] Optionally, first, locate the code repository, repository path, branch naming rules, and version mapping relationship corresponding to the product based on the product information, then determine the set of branches allowed to participate in the build under the current version based on the version information, and then select multiple target branches from the candidate branch set based on the branch information.

[0061] The target branch represents the branch from which artifacts need to be generated in this assembly. Each target branch establishes an independent branch processing context, which records at least the branch name, branch header commit number, baseline reference, diff file extraction status, and subsequent task identifier. The code repository, as the source for storing source code and historical commits, can be a distributed version control system (Git) repository or a data source compatible with object storage version management.

[0062] For each target branch, it is necessary to obtain its corresponding baseline snapshot. The baseline snapshot is used as the base source code directory shared during the build of that target branch. It is essentially a read-only source code directory determined from the code repository and is not directly modified during subsequent builds.

[0063] Optionally, a corresponding baseline snapshot directory can be determined and generated from the code repository based on the correspondence between the build request and the target branch.

[0064] Optionally, to ensure that multiple branches can share the same base without content rewriting when running in parallel, the baseline snapshot directory is set to read-only permissions. The build user only has read and traversal permissions, not write or delete permissions. If multiple target branches correspond to the same base source code content, these target branches can share the same baseline snapshot instance; if the target branches belong to different versions, a baseline snapshot for each version is created separately. This process allows multiple target branches to obtain a stable and consistent view of the base source code without copying the entire source code directory, while also providing a reference object for subsequent diff file calculations.

[0065] S303: Determine the difference file for the target branch based on the baseline snapshot and build request.

[0066] The difference file is a collection of files that represent changes to a target branch relative to its baseline snapshot, and it serves as the direct basis for generating a complete build view and build task. Since product information, version information, and branch information are already provided in the build request, the comparison scope can be limited to the corresponding product and target branch when extracting the difference file, avoiding accidental file extraction across products or versions.

[0067] In one possible implementation, the commit number of the branch header is read for each target branch, and the source tree corresponding to that commit is compared with the source code content corresponding to the baseline snapshot.

[0068] The comparison process can be completed through the difference interface provided by the code repository, or by expanding the corresponding source code content locally and comparing it according to path, file type and content summary.

[0069] In addition to file paths, difference files can also store change information, original path, target path, file checksum, and most recent change commit number.

[0070] If the branch information indicates that multiple target branches are processed in parallel, each target branch outputs an independent list of diff files, which are then persistently saved. This step ensures that the diff content remains consistent with the stable baseline by referencing a baseline snapshot rather than directly comparing to the working directory. This allows for accurate restoration of the target branch's source code state when generating a complete build view and build task.

[0071] S304: Generate a complete build view of the target branch based on the baseline snapshot and difference file.

[0072] Here, the complete build view is used to present the complete source code tree of the target branch to the build tool, so that when the build tool reads the source code, parent configuration, dependency description files and resource files, it perceives a logically complete and self-consistent branch directory, without needing to perceive the underlying baseline reuse and difference synthesis process.

[0073] Optionally, a separate view working directory can be created for each target branch, and the contents of the view working directory can be organized based on the baseline snapshot and the difference file to reflect the complete source code state of the corresponding target branch.

[0074] The generation of a complete build view can be achieved through file composition, directory mapping, virtual view resolution, or other methods that can express a complete source code tree.

[0075] Optionally, a complete build view of the target branch is generated based on the baseline snapshot and the diff file, including: generating a separate upper layer of the target branch based on the diff file; and overlaying the separate upper layer with the baseline snapshot as a read-only lower layer to generate a complete build view.

[0076] Optionally, overlay is implemented through a union file system: the baseline snapshot is mounted as a read-only lower layer, and the independent upper layer is mounted as a writable upper layer; when the build tool reads files in the complete build view, it returns the file content according to the upper-layer priority rule; if the file exists in the independent upper layer, the file content in the independent upper layer is returned; if the file only exists in the baseline snapshot, the read-only file content in the baseline snapshot is returned; if the file is marked for deletion in the independent upper layer, then the file is not visible to the build tool. In this way, the build tool can directly obtain the complete source tree of the target branch without being aware of the underlying file organization.

[0077] Optionally, when there are N target branches, the related technologies that require copying a complete working directory for each branch need to occupy the storage space of N source code directories. However, in this embodiment, the N target branches share the same read-only baseline snapshot and only maintain their own change files in an independent upper layer. The disk usage is approximately the sum of one baseline snapshot and N difference files. The larger the value of N, the more significant the disk saving effect. Here, N is any positive integer.

[0078] This application embodiment generates an independent upper layer for the target branch based on the difference file, and overlays the independent upper layer with the baseline snapshot as a read-only lower layer to generate a complete build view. This allows multiple target branches to share the same read-only baseline snapshot, and each target branch only needs to maintain its own independent upper layer to present a complete source code tree. Compared with the related technologies that copy a complete working directory for each branch, this application embodiment significantly reduces disk space usage. Compared with the related technologies that reuse the same working directory for all branches, the independent upper layers of each target branch in this application embodiment do not interfere with each other, avoiding cross-contamination of build output and temporary files between branches, and ensuring the isolation of the build environment of each branch and the correctness of the build results.

[0079] Optionally, the difference file includes an add type file, a modify type file, a delete type file, and a rename type file. Based on the difference file, an independent parent layer for the target branch is generated, including: when the difference file is an add type file or a modify type file, writing the add or modify content to the independent parent layer; when the difference file is a delete type file, writing a deletion mark or a list of paths to be deleted to the independent parent layer; when the difference file is a rename type file, writing the old path deletion relationship and the new path addition relationship to the independent parent layer.

[0080] Optionally, when the file content of a renamed file remains unchanged, only the deletion relationship of the old path and the addition relationship of the new path need to be recorded in the independent upper level, without copying the file content; when the file content also changes, the path change relationship is recorded simultaneously and the new file content is written to the independent upper level. This method prevents the renaming operation from generating additional file content redundancy, and in conjunction with add and modify operations, ensures that the independent upper level only stores the necessary change information.

[0081] Optionally, when the underlying file system supports deletion markers (i.e., whitelisting mechanism) of the union file system, deletion markers are written in the independent upper layer, making the file invisible in the superimposed complete build view; when the underlying file system does not support deletion markers, the path of the file to be deleted is written into the list of paths to be deleted, and the corresponding path is masked according to the list of paths to be deleted before or during the generation of the complete build view. The above method enables the embodiments of this application to adapt to the differences in capabilities of different file systems.

[0082] This application's embodiments classify and process difference files, employing different writing strategies for four difference types: addition, modification, deletion, and renaming. For additions or modifications, only the changed content is written to an independent upper layer. For deletions, a deletion marker or a list of paths to be deleted is written to the independent upper layer instead of actually deleting the baseline file. For renamings, the path change relationship is recorded in the independent upper layer instead of copying the file content. This approach ensures that only necessary change information is stored in the independent upper layer, avoiding the complete copying of unchanged files. When multiple target branches maintain their own independent upper layers, the amount of difference data in each branch remains at a minimum, thereby further reducing overall disk usage while ensuring the integrity of the views built by each branch.

[0083] Specifically, when the build tool accesses a path, the system returns the corresponding content based on a combination of baseline snapshots and difference files, thus restoring the complete directory structure of the target branch without having to copy the entire source code. For projects containing parent project configurations, public resource directories, and script directories, the complete build view must ensure that these critical paths are logically accessible. Therefore, after generating the complete build view, a directory integrity check can be performed to check the existence of aggregate build files, module manifests, build script entry points, and necessary resource directories. For scenarios where multiple target branches are assembled in parallel, each target branch establishes its own complete build view, but the corresponding baseline snapshot can be reused, thereby reducing disk usage. This step ensures that the build tool always executes in a complete source code context, without relying on incomplete incremental directories, thus correctly resolving parent configurations, public resources, and module dependencies.

[0084] In one possible implementation, the branch construction view generation method of this application embodiment includes the following steps:

[0085] Step 4.1: Obtain the target commit number of the target branch and compare it with the baseline commit number corresponding to the baseline snapshot to obtain a list of difference files of the target branch relative to the baseline snapshot.

[0086] Step 4.2: For newly added and modified files, write the file content corresponding to the target commit number from the code repository to the independent parent directory of the target branch.

[0087] Step 4.3: For deleting files, write a deletion tag that the union file system can recognize in the independent parent directory; in file systems that do not support this tag, write the path to be deleted into the exclusion list, and block the corresponding path according to the exclusion list before or when generating the complete build view.

[0088] Step 4.4: For renamed files, record the deletion relationship of the old path and the addition relationship of the new path respectively; if the file content has not changed, the independent upper layer only retains the associated data required for the path change and reuses the original file content in the baseline snapshot.

[0089] Step 4.5: Create a complete build view of the target branch. Specifically, mount the baseline snapshot as a read-only lower layer and the independent upper layer as a writable upper layer, and set the working directory to generate a complete build view. In systems that do not support union file mounting, use file-level hard link copies, copy-on-write copies, or content-addressed storage to overlay the read-only lower layer and the independent upper layer, but ensure that the sharing relationship is broken before writing, and do not directly write to the shared file in place.

[0090] Step 4.6: Mark the complete build view as the build context of the target branch, and write the capacity of the independent upper layer, the number of difference files, and the mount parameters into the build manifest.

[0091] Accordingly, Figure 4 This application provides a schematic diagram illustrating the relationship between a branch construction view and a writable overlay, as shown in the embodiments of this application. Figure 4 As shown in the embodiments of this application, multiple target branches share the same read-only baseline snapshot and shared dependency repository. Each target branch maintains its own independent writable upper layer (including new files, modified files and deletion marks), overlay working directory, independent output directory and independent dependency repository upper layer for its own build task. The writable storage space between different target branches is not shared, thereby achieving environment isolation and low redundancy storage when building multiple branches in parallel.

[0092] Optionally, the shared dependency repository can be a local dependency repository, or an edge cache of a private dependency management service or internal artifact repository. If a remote repository is used, an independent write layer can still be set up locally for each build task to avoid incomplete file pollution during concurrent downloads.

[0093] Specifically, a complete source code build view is formed by combining a read-only baseline snapshot, the target branch difference layer, and the overlay working directory. Each target branch's independent upper layer and independent output directory only store the difference files and build outputs relative to the baseline for that branch; writable storage space is not shared between branches. Each build task's independent dependency repository upper layer only stores newly downloaded dependencies and temporary files for that task; after the task completes, only verified dependencies are promoted to the shared cache. Through this approach, this embodiment of the application ensures the isolation of the build environment for each branch while keeping disk usage to the sum of a single baseline snapshot, branch difference files, shared dependency cache, and newly added dependencies for each task, avoiding the need to fully copy the source code directory and the dependency repositories corresponding to the build and dependency management tools for each branch.

[0094] Optionally, the key point of the execution process in steps 4.1 to 4.6 above is that the complete source code tree of the target branch is not formed by a full copy command, but by superimposing the differences between the read-only baseline snapshot and the target branch. The build tool is unaware of the above superposition process and still reads the project configuration files, source code directory, resource directory and configuration files according to the conventional project structure. It does not need to be aware of the underlying file organization method to obtain the complete build context.

[0095] S305: Generate a build task for the target branch based on the difference file.

[0096] Among them, the build task represents the specific build work unit that needs to be executed for a certain target branch. Its generation process takes the difference file as the core input and combines the project build configuration and product type to determine the final task content.

[0097] Optionally, first read the list of difference files for the target branch, and determine the corresponding build content based on the scope of changes reflected in the difference files.

[0098] Optionally, the data structure of a build task may include a task identifier, its target branch, the complete build view path, the content to be executed, the execution command, and the output directory. The execution command can be generated based on the product build system, for example, by generating a command line according to the project entry point and execution mechanism of the corresponding build tool.

[0099] Optionally, if multiple build tasks belong to the same target branch and have sequential dependencies, corresponding dependencies are established between the tasks, and the scheduler triggers them sequentially; if there are no dependencies between the tasks, they are marked as parallelizable. After the build task is generated, the executing entity submits the task information to the scheduling queue and establishes a mapping relationship between the difference file and the task identifier, so as to locate the scope of changes that trigger the task later. Based on the above analysis, this step, by mapping the difference file to the corresponding build action, ensures that the build coverage corresponds to the actual change scope and makes the subsequent parallel build process schedulable.

[0100] In this embodiment, the complete build view provides a static source code view of the target branch, while the build task provides the dynamic build instructions to be executed. This separation allows the complete build view to be reused by multiple build tasks, and enables build tasks to be independently scheduled, retried, and expanded without re-preparing the source code environment. This improves the flexibility and resource utilization of multi-branch parallel assembly.

[0101] S306: Based on the complete build view, execute build tasks in parallel to generate the assembly artifacts of the target branch.

[0102] After generating the complete build view and build tasks, the scheduler allocates an execution instance for each target branch and starts the task execution process on the corresponding complete build view. Since the complete build view presents a logically complete source code tree to the build tools, there is no need to additionally copy the baseline source code or manually concatenate the difference directories during execution. During parallel execution, different target branches use their respective complete build view paths and task working directories, thus making the build processes of each branch independent of each other.

[0103] Optionally, for multiple target branches under the same product, the scheduler can distribute build tasks to multiple build nodes according to available computing resources, or run multiple task processes on the same build node.

[0104] In some embodiments, during execution, the build tool reads the parent configuration file, module manifest, public resources and source code files from the complete build view, and performs compilation, dependency resolution, test skipping or execution, module packaging and artifact archiving according to the task description.

[0105] Alternatively, the assembly artifacts can be executable installers, binary distributions, container image build contexts, compressed archives, or collections of module-level artifacts.

[0106] Optionally, during output, the results of each target branch are written to the corresponding product directory, recording the product name, version number, branch identifier, corresponding task identifier, and generation time. If a parallel task fails, only the failure status is recorded in the context of the corresponding target branch, without affecting the continued execution of other target branch tasks; the build status and assembly product information are summarized uniformly after all tasks are completed. This step achieves the coexistence of sharing and reusing the same basic source code snapshot and isolating branch differences by executing the corresponding tasks of each target branch in parallel on the complete build view. This allows for the maintenance of a complete build context in multi-branch scenarios while outputting the assembly products of each target branch without retaining multiple complete source code directories.

[0107] Optionally, based on the complete build view, build tasks are executed in parallel, including: generating task description information for the target branch; wherein the task description information includes identification information and resource control description information; the identification information includes at least one of task identification description information, source code version description information, and execution context information; obtaining the status information of the parallel scheduler. Based on the resource control description information and status information, the number of tasks to be executed concurrently is determined; based on the number of tasks, the scheduler is controlled to execute the build tasks in parallel according to the identification information.

[0108] The build task is executed within the corresponding complete build view. Status information includes hardware resource information and / or task load information.

[0109] Optionally, task description information is created during the generation of build tasks, serving as structured data for the scheduler to identify, queue, allocate resources, and execute build tasks. Each task description corresponds one-to-one with a build task and is stored in the scheduling queue or task database. The scheduler distinguishes build tasks for different target branches based on the identification information in the task description information and allocates corresponding computing resources to each build task based on the resource control description information.

[0110] It should be noted that task load information refers to at least one of the following: the number of build tasks currently being executed, the amount of resources used by each executing task (including CPU utilization, memory usage, disk read / write speed, etc.), and the number of tasks waiting to be executed in the scheduling queue. The scheduler uses task load information to determine the current idle level of the system and adjusts the number of concurrently executed tasks accordingly to avoid exhausting system resources.

[0111] This application's embodiments generate task description information containing identification information and resource control description information, enabling each build task to carry a unique identifier and resource requirements. By acquiring the scheduler's hardware resource information and / or task load information, the scheduler can perceive the system status in real time. By comprehensively considering the resource control description information and status information, the number of tasks to be executed concurrently is determined, ensuring that concurrency decisions take into account both task requirements and system capabilities, avoiding resource contention and system overload. By binding build tasks to their corresponding complete build views based on the identification information, each task is executed within its respective build view, achieving source code environment isolation. These methods enable the scheduler to rationally allocate computing resources, achieving parallel execution while ensuring that each build task does not interfere with others, thus improving the resource utilization efficiency and execution security of multi-branch parallel assembly.

[0112] Optionally, the control scheduler executes build tasks in parallel based on the identification information, including: the control scheduler generating isolation items based on the identification information; and the control scheduler executing build tasks in parallel based on the isolation items.

[0113] The isolation items include at least one of the following: build output directory, temporary file directory, dependency repository write layer, log file, and process group.

[0114] This application embodiment generates isolation items for each build task based on identification information, enabling each build task to have an independent build output directory, temporary file directory, dependency repository writing layer, log file, and process group. The output artifacts, temporary files, dependency downloads, log records, and process resources of different build tasks are physically or logically isolated from each other, avoiding the overwriting of build outputs from different branches, cross-contamination of temporary files, dependency download conflicts, and log confusion. When a single build task terminates abnormally or exceeds resource limits, it does not affect the normal execution of other tasks, thus improving the stability and reliability of multi-branch parallel assembly.

[0115] Optionally, a dedicated dependency repository view is used during build task execution. This view is generated by overlaying a shared read-only lower layer and a write layer independent of the build task. Specifically, to avoid conflicts caused by multiple build tasks simultaneously writing data to the same dependency repository, this embodiment does not directly point all build tasks to the same writable dependency repository directory. Instead, it uses the shared dependency repository as a read-only lower layer, allocates an independent dependency repository write layer and a temporary working directory to each build task, and overlays the read-only lower layer and the independent dependency repository write layer to form a dependency repository view unique to that build task.

[0116] The shared dependency repository stores verified stable dependencies; the independent dependency repository write layer stores newly downloaded dependencies or temporary files for this build task; and the dependency repository view shows the actual paths used by the build tool. After the build task is completed, the artifact merging validator only promotes the verified, non-temporary, and non-downloading dependency files to the shared dependency repository; the remaining files are cleaned up with the build task. This approach allows for the reuse of public dependencies while preventing temporary files from overwriting or conflicting with each other in concurrent scenarios.

[0117] Optionally, the dependency repository view is implemented via a union file system mount: the shared dependency repository is mounted as a read-only lower layer, and the dependency repository write layer independent of the build task is mounted as a writable upper layer, with a temporary working directory set to generate the dependency repository view. The build tool points to the dependency repository view by specifying path parameters and performs dependency resolution and download operations; newly downloaded dependencies and temporary files are automatically written to the writable upper layer without affecting the read-only lower layer. After the build task is completed, the dependency repository view is unmounted, the mount point is released, and based on the verification results, it is determined whether to promote the dependencies in the writable upper layer to the shared dependency repository.

[0118] Optionally, after a build task completes, the cleanup reclaimer performs the following operations: unloads the complete build view and dependency repository view corresponding to the build task; deletes the temporary working directory of the build task, temporary files in the build output directory, and files that fail validation in the dependency repository write layer; archives the log files and build manifest of the build task to a specified storage location; and releases the process group and resource control configuration occupied by the build task. Through the above cleanup mechanism, temporary files from each build task are prevented from occupying disk space for extended periods, keeping disk usage at a low redundancy level.

[0119] Optionally, based on the complete build view, build tasks are executed in parallel, including: generating task description information for each target branch, wherein the task description information includes at least one of the following: project name, target branch, baseline commit number, target commit number, build view path, dependency repository view path, build manifest path, artifact output path, and resource constraint information.

[0120] Optionally, the build view path is used by the build tool to read source code, and the dependency repository view path is used by the build tool to read and write dependency files. Both are logical view paths during the build task runtime. When executing the build command, the build tool specifies the build view path as the working directory and the dependency repository view path as the dependency repository path through parameters. This allows the build tool to write data to the independent upper layer of the complete build view and the independent writing layer of the dependency repository view while reading the complete source code tree and the complete dependency repository, thereby achieving dual isolation of source code and dependencies during the build process.

[0121] Optionally, the scheduler sets the concurrency level based on at least one of the following: number of CPU cores, disk I / O capacity, memory capacity, and number of modules. For example, on a build server with 16 cores and 64GB of memory, three target branches may be allowed to execute build tasks concurrently, with each build task using a limited number of threads to avoid I / O saturation that could slow down the overall process.

[0122] Optionally, when determining the number of concurrent tasks, the scheduler first obtains the number of available CPU cores, available memory capacity, and disk I / O capacity of the current build server. Then, based on the resource control description information in each build task description, it calculates the theoretical resource consumption of each task. The maximum concurrency is obtained by dividing the total available resources by the theoretical resource consumption of a single task, and then dynamically adjusts the scheduler based on the current task load information. For example, on a build server with 16 cores and 64GB of memory, if each build task declares that it requires 4 cores and 8GB of memory, the scheduler can allow 3 build tasks to be executed concurrently. When the current task load of the system is high, the scheduler reduces the concurrency accordingly to avoid system overload.

[0123] Optionally, the scheduler also sets the following isolation items: an independent build output directory and temporary file directory for each build task; an independent dependency repository write layer for each build task; an independent log file and build manifest for each build task; and an independent process group for each build task, which, if necessary, limits at least one of the CPU, memory, and disk write rates through resource control mechanisms.

[0124] In response to a build request, this embodiment identifies multiple target branches corresponding to the same product. A read-only source code directory is retrieved from the code repository as a baseline snapshot of the product, allowing multiple target branches to share the same read-only source code base. Then, a difference file is built for each target branch. Finally, a complete build view of the target branch is generated using the baseline snapshot and the difference file. This allows each target branch to obtain a complete build environment by storing only the difference file, further reducing redundant storage. Build tasks for each target branch are generated based on the difference file, and these tasks are executed in parallel based on the complete build view. This enables the assembly tasks of multiple target branches to be executed concurrently without interference within the same build environment. Through this method, while achieving parallel assembly of multiple branches, disk resource consumption is effectively reduced, assembly efficiency is improved, and safe and efficient multi-branch product assembly is realized.

[0125] Optionally, after executing build tasks in parallel based on the complete build view to generate the assembly artifacts of the target branch, the method further includes: reading the build artifact catalog in the build view to obtain the assembly artifacts; generating an artifact verification list; wherein the artifact verification list includes at least one of the following: the identification information of the target branch, the target commit number of the target branch, the identification information of the baseline snapshot, the verification value of the assembly artifacts, and the fingerprint of the build environment; and associating and outputting the assembly artifacts and the artifact verification list.

[0126] In one possible implementation, after the build is complete, the artifact merge verifier reads the build output directory of the target module from each build view and copies the build artifact package, configuration file, database script and patch description file to a unified artifact directory, for example, archived according to the directory structure of "product / version / branch".

[0127] Simultaneously, a product verification list is generated. This list can be in a structured data format (such as JS object notation format) and includes one or more of the following information:

[0128] Product name, product version, target branch, and target commit number are used to uniquely identify the product and source code version corresponding to this assembly.

[0129] The baseline commit number, baseline snapshot number, and view mounting parameters are used to trace the baseline source code snapshot and view composition method on which this assembly is based;

[0130] The number of difference files, the list of affected modules, and the actual build commands executed are used to record the scope of changes and the actual execution content of this assembly.

[0131] Output the name, file size, checksum, and generation time of the output package to verify its integrity and uniqueness.

[0132] The build environment fingerprint, including the programming language runtime version, build tool version, build configuration file summary, operating system information, and build script version, is used to record the runtime environment in which this assembly takes place.

[0133] This verification checklist can be written into the patch package directory or the build platform page, and stored or displayed in association with the assembled product for subsequent source tracing, integrity auditing and ownership determination of the assembled product.

[0134] This application's embodiments generate a product verification list and associate the assembled products with it, ensuring that each assembled product carries complete identity information. The target branch identifier, target commit number, and baseline snapshot identifier recorded in the product verification list accurately trace the source branch and source code version of the assembled product. Recorded product verification values ​​can be used to verify whether the product has been tampered with or damaged during delivery and deployment, ensuring the product's integrity and reliability. Recorded build environment fingerprints allow for rapid root cause location in case of environment-related issues, providing a basis for troubleshooting. The associated output of the product verification list and the assembled products provides a complete and traceable chain of evidence for the assembly results of multi-branch products, enhancing the reliability and verifiability of the assembly results and improving data integrity.

[0135] Optionally, after executing build tasks in parallel based on the complete build view, cleanup and exception rollback steps are also included.

[0136] In one possible implementation, once a target branch is successfully built, the cleanup recycler unloads the complete build view corresponding to that branch, deletes the view working directory, the union file system working directory, the temporary file directory, and the unarchived build output temporary files, and only retains the necessary difference file summary, build manifest, artifact checklist, and build log in the independent upper layer corresponding to that branch for subsequent traceability and auditing.

[0137] When a target branch fails to build, the system retains the complete build view mount information and independent parent directory of that branch, without immediately performing cleanup operations, so that developers can access the site to reproduce the cause of the failure; after the preset retention period, the system automatically reclaims the storage resources of the failed site.

[0138] In another possible implementation, the system automatically degrades the build mode from incremental to full build when one of the following conditions occurs: the degraded full build still reuses the baseline snapshot, independent upper-level and isolated dependency repository views, and does not switch to the traditional full copy of the working directory: cross-module build configuration files undergo extensive changes, making it difficult to accurately locate the affected module range; module dependency graph parsing fails, making it impossible to correctly determine the dependencies between modules; the proportion of the number of difference files to the total number of files in the source code directory exceeds a preset threshold, and the cost difference between incremental and full builds is no longer significant; the commit difference between the target branch and the branch corresponding to the baseline snapshot is too large, and the difference cardinality exceeds the safe incremental range; during the build process, plugins dynamically generate or modify files in the source code directory, making it impossible for incremental builds to predict the entire source code state.

[0139] This rollback mechanism ensures that the correctness of the build result is prioritized when incremental build cannot be safely performed in the embodiments of this application, and that modules that may be affected are not forcibly skipped when the scope of impact cannot be reliably determined, while still maintaining a low-redundancy directory mechanism.

[0140] Step S302 will be described below with reference to specific embodiments:

[0141] Optionally, obtaining baseline snapshots corresponding to multiple target branches includes: determining the baseline commit number of the target branch based on the build request; matching the baseline commit number in the code repository to obtain the corresponding baseline snapshot; wherein the code repository includes a mapping relationship between the baseline commit number and the read-only source code directory.

[0142] This application embodiment determines the baseline commit number of the target branch based on the build request and matches it in the code repository to obtain the corresponding baseline snapshot. The code repository stores a mapping relationship between baseline commit numbers and read-only source code directories, allowing multiple target branches to obtain their respective baseline snapshots while sharing the same read-only source code directory. Through the pre-established mapping relationship, the initialized read-only source code directory can be quickly located and obtained without repeatedly pulling and expanding the source code tree, thus improving the efficiency of baseline snapshot acquisition. Simultaneously, since the baseline snapshot is a read-only source code directory, multiple target branches can securely share the same baseline data, preventing data inconsistency due to concurrent access, thereby ensuring the consistency and stability of baseline data during parallel assembly of multiple branches.

[0143] Optionally, before matching in the code repository based on the baseline commit number to obtain the corresponding baseline snapshot, the method further includes: creating an object pool and a baseline directory; obtaining multiple baseline commit numbers to be initialized; pulling the code objects corresponding to the baseline commit numbers from the code repository to the object pool, and expanding the source code tree corresponding to the baseline commit numbers to the baseline directory; setting the baseline directory to read-only to form a read-only source code directory; parsing the build configuration file corresponding to the read-only source code directory to generate a module dependency graph; downloading stable dependencies to a shared dependency repository based on the module dependency graph, so that the shared dependency repository can be reused by multiple build tasks as a read-only lower layer; and generating a baseline file fingerprint table based on the read-only source code directory and the module dependency graph to map the difference files to the corresponding modules.

[0144] Optionally, before matching the baseline commit number in the code repository to obtain the corresponding baseline snapshot, a baseline snapshot initialization step is included. Specifically, taking a project as an example, the baseline snapshot can be selected from the commit number of the most recent stable release branch. The initialization process is as follows:

[0145] Step 5.1: Create a read-only object pool and a baseline directory on the build server.

[0146] Step 5.2: Pull the code object from the code repository to the object pool, and expand the source code tree corresponding to the baseline commit number to the baseline directory; after expansion, set the baseline directory to read-only to avoid accidental modification during subsequent builds.

[0147] Step 5.3: Parse the root build configuration file and the build configuration files of each submodule in the baseline directory to generate a module dependency graph. The module dependency graph is used to record module identifiers, module relative paths, parent-child module relationships, internal dependencies, and plugin influence scope.

[0148] Step 5.4: Warm up the shared dependency repository. For the branch corresponding to the baseline snapshot, execute the offline dependency retrieval command or dependency resolution command to download stable dependencies to the shared dependency directory. The shared dependency directory serves as a read-only lower layer for multiple build tasks to reuse during normal builds.

[0149] Step 5.5: Generate a baseline file fingerprint table, recording the file path, file size, file modification time, file checksum, module, and file type. The baseline file fingerprint table is used for subsequent difference analysis and build manifest generation.

[0150] It's important to note that the object pool is a local storage area on the build server used to store all code objects in the code repository. Multiple baseline snapshots can share code objects from the same object pool, eliminating the need to store a separate complete copy of the code repository for each baseline snapshot. The module dependency graph is a directed graph structure generated from the module and dependency declarations in the build configuration file. It represents the parent-child relationships, internal dependencies, and plugin influence scope between modules and can be stored as a structured data file for quick subsequent lookups. The baseline file fingerprint table is an index structure that records the metadata of each file in the baseline snapshot. It is used to quickly map difference files to their corresponding modules during subsequent difference resolution.

[0151] This application embodiment achieves batch initialization and preprocessing of baseline snapshots by pre-executing initialization steps. By pre-expanding the source code tree, pre-parsed the module dependency graph, pre-downloaded stable dependencies, and pre-generated a file fingerprint table, this embodiment enables multiple target branches to reuse the same baseline data, dependencies, and file indexes during the construction process, eliminating the need for repeated fetching, parsing, and downloading. This improves the overall efficiency of parallel assembly of multiple branches, while the read-only attribute ensures the stability and security of the baseline data.

[0152] The following explanation of step S305 is based on a specific embodiment:

[0153] Optionally, based on the diff file, a build task for the target branch is generated, including: obtaining a module dependency graph; determining the directly affected modules by the diff file based on the diff file and the module dependency graph; adding upstream modules that depend on the directly affected modules to the build set based on the module dependency graph to form a dependency closure; generating a build manifest based on the directly affected modules and the dependency closure; and generating a build task based on the build manifest.

[0154] Optionally, based on the diff file, a build task for the target branch is generated, including the following steps:

[0155] Step 6.1: Classify the difference files according to the baseline file fingerprint table and module dependency graph.

[0156] Step 6.2: If the difference file is located in the source code directory, test directory, resource directory, or configuration directory of a module, then mark that module as the directly affected module.

[0157] Step 6.3: If the difference file is the root build configuration file, parent build configuration file, common plugin configuration, build tool configuration template, or build script, then add all modules affected by this configuration to the candidate set; if the scope of impact cannot be reliably determined, then mark the build mode as the full safe build mode.

[0158] Step 6.4: If the difference file is a public interface, public data object, public configuration class, or utility class that is depended on by multiple modules, then search upwards along the module dependency graph and add the upstream modules that depend on this module to form a dependency closure.

[0159] Step 6.5: If the difference file is only a document, comment, description file, or a test case that does not enter the build artifacts, then add the file to the log list, but do not trigger the main build module.

[0160] Step 6.6: Generate a structured build manifest, which includes the target branch, baseline commit number, target commit number, diff file, directly affected modules, extended dependent modules, build command, and rollback reason.

[0161] Step 6.7: Generate build commands based on the structured build manifest; if the build mode is full safe build mode, then perform a full build, but still reuse the complete build view and isolated dependency repository view to avoid copying the entire working directory.

[0162] Optionally, Figure 5 This application provides a schematic diagram of a process for generating a build manifest from a difference file, as illustrated in the embodiments of this application. Figure 5 As shown, the process of steps 6.1 to 6.7 above can be summarized as follows: receive the target branch and target commit number; execute the difference comparison command to obtain the list of difference files; query the baseline file fingerprint table to determine the file type and module to which it belongs; parse the module dependency graph to generate directly affected modules; extend the dependency closure along the dependency graph to obtain candidate build modules; determine whether to trigger the full safe build mode; generate a structured build manifest; execute the build command and output the product verification list and product verification value.

[0163] This application's embodiments obtain a module dependency graph, determine the directly affected modules based on the difference file and the module dependency graph, search upwards along the dependency graph to form dependency closures, and generate a build manifest and build tasks accordingly. The module dependency graph accurately locates the changed modules, avoiding the time wasted on a full build; by adding upstream dependent modules to the build set to form dependency closures, it ensures the complete propagation of the change's impact along the dependency relationships, avoiding the risk of inconsistent artifacts; by generating a build manifest and generating build tasks based on the build manifest, the build process becomes traceable and reproducible. The above method, while ensuring the correctness of the build results, limits the build scope to the actually affected modules and their dependent closures, reducing unnecessary compilation and packaging operations and improving the efficiency of multi-branch parallel assembly.

[0164] This application's embodiments reduce serial waiting time by executing build tasks in parallel for multiple code branches of the same product within a single build environment; by sharing the same read-only baseline snapshot for multiple target branches, it avoids completely copying the source code directory and dependency repositories for each target branch, only occupying extra space for difference files, build outputs, and necessary metadata; by setting independent write layers, build output directories, and temporary file directories for each build task while sharing dependency caches, it avoids mutual pollution from concurrent builds; by automatically generating a build manifest based on the differences between the target branch and the baseline snapshot, it only builds the affected modules and their dependent closures, and automatically degrades to a full build when it cannot be safely determined, achieving incremental builds while ensuring build correctness; by generating a traceable artifact verification list, the build process can be reviewed through the build interface, logs, installer metadata, or build manifest.

[0165] To more clearly illustrate the beneficial effects of the embodiments of this application, a specific example is described below.

[0166] Suppose a project consists of six build modules: Module 1, Module 2, Module 3, Module 4, Module 5, and Module 6. The baseline snapshot directory is approximately 18GB, and the shared dependency cache is approximately 9GB. The first target branch modifies the computation logic of Module 3, the second target branch modifies the public response object in Module 1, and the third target branch modifies the packaging configuration of Modules 5 and 6.

[0167] Traditionally, if a complete working directory is copied to each of the three branches, the source code copy would be approximately 54GB, and each branch would also generate its own build output directory and temporary files. Using the solution described in this application, an 18GB baseline snapshot is maintained on disk, the independent parent directories of the three branches total approximately 4GB, and the three tasks share a 9GB dependency cache, saving only newly added dependencies and build outputs in their respective write layers. The scheduler can execute the three build tasks simultaneously. The second target branch builds the first module and its dependencies (the second, third, and fifth modules) due to changes in common modules; the first target branch only builds the third module and its necessary dependencies; and the third target branch builds the fifth and sixth modules. After the three build tasks are completed, corresponding artifact verification lists and patch packages are generated.

[0168] Furthermore, using a sample project containing 6 build modules, a baseline source code directory of approximately 18GB, shared dependencies of approximately 9GB, and three branches released simultaneously, the following metrics can be used for evaluation. This data is used to illustrate the calculation method; the actual effect will vary with the number of modules, the proportion of differences, the dependency cache hit rate, and disk performance.

[0169] Traditional single-environment sequential build: The total build time for three branches is about 140 to 170 minutes, the source code and build directory occupy about 27 to 35 GB, the required number of build environments is 1, and the average rework scope after failure usually requires rerunning the full build of the current branch. The cross-version adaptation method is to manually switch branches and check residual files.

[0170] Traditional multi-environment parallel build: The total build time for three branches is about 55 to 75 minutes, the source code and build directory occupy about 75 to 100 GB, and the number of build environments required is 3. On average, the rework scope after failure only affects a single environment, but the environment maintenance cost is high. The cross-version adaptation method maintains dependencies, runtime environment and scripts for each environment separately.

[0171] The implementation scheme of this application is as follows: the total build time of the three branches is about 40 to 55 minutes, the source code and build directory occupy about 31 to 45 GB, the required number of build environments is 1 set, and the average rework scope after failure is to retain the independent upper layer and build list of the failed branch, and to retry according to the affected modules. The cross-version adaptation method is to uniformly manage the baseline snapshot, branch overlay and shared dependency cache.

[0172] Compared to traditional single-environment sequential builds, the embodiments of this application primarily save waiting time; compared to traditional multi-environment parallel builds, the embodiments of this application primarily reduce duplicate source code copies and duplicate dependency repositories. Because the embodiments of this application retain a full rollback mechanism, build correctness can still be guaranteed under complex change scenarios.

[0173] The embodiments of this application can be applied to the following scenarios:

[0174] The same software product has multiple long-term maintenance branches, requiring multiple patch packages to be output within the same release window.

[0175] Research and development testing requires simultaneous verification of multiple customer site versions, but the disk space on the build server is limited.

[0176] Multiple products within the company share some build modules and dependencies, so it is necessary to reduce duplicate downloads and builds.

[0177] Private delivery projects need to retain the outgoing package list, build commands, and artifact verification values ​​for easy auditing later.

[0178] The technical effects of this application can be achieved through the following solutions:

[0179] A method for generating a complete build view based on a read-only baseline snapshot and a writable overlay of the target branch. This method does not require a full copy of the target branch's working directory; instead, it presents the complete source tree by overlaying difference files.

[0180] A method for generating a build manifest based on version control system diff files, baseline file fingerprint tables, and module dependency graphs. This manifest includes directly affected modules, dependency closures, fallback conditions, and the actual build commands.

[0181] A shared dependency caching isolation method for local dependency repositories. Shared dependencies are treated as a read-only lower layer, with each build task having its own independent write layer. Only validated dependency files are promoted after the build is complete.

[0182] A multi-branch parallel build scheduling method. The scheduler creates tasks based on the build view, repository view, module manifest, and resource constraints, and achieves isolation through independent build output directories, temporary directories, logs, and process groups.

[0183] Product verification checklist generation method. This checklist binds the product version, target branch, baseline snapshot, difference file, build command, output package checksum, and environment fingerprint for traceability and external forensics.

[0184] Anomaly rollback mechanism. When the scope of a module's impact cannot be safely determined or the difference ratio exceeds a threshold, the system automatically performs a full safe build, but still reuses baseline snapshots and isolation caches to ensure correctness takes priority.

[0185] Figure 6 This is a schematic diagram of the assembly apparatus for multi-branch products provided in an embodiment of this application. Figure 6 As shown in the embodiments of this application, an assembly device for multi-branch products is also provided. The device includes: a first acquisition module 601, a second acquisition module 602, a determination module 603, a first generation module 604, a second generation module 605, and a third generation module 606.

[0186] The first acquisition module is used to acquire build requests; the build requests include product information, version information, and branch information.

[0187] The second acquisition module is used to determine multiple target branches corresponding to the same product based on the build request, and to acquire baseline snapshots corresponding to the multiple target branches; wherein, the baseline snapshot is a read-only source code directory determined from the code repository;

[0188] The determination module is used to determine the difference files for the target branch based on the baseline snapshot and build request;

[0189] The first generation module is used to generate a complete build view of the target branch based on the baseline snapshot and the difference file;

[0190] The second generation module is used to generate the build task for the target branch based on the difference file;

[0191] The third generation module is used to execute build tasks in parallel based on the complete build view to generate the assembly artifacts of the target branch.

[0192] In one possible embodiment, the first generation module is specifically used for:

[0193] Based on the difference file, generate an independent upper level for the target branch;

[0194] Use the baseline snapshot as a read-only lower layer and overlay it with an independent upper layer to generate a complete build view.

[0195] In one possible embodiment, the difference files include new type files, modified type files, deleted type files, and renamed type files;

[0196] The first generation module is also specifically used for:

[0197] When the difference file is a new type file or a modified type file, the new or modified content will be written to the independent upper layer.

[0198] When the difference file is a deletion type file, write a deletion mark or a list of paths to be deleted in a separate upper level;

[0199] When the difference file is a rename type file, write the old path deletion relationship and the new path addition relationship in the independent upper level.

[0200] In one possible embodiment, the third generation module is specifically used for:

[0201] Generate task description information for the target branch; wherein, the task description information includes identification information and resource control description information; the identification information includes at least one of task identification description information, source code version description information, and execution context information;

[0202] Obtain the status information of the parallel scheduler; whereby the status information includes hardware resource information and / or task load information;

[0203] The number of tasks to be executed concurrently is determined based on resource control description information and status information;

[0204] Based on the number of tasks, the control scheduler executes build tasks in parallel according to the identification information; the build tasks are executed in the corresponding complete build view.

[0205] In one possible embodiment, the third generation module is specifically used for:

[0206] The control scheduler generates isolation items based on the identification information; the isolation items include at least one of the following: build output directory, temporary file directory, dependency repository write layer, log file, and process group;

[0207] The control scheduler executes build tasks in parallel based on the isolation items.

[0208] In one possible embodiment, the second generation module is specifically used for:

[0209] Obtain the module dependency graph;

[0210] Based on the difference file and module dependency graph, identify the directly affected modules that are affected by the difference file;

[0211] Based on the module dependency graph, the upstream modules of the modules directly affected by the dependencies are added to the build set to form a dependency closure;

[0212] Generate a build manifest based on the directly affected modules and dependent closures;

[0213] Build tasks are generated based on the build manifest.

[0214] In one possible embodiment, the second acquisition module is specifically used for:

[0215] Based on the build request, determine the baseline commit number of the target branch;

[0216] Based on the baseline commit number, a match is made in the code repository to obtain the corresponding baseline snapshot; the code repository includes a mapping relationship between the baseline commit number and the read-only source code directory.

[0217] In one possible embodiment, before the second acquisition module is used to match the baseline commit number in the code repository to obtain the corresponding baseline snapshot, an initialization module is also included, which is used to:

[0218] Create an object pool and baseline directory;

[0219] Retrieve multiple baseline commit numbers to be initialized;

[0220] Pull the code object corresponding to the baseline commit number from the code repository to the object pool, and expand the source code tree corresponding to the baseline commit number to the baseline directory;

[0221] Set the baseline directory to read-only to create a read-only source code directory;

[0222] Parse the build configuration file corresponding to the read-only source code directory to generate a module dependency graph;

[0223] Based on the module dependency graph, stable dependencies are downloaded to the shared dependency repository, which is then used as a read-only lower layer for multiple build tasks to reuse.

[0224] Based on the read-only source code directory and module dependency graph, a baseline file fingerprint table is generated to map the differences to the corresponding modules.

[0225] In one possible embodiment, after the third generation module performs build tasks in parallel based on the complete build view to generate the assembly artifact of the target branch, a verification module is also included, for:

[0226] Read the build artifacts catalog in the build view to obtain the assembly artifacts;

[0227] Generate a product verification list; wherein the product verification list includes at least one of the following: the identification information of the target branch, the target commit number of the target branch, the identification information of the baseline snapshot, the verification value of the assembled product, and the fingerprint of the build environment;

[0228] The assembled product and the product verification list are output together.

[0229] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 7 As shown, the electronic device 70 provided in this embodiment includes at least one processor 701 and a memory 702. In one possible implementation, the electronic device 70 further includes a communication component 703. The processor 701, memory 702, and communication component 703 are connected via a bus.

[0230] In a specific implementation, at least one processor 701 executes computer execution instructions stored in memory 702, causing at least one processor 701 to execute the above-described embodiment of the reasoning method for assembling or modeling multi-branch products.

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

[0232] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

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

[0234] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings of this application's embodiments are not limited to only one bus or one type of bus.

[0235] An embodiment of this application also provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the above-described embodiments of the reasoning method for assembling or modeling any of the multi-branch products when it is run.

[0236] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0237] An embodiment of this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps in the embodiment of the reasoning method for assembling or modeling any of the multi-branch products described above.

[0238] The embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-described embodiments of the assembly or model reasoning method for any of the multi-branch products.

[0239] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of the embodiments of this application.

[0240] The foregoing has provided a detailed description of the assembly or modeling of a multi-branch product provided by the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of the embodiments of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the methods and core ideas of the embodiments of this application. It should be noted that those skilled in the art can make several improvements and modifications to the embodiments of this application without departing from the principles of the embodiments of this application, and these improvements and modifications also fall within the protection scope of the embodiments of this application.

Claims

1. A method for assembling a multi-branch product, characterized in that, include: Obtain a build request; wherein the build request includes product information, version information, and branch information; Based on the build request, multiple target branches corresponding to the same product are determined, and baseline snapshots corresponding to the multiple target branches are obtained; wherein, the baseline snapshot is a read-only source code directory determined from the code repository; Based on the baseline snapshot and the build request, determine the difference file for the target branch; Based on the baseline snapshot and the difference file, generate a complete build view of the target branch; Based on the difference file, generate the build task for the target branch; Based on the complete build view, the build tasks are executed in parallel to generate the assembly product of the target branch.

2. The method according to claim 1, characterized in that, The step of generating a complete build view of the target branch based on the baseline snapshot and the difference file includes: Based on the difference file, generate an independent upper layer for the target branch; The baseline snapshot is used as a read-only lower layer, and the independent upper layer is overlaid to generate the complete build view.

3. The method according to claim 2, characterized in that, The difference files include newly added type files, modified type files, deleted type files, and renamed type files; The step of generating an independent upper layer for the target branch based on the difference file includes: When the difference file is the new type file or the modified type file, the new or modified content is written to the independent upper layer; When the difference file is the deletion type file, write a deletion mark or a list of paths to be deleted in the independent upper layer; When the difference file is a rename type file, the old path deletion relationship and the new path addition relationship are written in the independent upper layer.

4. The method according to claim 1, characterized in that, The step of executing the build task in parallel based on the complete build view includes: Generate task description information for the target branch; wherein, the task description information includes identification information and resource control description information; the identification information includes at least one of task identification description information, source code version description information, and execution context information; Obtain the status information of the parallel scheduler; wherein, the status information includes hardware resource information and / or task load information; The number of tasks to be executed concurrently is determined based on the resource control description information and the status information; Based on the number of tasks, the scheduler is controlled to execute the build tasks in parallel according to the identification information; wherein the build tasks are executed in the corresponding complete build view.

5. The method according to claim 4, characterized in that, The control of the scheduler to execute the construction task in parallel according to the identification information includes: The scheduler is controlled to generate isolation items based on the identification information; wherein the isolation item includes at least one of the following: build output directory, temporary file directory, dependency repository write layer, log file and process group; The scheduler is controlled to execute the build tasks in parallel based on the isolation items.

6. The method according to any one of claims 1 to 5, characterized in that, The build task of generating the target branch based on the difference file includes: Obtain the module dependency graph; Based on the difference file and the module dependency graph, determine the directly affected modules that are affected by the difference file; Based on the module dependency graph, upstream modules that depend on the directly affected modules are added to the build set to form a dependency closure; Generate a build manifest based on the directly affected modules and the dependent closures; The build task is generated based on the build manifest.

7. The method according to any one of claims 1 to 5, characterized in that, The step of obtaining baseline snapshots corresponding to the multiple target branches includes: Based on the build request, determine the baseline commit number of the target branch; Based on the baseline commit number, a match is made in the code repository to obtain the corresponding baseline snapshot; wherein the code repository includes a mapping relationship between the baseline commit number and the read-only source code directory.

8. The method according to claim 7, characterized in that, Before the step of matching in the code repository based on the baseline commit number to obtain the corresponding baseline snapshot, the method further includes: Create an object pool and baseline directory; Retrieve multiple baseline commit numbers to be initialized; Pull the code object corresponding to the baseline commit number from the code repository to the object pool, and expand the source code tree corresponding to the baseline commit number to the baseline directory; Set the baseline directory to read-only to form the read-only source code directory; Parse the build configuration file corresponding to the read-only source code directory to generate a module dependency graph; Based on the module dependency graph, stable dependencies are downloaded to a shared dependency repository, which is then used as a read-only lower layer for multiple build tasks to reuse. Based on the read-only source code directory and the module dependency graph, a baseline file fingerprint table is generated to map the difference files to the corresponding modules.

9. The method according to any one of claims 1 to 5, characterized in that, After executing the build task in parallel according to the complete build view to generate the assembly product of the target branch, the method further includes: Read the build artifact catalog in the build view to obtain the assembly artifact; Generate a product verification list; wherein the product verification list includes at least one of the following: the identification information of the target branch, the target commit number of the target branch, the identification information of the baseline snapshot, the verification value of the assembled product, and the construction environment fingerprint; The assembled product and the product verification list are associated and output.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the assembly method of the multi-branch product as claimed in any one of claims 1 to 9.

Images