Multi-platform multi-version environment isolation automatic building method, device, equipment and medium

Abstract

The application provides a multi-platform multi-version environment isolation automatic construction method, device, equipment and medium, the method comprises the following steps: creating a construction environment directory isolated from each other for different versions of Firefox, realizing complete isolation by resetting environment variables; receiving construction parameters through a parameterized construction script, and automatically selecting the corresponding configuration file; synchronizing the secondary development code repository, switching the upstream repository version, code coverage, and construction packaging and integration into a single pipeline, which is interrupted if any step fails; generating a versioned construction product file name according to the product identifier, the operating system type, the CPU architecture and the timestamp, and automatically updating the version number cache file; realizing multi-version Firefox parallel construction environment isolation, cross-platform unified construction interface, code synchronization and construction integration, and significantly improving the secondary development construction efficiency and reliability.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to an automated build method, apparatus, device, and medium for multi-platform and multi-version environment isolation. Background Technology

[0002] Mozilla Firefox is one of the world's largest open-source browser projects, with a codebase exceeding 20 million lines and supporting multiple platforms including Windows, macOS, Linux, and Android. During Firefox's secondary development, the development team needs to maintain secondary development code for multiple Firefox versions simultaneously, building for different platforms and operating systems, and supporting customized builds for multiple product lines.

[0003] Current Firefox build solutions primarily rely on Mozilla's official Mach build system, requiring developers to manually configure the build environment, select configuration files, and execute build commands. This existing technology has the following drawbacks: First, there are build environment conflicts. Different versions of Firefox have different version requirements for build toolchains such as Rust, Clang, and Python. When developers build different versions on the same machine, the globally installed toolchain versions will interfere with each other, causing build failures. Furthermore, environment configuration is time-consuming and build problems are difficult to reproduce.

[0004] Second, multi-platform construction is complex. Existing solutions require writing separate build scripts for each platform, resulting in repetitive scripts, high maintenance costs, fragmented handling of platform differences, and a lack of a unified parameter interface.

[0005] Third, building multiple products is difficult. Different products require different configuration files, resource files, and signing keys. Existing solutions require manually switching configuration files, resulting in chaotic version number management and errors when copying product resources.

[0006] Fourth, code synchronization and build are disconnected. Synchronizing and building secondary development code are two independent operations, requiring manual code synchronization before building. This easily leads to inconsistencies between code versions and build logs, and lacks complete build log tracking.

[0007] Therefore, how to achieve complete isolation of multiple versions of Firefox build environments, design a unified cross-platform build interface, realize automated configuration and version management of multiple products, and seamlessly integrate code synchronization with the build process are technical problems that urgently need to be solved by those skilled in the art. Summary of the Invention

[0008] The technical problem to be solved by the present invention is to provide an automated build method, apparatus, device and medium for multi-platform and multi-version environment isolation, which realizes parallel build environment isolation for multiple versions of Firefox, cross-platform unified build interface, code synchronization and build integration, and significantly improves the efficiency and reliability of secondary development build.

[0009] In a first aspect, the present invention provides an automated build method for multi-platform, multi-version environment isolation, characterized by comprising the following steps: Step 1: Create isolated build environment directories for different versions of the Firefox browser. The build environment directories include version-specific Rust toolchain paths, package manager paths, and build state storage paths. Complete isolation of the build environments for each version is achieved by resetting environment variables. Step 2: Receive build parameters, which include target platform, operating system type, CPU architecture, product identifier, build mode flag, and upload flag. Select the corresponding mozconfig configuration file, product resource file, and version number cache file according to the build parameters. The target platform includes PC and Android platforms. When the target platform is a PC platform, the operating system type is Windows, macOS, or Linux. When the target platform is an Android platform, the operating system type is the default value. The CPU architecture is selected from x86, x64, arm, arm64, arm64-v8a, armeabi-v7a, or x86_64 depending on the target platform. Step 3: Integrate the synchronization operation of the secondary development code repository, the version switching operation of the Firefox upstream repository, the code overwrite operation, and the build and packaging operation into a single pipeline. The synchronization operation is only allowed to fast forward and merge, and subsequent operations are stopped if any operation in the pipeline fails. Step 4: After the build and packaging operation is successfully completed, generate the file name of the build artifact based on the product identifier, operating system type, CPU architecture and timestamp. The file name shall at least contain the product identifier, the operating system type, the CPU architecture and build time information, and update the version number cache file. If any step 1, step 2, step 3 or step 4 fails, the entire method process shall be terminated immediately.

