Electron application automatic building method and system based on xinchuang environment

Abstract

This invention discloses an automated method for building Electron applications based on a domestically developed IT environment, belonging to the field of information technology application innovation. The method includes: responding to a request, performing static analysis and optimization of the source code on the server side, generating a standardized resource package and securely transmitting it to the domestically developed IT terminal device; after receiving parameterized instructions, the terminal automatically updates the build environment, decompresses resources and parses configurations in an isolated space; finally, based on the target architecture and system, dynamically calls the toolchain to complete native module compilation, application encapsulation, and desktop integration, generating a standard installation package conforming to domestically developed IT specifications and archiving it. This invention solves the problems of difficult adaptation, low efficiency, and error-prone manual operation in Electron application building under the domestically developed IT environment, significantly improving build efficiency, deliverable consistency, and supply chain traceability.

Description

Technical Field

[0001] This invention relates to the field of computer application development and information technology application innovation, specifically to an automated packaging method and system for Electron applications based on a domestic IT innovation environment. Background Technology

[0002] With the booming development of the information technology application innovation (ITAI) industry, achieving self-reliance and controllability in the field of information technology has become a key objective. The ITAI environment encompasses a series of crucial components, from chips and operating systems to databases and application software, aiming to build a secure, reliable, and self-controllable information technology ecosystem. Against this backdrop, applications developed based on the Electron framework have received widespread attention and application due to their cross-platform capabilities, enabling them to run on different operating systems. Therefore, automating the construction of Electron applications within the ITAI environment has become an important means to improve application delivery efficiency and ensure system compatibility and stability.

[0003] In existing technologies, the automated building of Electron applications based on the domestic IT innovation environment typically employs traditional dependency package management and environment configuration methods. These solutions primarily rely on manual configuration and deployment processes. Specifically, existing solutions usually require developers or operations personnel to manually install various dependency packages, set compilation environment parameters, and make adaptation adjustments for different system architectures (such as ARM and x86) on different types of domestic IT innovation terminal operating systems (such as Kylin and UnionTech UOS). Furthermore, existing build processes often lack unified standardized scripts and automation tools, resulting in the repeated execution of numerous similar but subtly different configuration operations when building across different projects and Electron versions. The overall process relies heavily on manual intervention and accumulated experience.

[0004] However, existing technical solutions have the following significant drawbacks: First, due to the significant differences between the operating system, dependency packages, and configuration environment in the domestic IT innovation environment and the traditional mainstream environment, the existing manual configuration methods are difficult to directly adapt to the specific requirements of different domestic IT innovation terminals. This results in a large amount of repetitive and error-prone adaptation work when packaging Electron applications under different operating systems. Second, the existing process lacks automation and standardization support, relying on manual execution of compilation, packaging, shortcut configuration, and writing installation and uninstallation scripts one by one. This not only consumes a lot of manpower and time but also easily introduces human errors, extending the application launch cycle. Finally, the existing solutions are difficult to achieve rapid reuse and version management of the build process, and cannot meet the rapid iteration and release requirements of multi-project, multi-version, and multi-terminal architectures in the domestic IT innovation environment, which seriously restricts project delivery efficiency and the large-scale development of the application ecosystem.

[0005] Therefore, there is an urgent need for an Electron application building system and method that can adapt to the characteristics of the information technology innovation environment and achieve a high degree of automation and standardization, in order to solve the problems of adaptation difficulties, low efficiency, error susceptibility and inability to iterate quickly in the existing technologies. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention discloses an automated packaging method for Electron applications based on a domestic IT innovation environment. The technical solution includes the following steps:

[0007] An automatic construction method for Electron applications based on a domestic IT innovation environment, characterized by the following steps:

[0008] An automatic construction method for Electron applications based on a domestic IT innovation environment, characterized by the following steps:

[0009] S1. On the continuous integration server, perform static analysis and dead code elimination optimization based on abstract syntax tree on the source code of the Electron application, compile and generate an artifact folder, compress it and transmit it to the domestic IT terminal device.

[0010] S2. The continuous integration server sends a remote build command to the domestic IT innovation terminal device, which includes parameters such as project identifier, target terminal architecture, Electron version, target installation package file type, and build artifact storage path.

[0011] S3. After receiving the remote build command, the build entry program on the domestic IT innovation terminal device automatically performs an update operation.

[0012] S4. On the domestic IT innovation terminal device, back up the existing program running resources corresponding to the current project identifier;

[0013] S5. Create a project directory corresponding to the project identifier on the domestic IT innovation terminal device, and decompress the received compressed package to the directory;

[0014] S6. Read the configuration file and extract the product name information from the decompressed program executable file;

[0015] S7. Based on the parameters in the remote build command, the product name information, and the decompressed program executable file, call the packaging toolchain that matches the target terminal architecture and the Electron version to execute the installation package generation process. This process includes at least compiling the native module source code using the local toolchain on the domestically developed terminal device, generating the application executable file, creating a desktop shortcut, and generating the installation and uninstallation hook script.

[0016] S8. After completing the installation package construction on the domestically developed terminal device, the generated installation package file is transferred to the storage path specified in the remote build command, and the metadata of this build is recorded.