[0010] Secondly, the present invention provides an automated build apparatus for multi-platform, multi-version environment isolation, comprising: The version isolation environment management module creates isolated build environment directories for different versions of the Firefox browser. The build environment directory includes version-specific Rust toolchain paths, package manager paths, and build state storage paths, and achieves complete isolation of the build environment for each version by resetting environment variables. A unified build interface module receives build parameters, including the target platform, operating system type, CPU architecture, product identifier, build mode flag, and upload flag. Based on these parameters, it selects the corresponding mozconfig configuration file, product resource file, and version number cache file. The target platform includes PC and Android platforms. When the target platform is a PC, the operating system type is Windows, macOS, or Linux; when the target platform is an Android platform, the operating system type is the default value. The CPU architecture is selected from x86, x64, arm, arm64, arm64-v8a, armeabi-v7a, or x86_64 depending on the target platform. The pipeline control module integrates the synchronization operation of the secondary development code repository, the version switching operation of the Firefox upstream repository, the code overwrite operation, and the build and packaging operation into a single pipeline. The synchronization operation only allows fast-forward merging, and subsequent operations are aborted if any operation in the pipeline fails. The build management module generates a filename for the build artifact based on the product identifier, operating system type, CPU architecture, and timestamp after the build and packaging operation is successfully completed. The filename must contain at least the product identifier, operating system type, CPU architecture, and build time information. The module also updates the version number cache file. If any step in the version isolation environment management module, unified build interface module, pipeline control module, or build management module fails, the process will be immediately terminated.

[0011] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.

[0012] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0013] One or more technical solutions provided by this invention have at least the following technical effects or advantages: 1. This invention creates version-specific build environment directories for different versions of Firefox, isolating paths such as the Rust toolchain, Cargo package manager, and Mozilla build status from the system global environment, and filtering out conflicting paths from the system PATH. This enables parallel building of different versions of Firefox without interference. Environment switching time is reduced from the traditional 30-60 minutes to seconds, and the ability to build multiple versions in parallel fills a gap in existing technology.

[0014] 2. This invention uses parameterized build scripts and a single interface to cover build scenarios for multiple platforms, multiple CPU architectures, and multiple product lines, including PC (Windows / Mac / Linux) and Android. This replaces the traditional approach of writing separate build scripts for each platform, reducing the number of scripts by more than 80% and lowering the configuration error rate from 15% to below 1%.

[0015] 3. This invention automatically indexes the corresponding product resource directory, version number cache file, and build configuration file through product identifiers, realizing automated configuration of multi-product builds. The product switching time is reduced from 10-15 minutes to a single command execution, without manual intervention.

[0016] 4. This invention integrates secondary development code repository synchronization, Firefox upstream repository version switching, code overwriting, and build packaging into a pipeline. If any step fails, the process will stop and retain complete logs, ensuring the consistency between the code version and the build artifacts. The build process is traceable and reproducible.

[0017] 5. This invention stores version number cache files separately for each product and platform, and automatically reads and increments the build sequence number after each successful build, thus achieving automated version number management and avoiding the tediousness and errors of manually maintaining version numbers.

[0018] 6. This invention is fully compatible with mainstream platforms such as Windows (including MozillaBuild environment), macOS (including Homebrew Python), Linux (including Clang compiler) and Android (including SDK / NDK / Gradle), and has good cross-platform compatibility.

[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0021] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention. Detailed Implementation

[0022] The overall concept of the technical solution in this application embodiment is as follows: To address the four major technical challenges in the secondary development of the Firefox browser—build environment conflicts, complex multi-platform builds, difficulties in managing multiple products, and disconnect between code synchronization and build processes—a four-in-one technical architecture of "environment isolation, unified interface, pipeline integration, and automatic artifact management" is adopted. This architecture integrates the originally scattered, manual, and error-prone multi-version, multi-platform build process into an atomic, automated, and traceable single pipeline.

[0023] This invention firstly establishes an independent build environment directory for different versions of Firefox through a version isolation mechanism, isolating the Rust toolchain, Cargo package manager, Mozilla build status, and other paths from the system's global environment, fundamentally resolving toolchain conflicts during parallel builds of multiple versions. Secondly, this invention designs a unified parameterized build interface that automatically selects the corresponding build configuration file, product resource file, and version number cache file based on combinations of parameters such as target platform, operating system type, CPU architecture, and product identifier. This enables a single script to cover PC and Android platforms, Windows / Mac / Linux operating systems, various CPU architectures (x86 / x64 / arm / arm64), and multiple product lines. Thirdly, this invention integrates secondary development code repository synchronization, Firefox upstream repository version switching, code overwriting, build guidance, and build packaging into an atomic pipeline. Failure of any operation terminates the entire process while retaining complete logs, ensuring consistency between code version and build artifacts, and achieving traceability and reproducibility of the build process. Finally, this invention achieves automated version number management by using an automated product management mechanism to generate versioned build product names based on product identifier, platform type, CPU architecture, and timestamp, and automatically increments the build sequence number in the version number cache file after a successful build.

[0024] Through the above technical solution, this invention achieves the technical effect of "one-time configuration, automatic execution, multi-version parallel processing, and full platform coverage" in the Firefox secondary development build process, significantly improving build efficiency and reliability. The core idea of ​​this invention is to use "isolation" as a means to resolve environmental conflicts, "unification" as a way to reduce complexity, "pipeline" as a mechanism to ensure consistency, and "automation" as a method to improve efficiency. These four elements are organically combined to form a complete and industrially applicable technical solution.

[0025] Example 1 like Figure 1 As shown, this embodiment provides an automated build method for multi-platform, multi-version environment isolation, characterized by the following steps: Step 1: Create isolated build environment directories for different versions of the Firefox browser. The build environment directories include version-specific Rust toolchain paths, package manager paths, and build state storage paths. Complete isolation of the build environments for each version is achieved by resetting environment variables. Step 2: Receive build parameters, which include target platform, operating system type, CPU architecture, product identifier, build mode flag, and upload flag. Select the corresponding mozconfig configuration file, product resource file, and version number cache file according to the build parameters. The target platform includes PC and Android platforms. When the target platform is a PC platform, the operating system type is Windows, macOS, or Linux. When the target platform is an Android platform, the operating system type is the default value. The CPU architecture is selected from x86, x64, arm, arm64, arm64-v8a, armeabi-v7a, or x86_64 depending on the target platform. Step 3: Integrate the synchronization operation of the secondary development code repository, the version switching operation of the Firefox upstream repository, the code overwrite operation, and the build and packaging operation into a single pipeline. The synchronization operation is only allowed to fast forward and merge, and the subsequent operation is stopped if any operation in the pipeline fails. Step 4: After the build and packaging operation is successfully completed, generate the file name of the build artifact based on the product identifier, operating system type, CPU architecture and timestamp. The file name shall at least include the product identifier, the operating system type, the CPU architecture and build time information, and update the version number cache file. If any step 1, step 2, step 3 or step 4 fails, the entire method process shall be terminated immediately.

[0026] In this embodiment, preferably, step 1 specifically comprises: The environment root directory path is constructed based on the Firefox major version number, and the Firefox major version number is embedded as a version identifier in the environment root directory path; Set the Rust toolchain installation path variable, the Rust version management tool installation path variable, and the build state storage path variable to point to the corresponding subdirectories under the root directory of the environment; Filter out toolchain paths that are not specific to the current version from the system path environment variables, and also filter out conflicting third-party tool paths; Add the version-specific toolchain path to the very beginning of the system path environment variable.