[0017] This invention also discloses an automated Electron application building system based on a domestic IT innovation environment, characterized in that it is deployed on a continuous integration server and domestic IT innovation terminal equipment, comprising:

[0018] A build trigger and static optimization module is configured on the continuous integration server to respond to build commands, perform static analysis and dead code elimination optimization based on abstract syntax tree on the source code, compile and generate an artifact folder, and then compress and transmit it.

[0019] The remote command delivery module, configured on the continuous integration server, is used to send remote build commands to the domestic IT innovation terminal device, including parameters such as project identifier, target terminal architecture, Electron version, target installation package file type, and build artifact storage path.

[0020] A build environment management module is configured on the domestic IT innovation terminal device to automatically update the build entry program before the build begins;

[0021] The resource management module, configured in the domestic IT terminal device, is used to back up historical program resources, create project directories, and decompress received program resource compressed packages.

[0022] A configuration parsing module is configured in the domestically developed terminal device to read the configuration file from the decompressed program file and extract the product name.

[0023] The installation package generation module is configured in the domestically developed terminal device. It is used to call a packaging toolchain that matches the target terminal architecture and the Electron version based on the received build parameters, the extracted product name and the decompressed program file, and output a complete installation package containing an executable file, a desktop shortcut and an installation and uninstallation script.

[0024] The product archiving module, configured in the domestic IT innovation terminal device, is used to transmit the generated installation package to a specified storage path and record the metadata of this build.

[0025] Beneficial effects

[0026] Improve build efficiency and automation: By using the automated triggering, compilation and transmission mechanism of the continuous integration server, and the parameterized remote build command execution process on the domestic IT terminal device, the traditional source code acquisition, environment configuration, cross-platform adaptation and packaging operations that rely heavily on manual labor are transformed into a fully automated pipeline, which greatly reduces manual intervention and time consumption and supports rapid iteration.

[0027] Ensuring the determinism, security, and compatibility of the build results: First, by utilizing static code analysis based on Abstract Syntax Trees (AST) and "tree shaking" optimization techniques, unused code is precisely eliminated during the compilation phase, reducing application size and lowering the potential attack surface. Second, a "source code preservation, target terminal compilation" strategy is adopted to handle native modules, ensuring that they are compiled in an architecture and library environment completely consistent with the target domestic IT innovation environment, fundamentally solving binary compatibility issues. Finally, through an atomic build environment self-update mechanism, the build system can automatically adapt to upgrades of domestic IT innovation infrastructure software (such as operating systems and Electron), ensuring the continuous effectiveness of build capabilities.

[0028] Enhanced system reliability, maintainability, and traceability: Automated backup of historical resources before building and the creation of independent, clean project workspaces achieve isolation and state preservation during the build process, supporting rapid rollback and ensuring build reliability and reproducibility. Dynamic extraction of metadata from application configuration files achieves loose coupling between the build process and product information, improving maintainability.

[0029] Achieve deep system integration and standardized output: Through parameter-driven and template-generated packaging toolchain, automatically create desktop shortcuts and installation / uninstallation scripts that conform to the target domestic operating system specifications, and call system-level packaging tools to generate standard format installation packages. This makes the output more than just simple executable files, but distribution packages with professional system integration capabilities, improving user experience and deployment standardization. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the system modules of the present invention;

[0031] Figure 2 This is a schematic diagram of the method flow of the present invention;

[0032] Figure 3 This is a schematic diagram of the script directory structure for the method of the present invention. Detailed Implementation

[0033] Example 1: An Automated Electron Application Building System Based on a Domestic Information Technology Innovation Environment

[0034] This system is deployed on continuous integration servers and domestically developed terminal devices. Through modular collaborative work, it achieves fully automated construction from source code to installation packages that conform to domestically developed standards.

[0035] Step S1: Build Trigger and Resource Preparation: On the continuous integration server, in response to a manually triggered build command, the source code of the Electron application is compiled to generate an artifact folder containing program execution resources; the artifact folder is compressed and then transmitted to the designated domestic IT terminal device.

[0036] This step involves configuring automated build tasks on the continuous integration server to respond to external trigger commands. Upon responding, the system automatically executes a predefined build pipeline. First, based on the repository address and branch identifier recorded in the version control system, the system uses the equivalent command "git clone" to pull the complete Electron application source code to the server's temporary sandbox directory. Then, the system reads the "package.json" file in the project's root directory and calls the Node.js package manager to execute "npm ci --production," accurately reproducing the project's dependencies.

[0037] Next, the core compilation and resource packaging process begins: front-end build tools such as Webpack are invoked, and a plugin chain optimized for Electron is configured. The build tools first perform lexical and syntactic analysis on the project source code (including JavaScript / TypeScript, HTML, CSS, Vue / React components, etc.) to generate an Abstract Syntax Tree (AST). Based on the AST, the tools perform static module dependency analysis, constructing a complete module dependency graph starting from the application's entry file. By traversing this graph, the tools accurately identify exported modules that are imported but never actually invoked in any execution context, along with their entire dependency subtrees (i.e., "dead code"), and automatically remove them from the final packaged artifacts—a technique known as "Tree-shaking." Simultaneously, the build tools transpile the code (e.g., converting ESNext to ES5), obfuscate and compress it, ultimately outputting a highly optimized main application script file and associated static resources.