[0027] In this embodiment, preferably, The version switching operation in step 3 is specifically as follows: Read the version number from the version configuration file of the secondary development repository, replace the dot in the version number with an underscore and add the _RELEASE suffix to generate the tag name of the Firefox upstream repository; When executing a tab switching command on a Firefox upstream repository, disable detached head pointer warnings only during the execution of the tab switching command. The code overwrite operation in step 3 specifically involves: Check the working directory status of the secondary development repository. If there are no uncommitted changes in the working directory status of the secondary development repository, then abort the subsequent steps in the single pipeline. If there are uncommitted changes in the working directory status of the secondary development repository, use a file synchronization tool to overwrite the code of the secondary development repository into the upstream repository directory of Firefox, while excluding the metadata directory of the version control system to preserve the version control information of the upstream repository.

[0028] In this embodiment, preferably, step 4 further includes: After the build and packaging operation is successfully completed, the file name of the build artifact is generated based on the product identifier, operating system type, CPU architecture, and timestamp. The file name contains at least the product identifier, the operating system type, the CPU architecture, and the build time information. The build sequence number in the version number cache file is read, incremented by 1, and then written back to the same file. The version number format is a multi-segment version number, which includes at least the build sequence number segment; The storage path of the version number cache file includes the product identifier, and the storage path of the PC platform also includes the platform identifier.

[0029] In this embodiment, preferably, step 5 is also included. Generate timestamped log files when a single pipeline starts; Write all standard output and standard error output of the build process to the log file and the terminal console simultaneously; If any step fails, the pipeline is immediately stopped and the log file is retained.

[0030] In this embodiment, preferably, step 6 is also included. On the Windows platform, start the MozillaBuild Shell environment and convert the Windows path to an MSYS2-compatible path format; On macOS, set the Homebrew Python path and perform newline character conversion on the configuration file; On a Linux platform, set the Clang compiler path; On the Android platform, configure the Android SDK and NDK paths and support Gradle builds; In this embodiment, preferably, it also includes step 7: locating the product resource directory based on the product identifier, wherein the product resource directory includes a product key file, an operating system-specific resource file, and an Android platform-specific resource file; Copy the product key file to the specified location in the source code directory; Copy the operating system-specific resource files to the browser's brand resource directory, which is the path browser / branding / official / under the Firefox source code directory; In Android platform build scenarios, replace the version placeholder with the actual version number and then copy it to the specified source file.

[0031] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0032] Example 2 like Figure 2 As shown, this embodiment provides an automated build device for multi-platform, multi-version environment isolation, including: The version isolation environment management module creates isolated build environment directories for different versions of the Firefox browser. The build environment directory includes version-specific Rust toolchain paths, package manager paths, and build state storage paths, and achieves complete isolation of the build environment for each version by resetting environment variables. A unified build interface module receives build parameters, including the target platform, operating system type, CPU architecture, product identifier, build mode flag, and upload flag. Based on these parameters, it selects the corresponding mozconfig configuration file, product resource file, and version number cache file. The target platform includes PC and Android platforms. When the target platform is a PC, the operating system type is Windows, macOS, or Linux; when the target platform is an Android platform, the operating system type is the default value. The CPU architecture is selected from x86, x64, arm, arm64, arm64-v8a, armeabi-v7a, or x86_64 depending on the target platform. The pipeline control module integrates the synchronization operation of the secondary development code repository, the version switching operation of the Firefox upstream repository, the code overwrite operation, and the build and packaging operation into a single pipeline. The synchronization operation only allows fast-forward merging, and subsequent operations are aborted if any operation in the pipeline fails. The build management module generates a filename for the build artifact based on the product identifier, operating system type, CPU architecture, and timestamp after the build and packaging operation is successfully completed. The filename must contain at least the product identifier, operating system type, CPU architecture, and build time information. The module also updates the version number cache file. If any step in the version isolation environment management module, unified build interface module, pipeline control module, or build management module fails, the process will be immediately terminated.