[0038] Regarding the handling of native modules: For binary modules written in C / C++ or Rust with the ".node" suffix, this system adopts a strategy of preserving the source code and compiling it for the target terminal. On the continuous integration server, no pre-compilation for a specific architecture is performed. Instead, the complete source code of the native module and its compilation description file (such as binding.gyp) are packaged together into the resource package. Subsequently, on the target domestically developed terminal device, the build system will automatically call the local native toolchain (such as gcc, make) to perform just-in-time compilation of the source code according to the target architecture parameters, generating a binary module that is fully compatible with the current terminal operating system and CPU architecture. This design fundamentally avoids the complexity of cross-compilation and ensures binary compatibility.

[0039] The final generated "application resource collection" follows the standard directory structure agreed upon by the Electron runtime, with the "app" folder at its core. After resource assembly, the system uses a compression tool based on the DEFLATE algorithm (such as zip) to perform lossless compression on the entire "app" folder, generating a single archive file (such as "app.tar.gz"). Subsequently, using a secure file copying tool based on the SSH protocol (such as scp), the compressed package is encrypted and transmitted to the designated receiving directory of the pre-configured target domestic IT terminal device, and renamed to the application resource file (such as "sis-im-app.tar.gz").

[0040] This step completely solves the environment consistency problem of "it can run on my machine" by locking dependency versions and sandboxing installation; through AST-level dependency graph analysis and tree-shaking, it not only reduces the volume of transmission and loading, but more importantly, removes potential security vulnerability carriers (unused library code), improving application security in the domestic IT innovation environment; by delaying the compilation of native modules to the target terminal, it cleverly avoids the extreme complexity of cross-compiling for multiple domestic IT innovation architectures on a single server, which is a key design to achieve cross-architecture compatibility of "write once, build anywhere"; and outputs a structured resource package that meets Electron's running expectations, and transmits it through an encrypted channel to ensure the integrity and confidentiality of the deliverables during transmission.

[0041] Step S2: Remote build command issuance: The continuous integration server issues a remote build command to the domestic IT terminal device via the Secure Shell protocol SSH. The build command includes at least the project identifier, target terminal architecture, Electron version, target installation package file type, and build artifact storage path parameters.

[0042] After confirming successful resource transfer, the continuous integration server establishes a secure shell channel with the target domestically developed terminal device using its integrated SSH client library. This secure shell channel is certified with an asymmetric encryption algorithm (such as RSA-2048). Once the connection is established, the server does not execute interactive commands; instead, it constructs and sends a complete, non-interactive shell command string. The core of this command is to call a pre-deployed "build entry point script" on the domestically developed terminal device, passing all necessary parameters for this build to the script as command-line arguments.

[0043] The parameters are organized using a key-value pair structure and undergo strict escaping to prevent injection attacks. A typical command format is as follows:

[0044] ssh user@target-terminal-ip ~ / maixin / pack / sis-electron-pack / pack.shsis-im-app Maxin amd64 22.3.26 deb / 1_Maxin / 2_Client / 3_Version /

[0045] Among them, "sis-im-app" refers to the application name, which is used to isolate the working spaces of different projects on the terminal; "Maxin" refers to the Chinese name of the application, which is used to set the name of the desktop shortcut when installing (this configuration will be overridden if there is a productname in the resource configuration file); "amd64" refers to the terminal architecture, which directly determines the target instruction set for subsequent compilation of native modules and selection of Electron binary files; "22.3.26" refers to the Electron version, which is used to ensure the API / ABI compatibility between the application and the runtime framework; "deb" refers to the installation package type, which specifies the installation package format that meets the requirements of the target operating system package manager (such as DPKG, RPM); " / 1_Maxin / 2_Client / 3_Version / " defines the final storage location of the build products.

[0046] This step abstracts the complex build intention into a well-defined set of parameters, achieving a declarative description of the build task, making the build process configurable, repeatable, and auditable. Communication is carried out through the mature SSH protocol, ensuring the confidentiality and integrity of instruction transmission. Non-interactive execution avoids the risk of build interruption caused by session timeout or network instability. The central server is only responsible for scheduling and passing parameters, and the specific build logic is fully implemented by the entry script on the terminal and the underlying system. This design makes it easy to manage hundreds or thousands of domestic innovation terminal devices with different software and hardware configurations and allocate appropriate build tasks to each terminal.

[0047] Step S3: Automatic update of the build environment: After receiving the remote build command, the build entry program on the domestic innovation terminal device automatically performs an update operation to obtain the latest build logic and configuration.

[0048] The self-update operation of the build entry program specifically includes the following sub-steps: S3.1, Version Query: The build entry program sends an HTTP(S) request to the pre-configured remote update server (or Git repository) to query the latest available build logical version number; S3.2, Version Comparison: The obtained remote version number is semantically compared with the version number recorded locally (e.g., following the "major version.minor version.revision number" specification); S3.3, Incremental Download: If the remote version is newer, the differential version is downloaded according to the update manifest (e.g., update_manifest.json). S3.4 Integrity Verification: Use cryptographic hash functions (such as SHA-256) to verify the integrity of the downloaded incremental packages to ensure that the data has not been tampered with; S3.5 Atomic Replacement: After verification, the new script is decompressed to a temporary directory, and then the old working directory is replaced by an atomic file renaming operation (such as the rename system call in Linux system). This ensures that the update process will not damage the original build system under any abnormal interruption, thereby ensuring that the build entry program always runs on the latest and consistent logic.

[0049] Step S4: Historical resource backup: On the domestic IT innovation terminal device, back up the existing program running resources corresponding to the current project identifier to support version rollback.

[0050] Before performing a new build, the system automatically performs state preservation. The script first checks if the working directory created for the current "project-id" exists (the apps directory). If it exists, it means that a build may have been performed previously, and the directory may contain unzipped source code, intermediate compilation files, or artifacts from the last build. The system immediately uses an archiving compression tool (such as "tar" with "gzip") to recursively package the directory into a single backup file, with the filename including the project ID and a precise timestamp, such as "sis-im-app_backup_20231027153005.tar.gz".

[0051] This backup file is moved to a dedicated backup archive, which may be located on a different storage volume. The system implements a simple lifecycle management strategy, retaining only the three most recent backups and automatically deleting earlier backups to free up storage space. The entire backup process is executed automatically as a mandatory pre-processing step in the build workflow, requiring no memory or operation from development or operations personnel.

[0052] This step creates a "checkpoint" for each build attempt. When a new build fails due to code issues, dependency conflicts, or environmental anomalies, it can immediately revert to the previous stable state, ensuring the continuity of the R&D delivery process. The preserved historical build state provides a complete context for analyzing the reasons for build failures, making it easy to compare differences and quickly locate problems. Embedding the important but tedious operation of backup into the process ensures 100% execution of the security policy.

[0053] Step S5: Project space creation and resource decompression: On the domestic IT terminal device, create a project directory corresponding to the project identifier, and decompress the received compressed package to this directory to release the program execution file.

[0054] The system creates a new subdirectory named after the current project ID (e.g., "sis-im-app") within the designated workspace (build script root directory / apps) of the domestic IT terminal device, serving as the dedicated workspace for this build. Then, it locates the transferred resource compressed package (path specified by the "application name" parameter), calls the corresponding decompression program (e.g., "tar -xzf"), and extracts all its contents into the newly created workspace. The decompression process strictly preserves the original directory hierarchy within the compressed package, ensuring the "app" folder and all its subfolders are completely restored.

[0055] The workspace is configured with appropriate access permissions during creation (e.g., allowing only build users and necessary system service accounts to read and write) to achieve basic isolation. This independent space ensures that the current build is not affected by any remnants of previous builds and also prevents resource conflicts that may occur when building the same project in parallel.

[0056] This step is the cornerstone for ensuring the determinism and reproducibility of the build results. Each build begins in a known, empty state, eliminating uncertainties such as environmental variable contamination and interference from residual files; independent directories allow the builds of the same project under different parameters, or the builds of different projects, to be safely executed in parallel on the same terminal, improving resource utilization.

[0057] Step S6: Read configuration information: Read the preset configuration file from the decompressed program executable file and extract the product name information from it.

[0058] The build system needs to retrieve metadata from the application itself to guide subsequent packaging processes. After decompression, the system navigates to the core area of ​​the restored application resources within the workspace, locating the "app.conf" file in the main configuration file directory (src). The sed command is used to read the contents of the configuration file.

[0059] From the parsed file content, the value corresponding to the configuration value productname is read as the official name string of the product. This string will be used as the name of the desktop shortcut to be created later.

[0060] This step retrieves the necessary display information directly from the source code, avoiding potential information inconsistencies that might arise from hard-coding in the build script, which aligns with DevOps practices. Applications can freely update their product names and version numbers without modifying the build system's configuration; the build system automatically detects and applies these changes.

[0061] Step S7: Installation package build execution: Based on the parameters in the build command, the product name information, and the decompressed program executable file, a specific build command is called to execute the installation package generation process. This process includes at least generating the application executable file, creating a desktop shortcut, and generating hook scripts required for the installation and uninstallation process.

[0062] This step is the culmination, integrating all previous preparations into a final, distributable installation package. The specific process is as follows:

[0063] 1. Dynamic configuration generation: Based on the installation package type (deb or rpm), different packaging scripts (deb-pack.sh or rpm-pack.sh) are called to package the application, desktop shortcut name, terminal architecture, Electron version, installation package type, storage location and other variables.

[0064] 2. Architecture-specific processing:

[0065] The build entry program automatically retrieves the corresponding Electron runtime binary file from a pre-configured local cache or trusted network source (such as an internal mirror repository) based on the target terminal architecture (e.g., amd64, arm64) and Electron version parameters. If the local cache is missing, it automatically downloads the binary file via a secure HTTP protocol, verifies its hash value, and then decompresses it to the templates / electrons / directory for later use. This process is fully automated and requires no manual intervention, ensuring build reliability in offline or semi-offline environments.