[0033] In this embodiment, preferably, the version isolation environment management module specifically comprises: The environment root directory path is constructed based on the Firefox major version number, and the Firefox major version number is embedded as a version identifier in the environment root directory path; Set the Rust toolchain installation path variable, the Rust version management tool installation path variable, and the build state storage path variable to point to the corresponding subdirectories under the root directory of the environment; Filter out toolchain paths that are not specific to the current version from the system path environment variables, and also filter out conflicting third-party tool paths; Add the version-specific toolchain path to the very beginning of the system path environment variable.

[0034] In this embodiment, preferably, The version switching operation in the pipeline control module is specifically as follows: Read the version number from the version configuration file of the secondary development repository, replace the dot in the version number with an underscore and add the _RELEASE suffix to generate the tag name of the Firefox upstream repository; When executing a tab switching command on a Firefox upstream repository, disable detached head pointer warnings only during the execution of the tab switching command. The code overwrite operation in the pipeline control module is specifically as follows: Check the working directory status of the secondary development repository. If there are no uncommitted changes in the working directory status of the secondary development repository, then abort the subsequent steps in the single pipeline. If there are uncommitted changes in the working directory status of the secondary development repository, use a file synchronization tool to overwrite the code of the secondary development repository into the upstream repository directory of Firefox, while excluding the metadata directory of the version control system to preserve the version control information of the upstream repository.

[0035] In this embodiment, preferably, the construction management module further includes: After the build and packaging operation is successfully completed, the file name of the build artifact is generated based on the product identifier, operating system type, CPU architecture, and timestamp. The file name contains at least the product identifier, the operating system type, the CPU architecture, and the build time information. The build sequence number in the version number cache file is read, incremented by 1, and then written back to the same file. The version number format is a multi-segment version number, which includes at least the build sequence number segment; The storage path of the version number cache file includes the product identifier, and the storage path of the PC platform also includes the platform identifier.

[0036] In this embodiment, preferably, a log management module is also included. Generate timestamped log files when a single pipeline starts; Write all standard output and standard error output of the build process to the log file and the terminal console simultaneously; If any step fails, the pipeline is immediately stopped and the log file is retained.

[0037] In this embodiment, preferably, a cross-platform adaptation module is also included. On the Windows platform, start the MozillaBuild Shell environment and convert the Windows path to an MSYS2-compatible path format; On macOS, set the Homebrew Python path and perform newline character conversion on the configuration file; On a Linux platform, set the Clang compiler path; On the Android platform, configure the Android SDK and NDK paths and support Gradle builds; In this embodiment, preferably, it also includes a product resource management module, which locates the product resource directory based on the product identifier. The product resource directory includes a product key file, an operating system-specific resource file, and an Android platform-specific resource file. Copy the product key file to the specified location in the source code directory; Copy the operating system-specific resource files to the browser's brand resource directory, which is the path browser / branding / official / under the Firefox source code directory; In Android platform build scenarios, replace the version placeholder with the actual version number and then copy it to the specified source file.

[0038] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0039] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3.

[0040] Example 3 This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement any of the implementation methods in Embodiment 1.

[0041] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.

[0042] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4.

[0043] Example 4 This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1.

[0044] Example 5 This example demonstrates building a Firefox 132 version of HubStudio on macOS. The implementation environment is a macOS computer with an Apple M2 chip, running macOS Sonoma 14.0, and with at least 100GB of available disk space. Before implementation, ensure that basic tools such as Git and Homebrew are installed, and that a secondary development code repository is ready.

[0045] First, version isolation is performed. The build script reads the `browser / config / version.txt` file in the Firefox source code directory and obtains the major version number, which is 132. Based on this major version number, the script builds the root directory path of the environment, formatted as the `.mozilla_env132` directory under the user's home directory. The script sets the `CARGO_HOME` environment variable to the `cargo` subdirectory of this directory, sets `RUSTUP_HOME` to the `rustup` subdirectory of this directory, and sets `MOZBUILD_STATE_PATH` to the `mozbuild` subdirectory of this directory. Then, the script filters paths containing strings like `cargo`, `rustup`, and `mozbuild` from the system PATH environment variable, while also filtering out potentially conflicting paths such as `Cygwin`, `LLVM`, and `depot_tools`, retaining only necessary system paths. Finally, the version-specific `cargo / bin` path is added to the beginning of the PATH. Through these operations, the build environment for Firefox version 132 is completely isolated from other Firefox version environments that may exist on the system.