[0066] Resource integration and packaging:

[0067] The specified application resource directory under the above apps directory is used as the program resource of the generated product (e.g., sis-im-app).

[0068] 4. System integration file generation:

[0069] Desktop shortcut: Based on the input desktop shortcut name and the app.icon icon in the res directory as the preset icon path, automatically generate a desktop entry file that conforms to the ".desktop" file format specification, containing the correct localized name, icon, launch command and category.

[0070] Installation / Uninstallation Hook Scripts: The system provides a set of script templates (examples of .deb script templates (located in the build script's template / deb directory): `control.temp`, `postinst.temp`, `prerm.temp`, `postm.temp`; example of .rpm script templates (located in the build script's template / rpm directory): template.spec). During the build process, based on the current project information (such as the path to the executable file after installation, service names, etc.), the template engine (string replacement) replaces the variables in the templates with actual values, generating the final control scripts. These scripts are responsible for setting file permissions after installation, creating menu items, or stopping related services and cleaning up user data before uninstallation.

[0071] 5. Package into an installer: Finally, the underlying system packaging tool (such as `dpkg-deb` or `rpmbuild`) is called to package the self-contained application directory, desktop files, control scripts, etc., into a standard software package (such as a `.deb` or `.rpm` file) that can be installed and uninstalled by the system package manager, according to the target package format specifications.

[0072] This step automates highly specialized and complex tasks such as cross-platform binary adaptation and system packaging standard compliance through toolchain integration and parameterized configuration, freeing developers from tedious low-level details. The generated package is not just an executable file, but a complete distribution package that includes standard desktop integration and complies with system management standards, enhancing the software's professionalism and user experience in the domestic IT operating system.

[0073] Step S8: Archive the build product: After the installation package is built on the domestically developed terminal device, the generated installation package file is transferred to the storage path specified in the build command.

[0074] After successful build, the generated installation package file (e.g., `sis-im-app_arm64_202510011101.deb`) is located in the ~ / maixin / pack directory. Then, using an efficient file synchronization tool (`scp`), the installation package is transferred to the centralized storage server or network attached storage (NAS) specified by the parameters.

[0075] Simultaneously, all key information from this build was structured into a single record and written to the local build log system. This record includes: project ID, build timestamp, trigger method, all input parameters, build system version used, Electron version, target architecture, full path to the generated installation package, and build process status (success / failure). This metadata is inextricably linked to the actual binary file.

[0076] This step's complete metadata record enables full traceability from the final installation package to a specific source code version, build environment, and parameters, meeting the stringent requirements of the information technology innovation industry for software supply chain security auditing. It automatically collects build artifacts scattered across various terminals into a unified location, facilitating version management, vulnerability scanning, signing, and distribution to testing or production environments. The accumulation of build records provides a data foundation for analyzing build efficiency, success rate, and problem patterns, supporting continuous improvement of the build process.

[0077] Example 2: An automated Electron application building system based on the domestic IT innovation environment.

[0078] This system is deployed on continuous integration servers and domestically developed IT terminal devices. Through modular collaborative work, it achieves fully automated construction from source code to an installation package compliant with domestically developed IT standards. The technical solutions, working processes, principles, and effects of each module are described in detail below:

[0079] 1. Construct trigger and static optimization modules

[0080] This module is deployed on a continuous integration server, and its core is a listener-response executor. It listens for build commands from the user interface or API. Once triggered, the source code retrieval unit within the module pulls the specified version of the Electron application source code from a remote repository to the server's isolated environment via a version control protocol. Subsequently, the dependency management and compilation unit starts: first, it calls the package manager to install all Node.js dependencies in the sandbox according to the precise description in the project dependency declaration file (such as package.json); then, it calls a static code analysis optimizer based on an abstract syntax tree (AST). This optimizer builds a module dependency graph, applies a graph traversal algorithm to perform reachability analysis, identifies and removes all "dead code" nodes and their subtrees (i.e., tree-shaking) that are not referenced by any entry point. Simultaneously, it transpiles, compresses, and obfuscates the code. For native modules that need to be compiled, this module adopts a source code preservation strategy, only encapsulating its source code in a resource package without performing cross-platform compilation. Finally, the resource packaging and transmission unit organizes the optimized code, static resources, and native module source code into an "application" folder according to the standard directory structure expected by Electron runtime, packages it using a lossless compression algorithm (such as DEFLATE), and pushes it to the target domestic IT terminal device via a secure file transfer protocol (such as SCP based on SSH).

[0081] This module achieves complete automation and standardization of the build process. Through AST-level static analysis and graph algorithms, precise dependency pruning and dead code elimination fundamentally reduce deliverable size and lower security risks. Its innovation lies in its "source code preservation, terminal compilation" strategy for native modules, elegantly solving the extreme complexity of pre-compiling binary compatible packages on a single server for heterogeneous IT architectures (such as ARM64, MIPS, and LoongArch), laying the foundation for subsequent cross-architecture builds.

[0082] 2. Remote command issuance module

[0083] This module, also located on the continuous integration server, is fundamentally a secure channel communication and instruction encapsulator. After resource transfer is complete, this module establishes a Secure Shell (SSH) connection with the target IT application terminal device via asymmetric encryption authentication. Its parameterized instruction construction unit encapsulates the context information of this build (such as project ID, target CPU architecture, Electron version, target package format, and artifact storage path) into a structured, strongly typed data object (e.g., JSON format). This data object is sent to the IT application terminal device via an encrypted channel and received and parsed by the terminal's daemon or script.

[0084] Using structured data objects instead of raw string commands for remote calls enhances the system's robustness, scalability, and auditability. Secure channels ensure the confidentiality and integrity of scheduling instructions. This design achieves clear decoupling between central scheduling and edge execution, enabling a single scheduling system to flexibly manage hundreds or thousands of domestically developed terminal devices with different configurations.

[0085] 3. Build an environment management module

[0086] This module, deployed on domestically developed terminal equipment, acts as a self-maintaining and update manager. Upon receiving a remote command, it does not immediately execute the user build. Instead, the version comparison and update triggering unit first queries a trusted central metadata service for the latest build system version. Using a semantic version comparison algorithm, it determines whether an update is needed. If so, the incremental download and application unit securely downloads the incremental update package according to the list provided by the service. After verifying the file integrity locally using cryptographic hashing, it performs atomic file operations (such as placing the new file in a temporary location, verifying it, and then atomically renaming and replacing it) to complete the self-upgrade, ensuring the system is not damaged due to update interruption.

[0087] This module enables the system to achieve "perpetual" adaptability. It allows widely distributed terminals to automatically and seamlessly adapt to upgrades to domestically developed operating systems, the Electron framework, or the addition of new architectures, significantly reducing operational costs. The atomic update mechanism ensures high reliability during the update process, a key guarantee for the long-term stable operation of the system.

[0088] 4. Resource Management Module

[0089] This module runs on domestically developed terminal equipment and is responsible for the lifecycle management of the build site. Its historical snapshot unit automatically checks and archives the existing project working directory before the build begins, creating a timestamped compressed backup to ensure state preservation. The environment isolation unit then creates a brand new, clean working directory named after the project ID. The resource restoration unit then decompresses the received resource packages into this directory, strictly maintaining the original file structure and attributes.

[0090] Automated backups provide robust fault tolerance and second-level rollback capabilities. Creating an independent, clean workspace is core to ensuring the determinism and reproducibility of build results. It eliminates build contamination caused by environmental remnants and is the cornerstone for supporting parallel builds and CI / CD reliability.

[0091] 5. Configure the parsing module

[0092] This module is a metadata extractor. It navigates to the standard location of the uncompressed application resources and locates the main configuration file (such as app.conf). The configuration file parsing engine within the module loads and parses this file, extracting key metadata such as product name and version number according to predefined field mappings and priority rules (such as prioritizing `productName`), and injecting it into the build context.

[0093] It achieves loose coupling between the build process and product information, and single data source management. Changes to application metadata can be automatically and accurately reflected in the final installation package without manual modification of build configuration, avoiding information asynchrony errors and improving the intelligence level of the process.

[0094] 6. Installation package generation module

[0095] This is the system's core encapsulation and integration engine. First, based on parameters (architecture, package format, etc.) from remote instructions, the dynamic configuration rendering unit generates a targeted packaging toolchain configuration file. The native module cross-compilation unit then triggers local compilation for the target domestic IT architecture, generating compatible binary dependencies. The application assembly unit merges the optimized code, compiled native modules, and the corresponding Electron runtime into a self-contained application image. The system integration file generation unit uses a template engine to dynamically generate shortcut files conforming to the target desktop environment specifications, as well as control scripts (such as "control, postinst, prerm, postrm") required for package installation, uninstallation, and upgrades, and injects instantiation parameters based on the extracted product name. Finally, the standardization packaging unit calls the underlying system packaging tools to encapsulate all components into a standard software package according to the target format specifications.

[0096] This module encapsulates highly complex and specialized technical details such as cross-platform adaptation, native compilation, and deep system integration into an automated pipeline. Its innovation lies in dynamically generating professional-grade distribution packages that comply with the strict specifications of different domestic operating systems through parameter-driven and template-based methods, rather than just executable files. This significantly lowers the technical threshold for creating compliant installation packages and ensures the consistency of output quality.

[0097] 7. Product Archiving Module

[0098] This module serves as the endpoint and audit point of the build process. Its digital fingerprint generation unit calculates the cryptographic hash value for the generated installation package. The artifact transmission and storage unit then transmits the installation package and hash value file to a centralized artifact repository, where they are automatically categorized and stored by project, version, and architecture. Simultaneously, the build metadata recording unit persists structured information such as parameters, environment, version, artifact path, and hash value from the entire build process to the database as an immutable record.

[0099] It achieves traceability of build artifacts and transparency in the software supply chain. Hash-linked metadata records provide a complete chain of evidence for software origin verification, security audits, and compliance checks. Centralized artifact management provides a single, trusted source for automated testing, security scanning, and release deployment, serving as a critical infrastructure supporting DevOps and the security of the domestically developed software supply chain.