[0046] Next, the unified interface configuration step is executed. The user executes the build command, specifying the build configuration via command-line arguments. The command is as follows: . / build_package.sh -t pc -o mac -c arm64 -p hubstudio -r -u The -t parameter specifies the target platform as PC, the -o parameter specifies the operating system type as macOS, the -c parameter specifies the CPU architecture as arm64, the -p parameter specifies the product identifier as hubstudio, the -r flag indicates that this build is in Release mode, and the -u flag indicates that the build will be uploaded to the SVN version control system after completion.

[0047] After receiving the above parameters, the script automatically selects the corresponding build configuration file. Since the target platform is a PC, the operating system is macOS, and the build mode is Release, the script selects `conf / mac / mozconfig-release-hubstudio` as the `mozconfig` configuration file. The script reads this configuration file and uses the `sed` command to modify the value of the `MOZ_OBJDIR` line to `obj-superBrowser-r64-hubstudio`, ensuring the compiled output directory includes the product identifier. The script also selects `conf / mac / version_code_hubstudio_mac64.txt` as the version number cache file and locates the `resource / product / hubstudio` directory as the product resource directory.

[0048] Then, the pipeline integration step is executed. This step integrates the secondary development code repository synchronization, Firefox upstream repository version switching, code overwriting, and build packaging into an atomic pipeline.

[0049] First, the script synchronizes the secondary development code repository. It checks the working directory status of the secondary development repository to ensure there are no uncommitted changes. If uncommitted changes are found, the script immediately stops the pipeline and prompts the user to handle it. After confirming the working directory is clean, the script switches to the specified development branch and executes the `git pull --ff-only` command, allowing only fast-forward merges to avoid generating unnecessary merge commits.

[0050] Next, the script switches the Firefox upstream repository version. It reads the version number from the `browser / config / version.txt` file in the secondary development repository; the file contains 132.0.2. The script replaces the dots in the version number with underscores and adds the `_RELEASE` suffix, automatically generating the tag name `FIREFOX_132_0_2_RELEASE`. The script checks if the Firefox build directory exists; if not, it executes the `git clone` command to clone the source code from `https: / / github.com / mozilla-firefox / firefox.git`. The script executes `git fetch --tags --prune` to get the latest tags, and then executes the `git checkout -q -f tags / FIREFOX_132_0_2_RELEASE` command to switch to the specified tag. During the tag switch, the script temporarily disables detached head pointer warnings using the `-c advice.detachedHead=false` parameter; this disabling only applies during the execution of the current command.

[0051] Then, the script performs code overwrite operations. It uses the `rsync` command to overwrite the code from the secondary development repository into the Firefox upstream repository directory. The command is `rsync -a --exclude .git / path / to / dev-repo / / path / to / firefox-build / `. This command excludes the `.git` directory, preserving the Git metadata of the Firefox upstream repository for subsequent version switching operations. If `rsync` is not installed on the system, the script automatically uses the `tar` command to perform the same function.

[0052] Finally, the script performs the build and packaging operations. First, it performs the build bootstrapping operation with the command `. / mach --no-interactive bootstrap --application-choice browser`. This command automatically installs the dependencies required for Firefox's build, including the correct versions of Rust, Clang, Node.js, etc. The script then performs the actual build and packaging operations, executing `. / mach build` for compilation and `. / mach package-multi-locale --locales en-US` for packaging.

[0053] During the build bootstrapping and build packaging process, the build system uses the toolchain in the isolated environment directory in step one. The Rust compiler is located at .mozilla_env132 / cargo / bin / rustc, and the Clang compiler is located at .mozilla_env132 / mozbuild / clang / bin / clang. Builds of different Firefox versions do not interfere with each other.