[0100] Through the precise collaboration of the aforementioned modules, this system constructs a highly automated, adaptive, and auditable build pipeline. Its innovation lies not only in the technical depth of individual modules but also in its system-level solution to core pain points faced by Electron application builders in complex and heterogeneous IT innovation environments, such as significant environmental differences, excessive manual operations, difficulty in standardization, and opaque supply chains, thus achieving a transformation from "manual adaptation" to "intelligent delivery."

[0101] This invention discloses an automated Electron application building system and method based on a domestically developed IT environment. It constructs a complete automated technology system encompassing build triggering and standardized resource preparation, cross-platform parameterized instruction scheduling, build environment self-updating, resource isolation management, metadata-driven configuration, and adaptive packaging and archiving for domestically developed IT systems. Through this method and system, it achieves a "one-click" efficient and reliable conversion of Electron applications from source code to standard installation packages conforming to the target operating system specifications in a complex and heterogeneous domestically developed IT environment.

[0102] This invention significantly improves build efficiency and reduces labor costs and error rates through end-to-end automation and deep optimization. By leveraging environment self-updating and native compilation mechanisms on the target platform, it ensures the continuous compatibility of the build system and its outputs with the evolving domestic IT infrastructure software and hardware ecosystem. Furthermore, through complete resource isolation, backup, and traceability records, it enhances the reliability, reproducibility, and auditability of the build process and the software supply chain. This invention provides strong technical support for the large-scale, standardized delivery of high-quality Electron desktop applications in the domestic IT innovation field, which demands independent control, security, and compliance.

[0103] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention. The scope of protection claimed by the appended claims and their equivalents is defined.

Claims

1. An Electron application automatic construction method based on Xinchuang environment, characterized in that, Includes the following steps: S1. On the continuous integration server, perform static analysis and dead code elimination optimization based on abstract syntax tree on the source code of the Electron application, compile and generate an artifact folder, compress it and transmit it to the domestic IT terminal device. S2. The continuous integration server sends a remote build command to the domestic IT innovation terminal device, which includes parameters such as project identifier, target terminal architecture, Electron version, target installation package file type, and build artifact storage path. S3. After receiving the remote build command, the build entry program on the domestic IT innovation terminal device automatically performs an update operation. S4. On the domestic IT innovation terminal device, back up the existing program running resources corresponding to the current project identifier; S5. Create a project directory corresponding to the project identifier on the domestic IT innovation terminal device, and decompress the received compressed package to the directory; S6. Read the configuration file and extract the product name information from the decompressed program executable file; S7. Based on the parameters in the remote build command, the product name information, and the decompressed program executable file, call the packaging toolchain that matches the target terminal architecture and the Electron version to execute the installation package generation process. This process includes at least compiling the native module source code using the local toolchain on the domestically developed terminal device, generating the application executable file, creating a desktop shortcut, and generating the installation and uninstallation hook script. S8. After completing the installation package construction on the domestically developed terminal device, the generated installation package file is transferred to the storage path specified in the remote build command, and the metadata of this build is recorded.

2. The method of claim 1, wherein, Step S1 specifically includes: S1.

1. Use version control commands to pull the source code to the server's temporary sandbox directory; S1.2 Read the project dependency declaration file and call the Node.js package manager to execute the installation command to accurately reproduce the dependency environment; S1.3 Call the front-end build tool and configure the abstract syntax tree analysis plugin to generate a module dependency graph. Traverse the graph to identify and remove unreferenced dead code. S1.4 Translate, obfuscate, and compress the retained code to generate the application main script file and static resources with hash fingerprints; S1.5 Package the dependencies, including the source code of the native module and its compilation description file, into the artifact folder, and do not perform cross-architecture pre-compilation on the server side; S1.

6. Package the product folder using a lossless compression algorithm and encrypt it using a secure file copying tool based on the SSH protocol to transmit it to the designated receiving directory of the domestically developed terminal device.

3. The method of claim 1, wherein, Step S2 specifically includes: The continuous integration server establishes a secure shell channel with the domestically developed terminal device through its integrated SSH client library, which is authenticated by an asymmetric encryption algorithm. It constructs a non-interactive shell command string, which is based on calling the pre-deployed build entry script on the domestically developed terminal device. The string appends the project identifier, target terminal architecture, Electron version, target installation package file type, and build artifact storage path as key-value pairs as command-line parameters, and escapes the parameter values ​​to prevent injection attacks. This command is then sent through the secure shell channel.

4. The method of claim 1, wherein, The automatic update operation described in step S3 includes: The build entry program sends a version query request to the remote update server or code repository to obtain the latest build logic version number; it performs a semantic comparison between the remote version number and the local version number; if the remote version is newer, it downloads the incremental update package according to the update list; it uses a cryptographic hash function to verify the integrity of the downloaded incremental package; after the verification is successful, it decompresses the new file to a temporary directory and replaces the old working directory through an atomic file renaming operation to ensure that the build system is not damaged in the event of an abnormal interruption of the update process.