[0054] Finally, the artifact management steps are executed. After the build and packaging operation is successfully completed, the script generates versioned build artifact filenames. The script reads the build sequence number from the file conf / mac / version_code_hubstudio_mac64.txt, which is currently 15. The script combines the product major version number 6, Firefox major version number 132, major version number 1, minor version number 0, and build sequence number 15 into the version number 6.132.1.0.15. Based on the product identifier hubstudio, operating system type mac, CPU architecture arm64, current timestamp 202604211430, and version number 6.132.1.0.15, the script generates the artifact filename firefox_hubstudio_mac_arm64_202604211430_ver6.132.1.0.15.zip.

[0055] The script writes the version number to the `conf / version.h` header file for use during the compilation process. The script executes the `zip` command to package the output files in the compilation output directory into a ZIP file with the aforementioned name. After packaging, the script increments the build sequence number in the version number cache file from 15 to 16 and writes it back to the original file.

[0056] Because the user specified the -u flag, the script performs an SVN upload operation. Based on the product identifier hubstudio, the script determines the SVN path to https: / / svn.example.com / releases / hubstudio / Firefox / mac / arm64 / , uses the svn import command to upload the ZIP file to this path, and the commit message contains the build artifact filename.

[0057] At this point, the entire build process is complete. If any of the above steps fail, the script immediately stops the pipeline and retains the current log file, located in the execution directory, named sync_build_20260421_143000.log, which contains complete standard output and standard error output for easy problem tracing.

[0058] This embodiment uses the macOS platform's arm64 architecture to build the HubStudio product as an example, fully demonstrating the implementation process of this invention. Those skilled in the art will understand that changing the -t parameter to pc, the -o parameter to win or linux, the -c parameter to x86 or x64, and the -p parameter to ziniao or morelogin will enable building on other platforms, architectures, and products. Changing the -t parameter to android enables APK building on the Android platform. Replacing the Firefox major version number with other version numbers will cause the version isolation mechanism of this invention to automatically create corresponding environment directories, enabling parallel building of multiple versions.

[0059] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0060] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0061] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0062] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0063] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. An automated build method for multi-platform, multi-version environment isolation, characterized in that, Includes the following steps: Step 1: Create isolated build environment directories for different versions of the Firefox browser. The build environment directories include version-specific Rust toolchain paths, package manager paths, and build state storage paths. Complete isolation of the build environments for each version is achieved by resetting environment variables. Step 2: Receive build parameters, which include target platform, operating system type, CPU architecture, product identifier, build mode flag, and upload flag. Select the corresponding mozconfig configuration file, product resource file, and version number cache file according to the build parameters. The target platform includes PC and Android platforms. When the target platform is a PC platform, the operating system type is Windows, macOS, or Linux. When the target platform is an Android platform, the operating system type is the default value. The CPU architecture is selected from x86, x64, arm, arm64, arm64-v8a, armeabi-v7a, or x86_64 depending on the target platform. Step 3: Integrate the synchronization operation of the secondary development code repository, the version switching operation of the Firefox upstream repository, the code overwrite operation, and the build and packaging operation into a single pipeline. The synchronization operation is only allowed to fast forward and merge, and the subsequent operation is stopped if any operation in the pipeline fails. Step 4: After the build and packaging operation is successfully completed, generate the file name of the build artifact based on the product identifier, operating system type, CPU architecture and timestamp. The file name shall at least include the product identifier, the operating system type, the CPU architecture and build time information, and update the version number cache file. If any step 1, step 2, step 3 or step 4 fails, the entire method process shall be terminated immediately.

2. The method according to claim 1, characterized in that, Step 1 specifically involves: The environment root directory path is constructed based on the Firefox major version number, and the Firefox major version number is embedded as a version identifier in the environment root directory path; Set the Rust toolchain installation path variable, the Rust version management tool installation path variable, and the build state storage path variable to point to the corresponding subdirectories under the root directory of the environment; Filter out toolchain paths that are not specific to the current version from the system path environment variables, and also filter out conflicting third-party tool paths; Add the version-specific toolchain path to the very beginning of the system path environment variable.

3. The method according to claim 1, characterized in that, The version switching operation in step 3 is specifically as follows: Read the version number from the version configuration file of the secondary development repository, replace the dot in the version number with an underscore and add the _RELEASE suffix to generate the tag name of the Firefox upstream repository; When executing a tab switching command on a Firefox upstream repository, disable detached head pointer warnings only during the execution of the tab switching command. The code overwrite operation in step 3 specifically involves: Check the working directory status of the secondary development repository. If there are no uncommitted changes in the working directory status of the secondary development repository, then abort the subsequent steps in the single pipeline. If there are uncommitted changes in the working directory status of the secondary development repository, use a file synchronization tool to overwrite the code of the secondary development repository into the upstream repository directory of Firefox, while excluding the metadata directory of the version control system to preserve the version control information of the upstream repository.

4. The method according to claim 1, characterized in that, Step 4 further includes: After the build and packaging operation is successfully completed, the file name of the build artifact is generated based on the product identifier, operating system type, CPU architecture, and timestamp. The file name contains at least the product identifier, the operating system type, the CPU architecture, and the build time information. The build sequence number in the version number cache file is read, incremented by 1, and then written back to the same file. The version number format is a multi-segment version number, which includes at least the build sequence number segment; The storage path of the version number cache file includes the product identifier, and the storage path of the PC platform also includes the platform identifier.

5. The method according to claim 1, characterized in that, It also includes step 5, Generate timestamped log files when a single pipeline starts; Write all standard output and standard error output of the build process to the log file and the terminal console simultaneously; If any step fails, the pipeline is immediately stopped and the log file is retained.

6. The method according to claim 1, characterized in that, It also includes step 6, On the Windows platform, start the MozillaBuild Shell environment and convert the Windows path to an MSYS2-compatible path format; On macOS, set the Homebrew Python path and perform newline character conversion on the configuration file; On a Linux platform, set the Clang compiler path; On the Android platform, configure the Android SDK and NDK paths and support Gradle builds.

7. The method according to claim 1, characterized in that, It also includes step 7, locating the product resource catalog based on the product identifier, wherein the product resource catalog contains product key files, operating system-specific resource files, and Android platform-specific resource files; Copy the product key file to the specified location in the source code directory; Copy the operating system-specific resource files to the browser's brand resource directory, which is the path browser / branding / official / under the Firefox source code directory; In Android platform build scenarios, replace the version placeholder with the actual version number and then copy it to the specified source file.

8. An automated build device with multi-platform and multi-version environment isolation, characterized in that, include: The version isolation environment management module creates isolated build environment directories for different versions of the Firefox browser. The build environment directory includes version-specific Rust toolchain paths, package manager paths, and build state storage paths, and achieves complete isolation of the build environment for each version by resetting environment variables. A unified build interface module receives build parameters, including the target platform, operating system type, CPU architecture, product identifier, build mode flag, and upload flag. Based on these parameters, it selects the corresponding mozconfig configuration file, product resource file, and version number cache file. The target platform includes PC and Android platforms. When the target platform is a PC, the operating system type is Windows, macOS, or Linux; when the target platform is an Android platform, the operating system type is the default value. The CPU architecture is selected from x86, x64, arm, arm64, arm64-v8a, armeabi-v7a, or x86_64 depending on the target platform. The pipeline control module integrates the synchronization operation of the secondary development code repository, the version switching operation of the Firefox upstream repository, the code overwrite operation, and the build and packaging operation into a single pipeline. The synchronization operation only allows fast-forward merging, and subsequent operations are aborted if any operation in the pipeline fails. The build management module generates a filename for the build artifact based on the product identifier, operating system type, CPU architecture, and timestamp after the build and packaging operation is successfully completed. The filename must contain at least the product identifier, operating system type, CPU architecture, and build time information. The module also updates the version number cache file. If any step in the version isolation environment management module, unified build interface module, pipeline control module, or build management module fails, the process will be immediately terminated.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

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

Images