5. The method of claim 1, wherein, The backup mentioned in step S4 specifically includes: The build entry program checks whether the working directory created for the current project identifier exists; if it exists, it uses an archive compression tool to recursively package the directory into an independent backup file, with the backup file name containing the project identifier and a precise timestamp; the backup file is transferred to a dedicated backup archive area, and a lifecycle management strategy is automatically executed, retaining only the most recent predetermined number of backups and automatically deleting earlier backup files that have exceeded the retention limit.

6. The method according to claim 1, characterized in that, Step S6, which involves reading the configuration file and extracting the product name information, specifically includes: Navigate to the core area of ​​the decompressed application resources and locate the main configuration file; use a text processing command to read the contents of the configuration file, parse it, and extract the values ​​of preset fields as the official name string of the product; if the field is not defined in the configuration file, use the alternative name issued in the build command.

7. The method according to claim 1, characterized in that, Step S7, which involves invoking a packaging toolchain that matches the target terminal architecture and Electron version, specifically includes: Based on the target terminal architecture, the system automatically retrieves the corresponding Electron runtime binary file from the local cache or a trusted network source; based on the target installation package file type, it selects the corresponding underlying system packaging tool; based on the product name information, it uses a template engine to replace the variables in the template with the actual project information based on the template files in the preset script template directory, generating desktop shortcut files and hook scripts for pre-installation, post-installation, pre-uninstallation, and post-uninstallation that conform to the target operating system specifications; finally, it calls the underlying system packaging tool to package the self-contained application directory, desktop files, and hook scripts into a standard format installation package.

8. An automatic Electron application building system based on a domestic IT innovation environment, characterized in that, Deployed on continuous integration servers and domestic IT application development terminal devices, including: A build trigger and static optimization module is configured on the continuous integration server to respond to build commands, perform static analysis and dead code elimination optimization based on abstract syntax tree on the source code, compile and generate an artifact folder, and then compress and transmit it. The remote command delivery module, configured on the continuous integration server, is used to send remote build commands to the domestic IT innovation terminal device, including parameters such as project identifier, target terminal architecture, Electron version, target installation package file type, and build artifact storage path. A build environment management module is configured on the domestic IT innovation terminal device to automatically update the build entry program before the build begins; The resource management module, configured in the domestic IT terminal device, is used to back up historical program resources, create project directories, and decompress received program resource compressed packages. A configuration parsing module is configured in the domestically developed terminal device to read the configuration file from the decompressed program file and extract the product name. The installation package generation module is configured in the domestically developed terminal device. It is used to call a packaging toolchain that matches the target terminal architecture and the Electron version based on the received build parameters, the extracted product name and the decompressed program file, and output a complete installation package containing an executable file, a desktop shortcut and an installation and uninstallation script. The product archiving module, configured in the domestic IT innovation terminal device, is used to transmit the generated installation package to a specified storage path and record the metadata of this build.

9. The system according to claim 8, characterized in that, The construction triggering and static optimization module includes: The source code retrieval unit is used to pull a specified version of source code from a remote repository to the sandbox environment via a version control protocol. The dependency management unit is used to precisely install Node.js dependencies based on the project's dependency declaration file. The static analysis unit is used to call Webpack and the abstract syntax tree analysis plugin to generate a module dependency graph and perform dead code elimination. The resource packaging unit is used to organize the optimized code, static resources, and native module source code according to the standard directory structure of the Electron runtime, and perform lossless compression. The secure transmission unit is used to encrypt and transmit compressed packages to domestically developed terminal devices via a secure file copy protocol based on the SSH protocol.

10. The system according to claim 8, characterized in that, The construction environment management module includes: The version detection unit is used to query the latest build logic version number from the remote update server; The incremental update unit is used to download the incremental update package based on the version comparison results and perform cryptographic hash integrity verification. The atomic substitution unit is used to decompress the downloaded new file to a temporary directory and replace the old working directory through an atomic file renaming operation.

11. The system according to claim 8, characterized in that, The installation package generation module includes: The runtime adaptation unit is used to automatically obtain the corresponding Electron runtime binary file based on the target terminal architecture and Electron version parameters. The native module compilation unit is used to call the local compiler on the domestic IT terminal device to compile the source code of the native modules distributed with the resource package in real time; The template rendering unit is used to replace variables in the template with parameters such as product name based on the preset script template directory, and generate desktop shortcut files and installation / uninstallation hook scripts. The packaging execution unit is used to call the underlying system packaging tools to package the assembled application directory, desktop files, and hook scripts into a standard format installation package.

12. The system according to claim 8, characterized in that, The resource management module includes: The historical backup unit is used to check the existing project working directory before decompressing resources. If it exists, it is recursively packaged into a timestamped backup file and transferred to the backup archive area. The lifecycle management unit is used to automatically delete the oldest backup that has exceeded the retention limit; Spatial isolation units are used to create a completely new, independent working directory named after the project identifier for each build, and to set access permissions; The decompression and restoration unit is used to decompress the received compressed package to a newly created working directory, strictly maintaining the original directory structure.

Images