Application program automatic construction method, device and computer equipment

Abstract

The application relates to the technical field of software development, and discloses an automatic construction method and device of an application program and computer equipment, wherein a construction request of a target application program is acquired; an Electron temporary directory and a Python temporary directory are created in response to the construction request; an Electron part and a Python part in the target application program are pulled into the Electron temporary directory and the Python temporary directory respectively; a construction operation is performed in the Electron temporary directory and the Python temporary directory, and a construction product is generated; the construction products of two construction sub-processes are extracted, and the construction products are written into an output directory; and the output directory is packed to obtain a release package of the target application program. The application has the beneficial effect of improving the construction efficiency of a mixed application program of Electron+Python.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method, apparatus, and computer device for automating the construction of applications. Background Technology

[0002] With the widespread use of computer devices in daily life, desktop applications have developed rapidly and become an important tool in people's lives and work.

[0003] Currently, most automated build solutions for applications are designed with a single technology stack. For example, Electron applications can be automated through electron-builder. Python applications can be built independently using PyInstaller in conjunction with CI / CD tools such as Jenkins.

[0004] However, with the widespread adoption of hybrid applications combining front-end interaction and high-performance back-end computing, automated build solutions designed for single technology stacks are unable to build such applications. Therefore, hybrid applications suffer from low build efficiency. Summary of the Invention

[0005] This application provides an automated application building method, apparatus, and computer device, which solves the technical problem of low building efficiency of Electron+Python hybrid applications and achieves the technical effect of improving the building efficiency of Electron+Python hybrid applications.

[0006] To achieve the above objectives, the main technical solutions adopted in this application include:

[0007] In a first aspect, embodiments of this application provide an automated application building method, the method comprising:

[0008] Obtain the build request for the target application, which is used to automatically build the target application; the target application is a hybrid application built with Electron and Python.

[0009] In response to the build request, an Electron temporary directory and a Python temporary directory are created; the Electron and Python parts of the target application are concurrently pulled into the Electron temporary directory and the Python temporary directory, respectively;

[0010] In response to the build request, two build sub-processes are created; using the build sub-processes, the Electron part of the target application in the Electron temporary directory and the Python part of the target application in the Python temporary directory are processed concurrently, and build artifacts are generated respectively.

[0011] Extract the build artifacts from the two build sub-processes and write them to the output directory; package the output directory to obtain the release package of the target application.

[0012] In this embodiment, by fetching Electron and Python code in parallel based on build requests, building Electron and Python build artifacts in parallel, and then copying the build artifacts to the final output file for packaging, the efficient and automated building of Electron and Python hybrid applications and the rapid generation of release packages are achieved.

[0013] Secondly, embodiments of this application provide an automated application building apparatus, the apparatus comprising:

[0014] The acquisition module is used to acquire the build request of the target application, which is used to automatically build the target application; the target application is a hybrid application built with Electron and Python.

[0015] A parallel module is configured to, in response to the build request, create an Electron temporary directory and a Python temporary directory; concurrently pull the Electron and Python parts of the target application into the Electron temporary directory and the Python temporary directory, respectively; in response to the build request, create two build sub-processes; and use the build sub-processes to concurrently process the Electron part of the target application in the Electron temporary directory and the Python part of the target application in the Python temporary directory, and generate build artifacts respectively.

[0016] The publishing module is used to extract the build artifacts from the two build sub-processes and write the build artifacts into the output directory; and to package the output directory to obtain the publishing package of the target application.

[0017] Thirdly, embodiments of this application provide a computer device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the method described in any of the above embodiments.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer instructions, which are used to cause a computer to perform the method described in any one of the above embodiments.

[0019] Fifthly, embodiments of this application provide a computer program product, including computer instructions, which are used to cause a computer to perform the method described in any of the above embodiments. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating the automated construction of an Electron application is provided as an embodiment of this application;

[0022] Figure 2 An architecture diagram of an automated application building system provided in this application embodiment;

[0023] Figure 3 A flowchart illustrating an automated application building method provided in this application embodiment;

[0024] Figure 4 A flowchart illustrating an automated application building method provided in this application embodiment;

[0025] Figure 5 A flowchart illustrating the execution process of constructing a sub-process, provided as an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of a product merging structure provided in an embodiment of this application;

[0027] Figure 7 A flowchart illustrating log push functionality provided in this application embodiment;

[0028] Figure 8 A flowchart illustrating the establishment of bidirectional real-time communication via WebSocket is provided in this application embodiment;

[0029] Figure 9 A flowchart illustrating a concurrency control method provided in an embodiment of this application;

[0030] Figure 10A flowchart illustrating a method for canceling a construction task, as provided in this application embodiment;

[0031] Figure 11 A flowchart illustrating resource cleanup provided in this application embodiment;

[0032] Figure 12 A structural diagram of an automated application building apparatus provided in this application embodiment;

[0033] Figure 13 This is a structural diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0035] Currently, in the field of desktop application development, most existing automated build and deployment solutions are designed for a single technology stack.

[0036] For example, in the automated building of Electron applications, tools such as electron-builder or electron-packager are used for packaging, and CI / CD tools such as Jenkins and GitHub Actions are used to complete the automated build. The entire process includes: cloning the code repository → installing dependencies (npm install) → executing the build script (npm run build) → generating the installation package (.exe, .dmg, etc.) → uploading to a file server or object storage.

[0037] The automated build process for this Electron application can be as follows: Figure 1As shown, developers push code to a Git repository. This Git repository can be GitLab, GitHub, etc. The CI / CD platform then triggers a build task. This CI / CD platform can be Jenkins, etc. After receiving the task, the build server pulls the code to its local working directory, then executes the `npm install` command to install Node.js dependencies, and then runs `npm run build:win` or a similar command to perform the packaging process. After packaging is complete, electron-builder generates a Windows installer or portable version, and finally uploads the build artifacts to a file server and sends a build completion notification to relevant personnel. The Windows installer can be in .exe format.

[0038] For example, in the automated build process of Python applications, tools such as PyInstaller and cx_Freeze are used to package Python scripts into executable files, which is also automated in conjunction with a CI / CD platform. The entire process includes: cloning code → configuring the Python environment → installing dependencies (pip install) → executing the packaging command (pyinstaller) → generating the .exe file → publishing.

[0039] The main difference between the automated build process for this Python application and that for an Electron application is that the Python application uses PyInstaller instead of electron-builder and pip instead of npm.

[0040] However, when using hybrid Electron+Python applications, the current practice is typically to build the Electron and Python components separately and then manually integrate them. A hybrid Electron+Python application can be an application where the front-end interface uses Electron, and the back-end computation or business logic uses Python. Specifically, this manual integration process involves manually copying the build artifacts of both parts to the same directory, manually writing startup scripts or configuration files, manually packaging them into a final installer or compressed file, and finally manually uploading them to a server or cloud storage.

[0041] However, the approach of manually integrating the Electron and Python parts after building them separately has many drawbacks.

[0042] One issue is the lack of support for hybrid architecture integration. Current automated build tools and CI / CD platforms are primarily designed for a single technology stack, lacking native support for hybrid architecture applications like Electron+Python. Development teams need to maintain two separate sets of build scripts and configurations, writing numerous custom scripts to coordinate the process, resulting in complex configurations, high maintenance costs, and a high risk of errors.

[0043] Secondly, the process involves a lot of manual work and is inefficient. In the current solution, even though the separate builds of Electron and Python are automated, the process of integrating them into the final release package still requires a lot of manual work.

[0044] Optionally, the manual operation may include manually waiting for two build tasks to complete, manually downloading or copying two parts of the build artifacts, manually merging files into a unified directory structure, manually adding a launcher or configuration file, manually creating a compressed package, and manually uploading to a cloud storage service.

[0045] Alternatively, consider a medical image analysis software as an example. This software uses an Electron interface and a Python image processing algorithm architecture. Each new version release takes approximately 10 minutes to build with Electron, 5 minutes with Python, 15-20 minutes for manual integration and packaging, and 5 minutes for manual upload to the cloud platform's Object Storage Service (OSS). The total time is approximately 35-40 minutes and requires dedicated monitoring.

[0046] Thirdly, there is a lack of unified version management and path specifications. In existing solutions, there is a lack of unified management for Electron and Python version numbers, build artifact naming conventions, and cloud storage paths. This leads to difficulties in version tracing, user confusion, and cumbersome maintenance and search. For example, the Electron version number might be v2.3.1, while the Python version number might be v2.3.0. Another example is that the Electron file might be named app-v2.3.1.exe, and the Python file might be named python_service_2.3.1.exe. Furthermore, Electron and Python files might be stored in different directories.

[0047] Fourthly, the setup environment is complex. Electron and Python have different environment requirements, and their dependencies may conflict. Configuring and maintaining a CI / CD environment involves a large workload, and it's easy for local builds to succeed while CI builds fail.

[0048] Fifth, there is a lack of real-time monitoring and error tracking. Existing build solutions only notify developers of the results after the build is complete, preventing them from viewing progress, detecting warnings, and locating failure steps in real time.

[0049] Currently, the main technical reasons for these shortcomings are that Electron and Python have completely different technology ecosystems, with their respective build tools and workflows being independent; existing CI / CD tools require extensive custom configuration to support hybrid architectures; and there is a lack of a unified abstraction layer to coordinate the build processes of different technology stacks. The business reasons for these shortcomings are that most applications use a single technology stack, hybrid architecture applications are relatively rare; and tool vendors focus more on general-purpose scenarios, providing insufficient in-depth support for specific architectures.

[0050] In summary, applications using a hybrid Electron+Python architecture currently face challenges in continuous integration and deployment, including inefficiency, error susceptibility, and maintenance difficulties. To address these issues, this application proposes an automated build method for hybrid Electron and Python applications.

[0051] The automated build method of this application is applied to the field of software development and deployment automation technology. This method is particularly suitable for continuous integration and continuous deployment of hybrid application systems that simultaneously contain Electro and Python executables. Optionally, the hybrid application can be based on a cross-platform desktop application framework of Chromium and Node.js.

[0052] First, the automated build method of this application enables one-click automated build of hybrid Electron and Python applications. This automated build process can simultaneously build, merge, and package the Electron frontend and Python backend in a single operation, without manual intervention.

[0053] Secondly, the automated build method proposed in this application achieves unified management of the build process and version control for hybrid architecture applications. By building a unified system and standards, it ensures that the versions of all parts of the application are strictly consistent and highly traceable. Specifically, this method can automatically extract version numbers, generate standardized file names, upload build artifacts to the OSS object storage service, and generate public access links, thus forming a complete closed-loop process from build to release.

[0054] Furthermore, this application leverages a web console to provide developers with a real-time monitoring and visualization experience of the build process, displaying build progress, log output, and status changes in real time, helping developers to promptly identify and resolve issues. Simultaneously, the real-time visualization system built on WebSocket achieves zero-latency log push and status synchronization, offering significant advantages over traditional polling or page refresh methods.

[0055] Finally, this application encapsulates the build environment using a service-oriented approach, which can automatically complete tasks such as installing Electron and Python dependencies and configuring the environment, effectively simplifying the configuration and maintenance process of the hybrid build environment and significantly reducing the complexity of environment configuration. Simultaneously, this application also constructs a robust resource management and error recovery mechanism, using AbortController, automatic cleanup, and retry mechanisms to ensure the system's long-term stable operation.

[0056] Furthermore, this application introduces core mechanisms such as concurrent build, intelligent retry, and automatic cleanup. On the one hand, it maximizes resource utilization through concurrent task execution and intelligent queue management, significantly shortening the overall build time. On the other hand, it automatically handles temporary network or system anomalies with the help of intelligent retry strategies, and avoids resource conflicts with the automatic cleanup mechanism. Ultimately, it improves build and deployment efficiency while ensuring high system reliability.

[0057] For hybrid Electron and Python applications, comparing the automated build method of this application with the current approach of manually deploying the Electron and Python components of a hybrid application separately reveals the following:

[0058] Firstly, in terms of efficiency, the traditional manual workflow takes 35-40 minutes in total: 5 minutes for code retrieval + 15 minutes for Electron build + 8 minutes for Python build + 5 minutes for manual merging + 5 minutes for uploading. In this application, however, concurrent retrieval takes 3 minutes + concurrent build takes 10 minutes + automatic merging and packaging takes 2 minutes, totaling only 12-15 minutes. This demonstrates an efficiency improvement of approximately 60%, saving 20-25 minutes per release. This improvement is attributed to concurrent execution of build tasks, automated merging and packaging, and automatic execution during non-working hours.

[0059] Secondly, we unified the management of version numbers, ensuring consistency between Electron, Python, and filenames. We used automated scripts to fix the file copy list, avoiding the omission of APP.exe or other dependent files. We strictly followed the configuration to pull specified branches, preventing the mixing of test and production code. We eliminated manual input errors by hard-coding file paths and naming conventions. Based on these operations, in terms of reliability, the error rate was reduced from approximately 15% in manual processes to below 2%, a reduction of 87%.

[0060] Furthermore, the web console displays color-coded, tiered logs in real time, allowing developers to view the complete logs directly in their browsers, track progress at any time, and quickly locate issues without requiring additional permissions. Leveraging zero-latency WebSocket push functionality, the time to locate issues is reduced from 10 minutes to 1 minute, saving 90% of network request diagnostic efficiency compared to polling.

[0061] Furthermore, compared to the traditional approach where each developer needs to install multiple tools and configure environment variables locally, this application only requires one build server, making dependency upgrades and new team members more convenient. Environment configuration time has been reduced from 4 hours to 0, significantly simplifying environment configuration and maintenance.

[0062] In addition, in terms of version management, file names include version numbers and timestamps, OSS storage is divided into directories by version, build logs record detailed information that can be traced back to specific code versions, and historical versions can be viewed and quickly rolled back through the OSS console or API. Build logs are persistently stored for easy review.

[0063] According to an embodiment of this application, an automated build method is provided, which solves the problem of automated build and deployment of hybrid architecture applications by building services, unifying processes, and monitoring in real time.

[0064] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed on a computer device via a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here. The computer device can be a mobile terminal, a personal computer, a server, etc.

[0065] Figure 2 An architecture diagram of an automated application building system provided in this application embodiment is shown below. Figure 2 As shown, this automated build system operates on a computer device, with the computer device as the execution subject. The automated build system includes: a web dashboard, a build service, build executors, resource managers, and data storage.

[0066] The Web Dashboard is a web-based front-end interface built on HTML5 and JavaScript. It provides a visual build configuration interface, real-time log display, and build status monitoring. The Web Dashboard can initiate build requests via HTTP API and receive real-time logs and status updates via WebSocket.

[0067] The Build Service is a web service built on the Node.js + Express framework. It receives build requests, schedules build tasks, and manages the build lifecycle. Its core modules consist of a routing layer, a build manager, and a WebSocket service.

[0068] The `buildRoutes.js` utility receives and validates API requests. The `buildManager.js` utility manages the build queue and handles concurrency control. The `websocketService.js` utility pushes logs and status updates in real time. The `buildExecutors` utility can consist of specialized build modules for different technology stacks. These build executors can include Electron builders, Python builders, and ensemble builders.

[0069] The Electron builder (electronBuilder.js) handles the building of Electron applications. The Python builder (pythonBuilder.js) handles the building of Python applications. The combined builder (combinedBuilder.js) coordinates the building of hybrid applications.

[0070] The Resource Managers can be composed of service modules responsible for interacting with external resources. These Resource Managers may include a GitLab service, an OSS uploader, and file utility tools. The GitLab service (gitlabService.js) is used to pull source code from the code repository. The OSS uploader (ossUploader.js) is used to upload build artifacts to Alibaba Cloud Object Storage. The file utility tools (fileUtils.js) are used for file operations, compression, and cleanup.

[0071] Data storage includes three parts: temporary storage, artifact storage, and log storage.

[0072] Temporary storage (temp / ) is used for temporary files during the build process. Artifacts storage (artifacts / ) is used for the final artifacts after the build is complete. Log storage (logs / 2) is used for persistent build logs.

[0073] Figure 3 A flowchart illustrating an automated application building method provided in this application embodiment is shown below. Figure 2 Based on the illustrated embodiments, as Figure 3 As shown, with a computer device as the execution subject, the process includes the following steps:

[0074] S301. Obtain the build request for the target application. The build request is used to automate the construction of the target application. The target application is a hybrid application built with Electron and Python.

[0075] For example, the computer device first listens for a build request from a web console (client). This build request instructs for an automated build of the target application. The target application is a hybrid application built using both Electron and Python.

[0076] In one implementation, the build request is a user-triggered instruction to build the target application. Optionally, the build request may include Electron branch parameters, Python branch parameters, target platform, version number, and whether to upload to OSS, etc.

[0077] In one implementation, Electron is a framework based on Chromium and Node.js, used to build the front-end of cross-platform desktop applications.

[0078] In one implementation, Python is used as the language for implementing the backend logic, and it is usually combined with tools such as PyInstaller to generate executable files.

[0079] In one implementation, the computer device can receive build requests via a REST API or a message queue such as RabbitMQ.

[0080] Optionally, the computer device may write a build request to the end of a queue upon receiving it. The computer device may retrieve currently processed build requests from the head of the queue in a first-in, first-out (FIFO) order. The computer device may also determine the build requests currently being processed for the retaining wall based on its computing power and concurrency. The computer device may write new build requests into the queue when there are insufficient computing power or the maximum number of concurrent build requests is reached.

[0081] In one implementation, the computer device can parse the parameters in the build request. Optionally, the computer device can verify the validity of each parameter according to preset rules. Optionally, the computer device can also verify the completeness of the parameters in the build request based on whether the parameters are indispensable.

[0082] S302. In response to the build request, create an Electron temporary directory and a Python temporary directory; concurrently pull the Electron and Python parts of the target application into the Electron temporary directory and the Python temporary directory, respectively.

[0083] For example, in response to a build request, a computer device can create two separate temporary directories in its local file system. These two temporary directories can be an Electron temporary directory and a Python temporary directory, respectively. Subsequently, the computer device can concurrently pull the Electron and Python portions of the target application from the code repository to the corresponding directories.

[0084] In one implementation, the Electron temporary directory is a folder used to temporarily store the Electron frontend code. It is cleaned up after the build is complete.

[0085] In one implementation, the Python temporary directory is a folder used to temporarily store the Python backend code. It is cleaned up after the build is complete.

[0086] In one implementation, concurrent fetching refers to executing two code fetching operations simultaneously through multi-threaded or asynchronous tasks to improve efficiency.

[0087] In one implementation, the code repository can be GitLab, GitHub, etc.

[0088] In one implementation, computer devices can create temporary directories using the mkdir command or a programming language such as Python's tempfile module.

[0089] In one implementation, computer devices can concurrently pull code via Git commands (such as git clone) or APIs (such as the GitHub REST API).

[0090] In one implementation, if the code repository requires authentication, the computer device can be configured with an SSH key or an OAuth token to enable code repository authentication.

[0091] S303. In response to the build request, create two build sub-processes; using the build sub-processes, concurrently process the Electron part of the target application in the Electron temporary directory and the Python part of the target application in the Python temporary directory, and generate build artifacts respectively.

[0092] For example, the computer device creates separate build subprocesses for the Electron and Python components. Each subprocess executes its build task in its corresponding temporary directory and generates its corresponding build artifacts.

[0093] In one implementation, the construction subprocess can be an independent process or thread, responsible for executing a specific part of the construction logic, thus avoiding mutual interference.

[0094] In one implementation, the Electron build artifacts may include front-end resources in the dist / directory or a packaged installer (such as .exe or .dmg).

[0095] In one implementation, the Python build artifact can be a standalone executable file generated by PyInstaller or a packaged .whl file.

[0096] In one implementation, the Electron component's build subprocess can be executed using `npm run build`.

[0097] In one implementation, the Python part of the build process can be built using pyinstaller.

[0098] In one implementation, computer devices can use subprocesses (such as Python's subprocess module) or containers (such as Docker) to execute build commands in isolation.

[0099] In one implementation, the computer device can be configured with different build environments for Electron and Python (such as Node.js versions and Python virtual environments).

[0100] In one implementation, computer devices can achieve concurrent scheduling of subprocesses through callbacks or Promise mechanisms.

[0101] S304. Extract the build artifacts from the two build sub-processes and write them to the output directory. Package the output directory to obtain the release package of the target application.

[0102] For example, a computer device can extract the build artifacts needed for packaging from the build artifacts generated by two build sub-processes. The computer device can then merge these artifacts and write them into a single output directory. The computer device can then package this directory to form the final release package of the target application.

[0103] In one implementation, the output directory is a folder that temporarily stores all build artifacts for final packaging.

[0104] In one implementation, the release package is a distributable file containing the complete application. Optionally, the release package can be a compressed file. Optionally, the release package can contain a startup script or configuration files. For example, the release package can be app-release.zip.

[0105] In one implementation, the build artifacts may include an Electron installation package and a Python executable.

[0106] In one implementation, the computer device can use file operation APIs (such as Python's shutil module) to copy the output directory.

[0107] In one implementation, the computer device can compress the output directory using system commands (such as zip -r) or programming libraries (such as archiver).

[0108] In one implementation, the computer device can also clean up the temporary directory to free up disk space after the release package is generated.

[0109] In one implementation, the computer device may also store the distribution package locally. Alternatively, the computer device may store the distribution package on a cloud platform.

[0110] In this embodiment, by fetching Electron and Python code in parallel based on build requests, building Electron and Python build artifacts in parallel, and then copying the build artifacts to the final output file for packaging, the efficient and automated building of Electron and Python hybrid applications and the rapid generation of release packages are achieved.

[0111] In one example, in step S303 above, a build subprocess is used to concurrently process the Electron portion of the target application in the Electron temporary directory and the Python portion of the target application in the Python temporary directory, and to generate build artifacts respectively, including:

[0112] S3031. After entering the Electron temporary directory or Python temporary directory, execute the corresponding installation command to install the corresponding environment and dependency libraries.

[0113] For example, after entering the Electron temporary directory or the Python temporary directory, the computer device first checks the dependency configuration files in the current directory (such as Electron's package.json or Python's requirements.txt). Then, the computer device can execute the corresponding installation instructions according to the file content to automatically install the runtime environment and dependent libraries required by the project.

[0114] In one implementation, the Electron temporary directory stores the Electron portion of the hybrid application. This portion is typically the front-end code. The Electron temporary directory may contain front-end resource files and dependency configurations.

[0115] In one implementation, the Python temporary directory stores the Python portion of the hybrid application. This portion is typically the backend code. This Electron temporary directory may contain virtual environments or dependency management files.

[0116] In one implementation, the dependency library is specifically a third-party module or library required for the project to run. For example, the dependency library could be electron-builder for Electron. Or, it could be numpy for Python.

[0117] In one implementation, Electron dependency installation can be achieved by executing the `npm install` command, which installs frontend dependencies based on `package.json`. Optionally, if the Electron dependency installation process requires a global tool (such as electron-packager), global installation can be pre-configured or invoked via `npx`.

[0118] In one implementation, Python dependencies can be installed by using `pip install -rrequirements.txt` to install backend dependencies. Alternatively, if an isolated environment is required, a virtual environment (such as `python -mvenv venv`) can be created and activated before installation.

[0119] In one implementation, the computer device can also automatically select the appropriate package management tool (such as pip or conda) under Windows, Linux, or macOS. Optionally, the computer device can also specify the dependency version through environment variables (such as PYTHON_VERSION).

[0120] S3032. Execute the corresponding build script based on the platform and environment of the Electron or Python temporary directory to generate the installation package or installation directory. The installation package or installation directory contains the build artifacts.

[0121] For example, a computer device can call a predefined build script (such as build.js for Electron or setup.py for Python) to perform compilation, packaging, and other operations, based on the operating system platform and build environment where the Electron or Python temporary directory is located, ultimately generating a build artifact. This build artifact may contain an installer (such as .exe or .dmg) or an installation directory (such as dist / ).

[0122] In one implementation, the build script can be a script file that automates the build task. Optionally, the build script may include logic for compilation, testing, packaging, etc.

[0123] In one implementation, the installation package encapsulates the application and its dependent executables (such as .msi for Windows or .pkg for macOS).

[0124] In one implementation, the installation directory may include an uncompressed folder structure. Alternatively, the installation directory may contain all build artifacts (such as Electron's resources directory or Python's bin directory).

[0125] In one implementation, the build artifacts can be the final files generated during the build process (such as executable programs, configuration files, or resource files).

[0126] In one implementation, the Electron build process can generate a cross-platform installer by calling electron-builder or electron-packager and based on the configuration in package.json.

[0127] Optionally, this Electron build process can support multi-platform packaging. For example, it can generate both Windows and macOS versions simultaneously.

[0128] Optionally, the computer device can be configured to digitally sign the installation package using a signing certificate. For example, the signing certificate could be Windows' CodeSign.

[0129] In one implementation, Python builds can package Python scripts into standalone executables using PyInstaller.

[0130] Optionally, this Python build process does not require an external Python environment.

[0131] In one implementation, the Python build process can use setuptools to generate installation packages in wheel or sdist format for pip to install.

[0132] In one implementation, the computer device can also customize the structure of the packaged files (such as merging data files into the data / directory).

[0133] In one implementation, on Linux, the computer device can use dpkg-buildpackage to generate a .deb package, or on macOS, productbuild can generate a .pkg package.

[0134] In one implementation, the computer device can dynamically select platform-related parameters in a script by setting conditional statements. For example, the condition could be `if os.name == 'nt'`.

[0135] In this example, by automating the execution of environment dependency installation and cross-platform adaptation build scripts in a temporary directory, we achieve efficient and consistent building of Electron and Python hybrid applications and the generation of standardized distributable artifacts.

[0136] In one example, in step S304 above, the build artifacts of the two build sub-processes are extracted and written to the output directory, including:

[0137] S3041. Write the executable file from the Python build artifacts to the output directory. The executable file includes dependent libraries.

[0138] For example, after completing the Python portion of the build, the computer device can locate the executable file generated in the build artifacts from a temporary directory. The computer device can then copy the executable file to a pre-created output directory, ensuring that the complete running program is included during subsequent packaging or distribution. This executable file already includes all dependent libraries, eliminating the need for additional Python installation.

[0139] In one implementation, the Python build artifact is the final file generated after compiling and packaging the Python code in the hybrid application, typically an executable program or a library file.

[0140] In one implementation, the executable file is created by converting a Python script into a directly executable binary file using tools such as PyInstaller or cx_Freeze. This executable file contains embedded dependency libraries.

[0141] In one implementation, the dependency library is a third-party module required by the Python program at runtime. For example, this dependency library could be numpy, requests, etc. The computer device can statically link this dependency library into the executable file during packaging.

[0142] In one implementation, the output directory is a unified folder that stores the final build results, which may be used later to generate an installation package or for direct distribution.

[0143] In one implementation, the computer device can use system commands (such as `cp` in Linux or `copy` in Windows) to move the executable file to the output directory. Alternatively, the computer device can implement cross-platform file operations using a programming language (such as `shutil.copy` in Python).

[0144] In one implementation, the computer device can use PyInstaller's `--onefile` mode to generate an executable file containing the dependent libraries, achieving static packaging. Alternatively, the computer device can use the `--onedir` mode, which will generate the dependent libraries in a separate folder. The computer device can then copy this separate folder containing the dependent libraries to the `lib / ` subdirectory of the output directory.

[0145] In one implementation, the computer device can check if the output directory exists before copying, and automatically create it if it does not exist.

[0146] In one implementation, the computer device can rename the file when a filename conflict is detected, in order to avoid information overwriting caused by the filename conflict.

[0147] S3042. Write the main program, language packs, dependency libraries, and application resources from the Electron build artifacts to the output directory.

[0148] For example, after completing the Electron portion of the build, the computer device collects the main program, language packs, dependency libraries, and application resources from the build artifacts in a temporary directory. The computer device can then organize these files according to a predefined structure and write them to the output directory.

[0149] In one implementation, the Electron build artifact may include multiple files and directories generated after compiling and packaging the Electron portion of the hybrid application. This Electron build artifact may contain front-end code, runtime environment, and resources.

[0150] In one implementation, the main program is the entry point executable for the Electron application. For example, this file could be a .exe file for Windows or a .app file for macOS. This main program is responsible for launching the Chromium rendering process and the Node.js main process.

[0151] In one implementation, a language pack is a localization file that provides multilingual support. For example, the language pack could be en-US.json or zh-CN.json. This language pack is typically stored in the locales / directory.

[0152] In one implementation, the dependency library is a Node.js module or native plugin required by the Electron application to run. For example, the dependency library could be ffmpeg.dll. This dependency library can be stored in resources / or a separate directory.

[0153] In one implementation, application resources are static files used by the front-end. These may include HTML, CSS, images, etc. These application resources are typically stored in the app / or resources / app / directory.

[0154] In one implementation, the computer device can use a build tool (such as electron-builder) to automatically copy the artifacts to the output directory according to a specified structure. Alternatively, the computer device can manually write a script (such as Python or Shell) to traverse the temporary directory and copy files by type.

[0155] In one implementation, for the Windows platform, the main program is an .exe file, and the dependent libraries may include .dll files; language packs are in .json or .pak format. For the macOS platform, the main program is an .app package, and the dependent libraries are .dylib files; resources must conform to macOS's sandboxing specifications. For the Linux platform, the main program is a binary file, and the dependent libraries are .so files; permission and path issues need to be addressed.

[0156] In one implementation, the computer device can centrally store the dependency libraries in the lib / or resources / subdirectories of the output directory to avoid conflicts with the main program path.

[0157] In one implementation, the computer device can store language packs in directories according to language codes (such as locales / en / , locales / zh / ), which facilitates dynamic loading.

[0158] In one implementation, the computer device can compress resources such as images (e.g., using the tinypng tool) to reduce the size of the output directory.

[0159] In one implementation, the computer device can delete temporarily generated intermediate files (such as uncompressed source files) and retain only the final product.

[0160] In this example, by automating the integration of Python and Electron build artifacts into the output directory, we achieve efficient collection and complete delivery of hybrid application build artifacts.

[0161] In one example, the process of copying files to the output directory also includes:

[0162] S3043. Write the launcher of the target application to the output directory.

[0163] For example, the computer device can also locate a launcher file from a predefined launcher list based on the launch requirements of the target application. The computer device can then copy this file to a specified location in the output directory.

[0164] In one implementation, the launcher is responsible for launching both Electron and Python components with a single click when the user runs the application.

[0165] In one implementation, the target application is a hybrid application consisting of an Electron frontend and a Python backend, which needs to be invoked uniformly through a launcher.

[0166] In one implementation, the launcher is a script or executable file used to uniformly invoke and start the Electron frontend and Python backend in the application. This launcher may include functions such as environment detection, dependency loading, and logging.

[0167] In one implementation, the computer device can determine the launcher that needs to be acquired and written to the output target based on the current environment. The launcher can determine the Windows, macOS, or Linux operating system it needs to match based on the environment.

[0168] In one implementation, Windows can use a .bat or .ps1 script and call the main program via the absolute path of python.exe or electron.exe to start the Electron frontend and Python backend.

[0169] In one implementation, macOS / Linux can use a .sh script, specifying the interpreter via #! / bin / bash and setting chmod +x execute permissions to start the Electron frontend and Python backend.

[0170] In one implementation, the computer device can be compiled into a standalone binary file using a language such as Go or Rust, avoiding the lack of a script interpreter in the user environment. For example, the startup logic can be embedded in launcher.exe (Windows) or launcher (macOS / Linux).

[0171] In one implementation, the computer device launcher can locate the main program and resources via relative paths such as . / resources / app / main.js, adapting to changes in the output directory structure.

[0172] In one implementation, the computer device can set environment variables such as APP_HOME in the script to dynamically resolve the application's root directory (e.g., export APP_HOME=$(dirname"$0")).

[0173] In one implementation, the computer device can perform different judgments by setting conditional branches. For example, the computer device can determine the platform in a script using `if os.name == 'nt'` (Python) or `uname -s` (Shell) and execute different commands accordingly.

[0174] In this example, by writing the launcher to the output directory, the target application achieves consistent startup and seamless operation across operating system environments.

[0175] In one example, the computer device can also achieve real-time monitoring of the progress and status of automatic packaging and deployment by sending broadcasts. This process may include:

[0176] S305. During the automated build process of the target application, broadcast messages are generated and sent based on the execution steps and results. These broadcast messages are used to instruct the front-end interface to modify and update the progress and status of the automated packaging and deployment of the target application.

[0177] For example, when a computer device executes an automated build process, it captures the execution status and key data of each build step in real time through a preset monitoring module. The execution status may include start, completion, failure, etc. The key data may include the current step name, time elapsed, number of steps remaining, etc.

[0178] Computer devices can encapsulate this information into broadcast messages using a standardized format. These messages are broadcast via predefined communication protocols. Upon receiving the broadcast, the web console (front-end) can update the display interface with the progress and status of the target application's automatic packaging and deployment, based on the broadcast content.

[0179] The computer equipment can determine the progress based on the execution steps, and it can also determine the status based on the execution results.

[0180] In one implementation, during the automated build process, computer devices can automatically execute tasks such as code compilation, dependency installation, packaging, and deployment through scripts or tools (such as Jenkins or GitHub Actions).

[0181] In one implementation, the execution step is a single operation step in the build process. For example, the execution step could be "download dependency libraries", "compile front-end code", or "generate installation package".

[0182] In one implementation, the execution result can be used to indicate the status of the current step. For example, for the step of downloading dependent libraries, it could correspond to download completed, download failed, etc.

[0183] In one implementation, the computer device broadcasts the execution step and the progress and status corresponding to the execution result, which makes it easier for multiple front-ends to obtain the information at the same time, thereby achieving more accurate and reliable updates.

[0184] Optionally, the broadcast message may include fields such as step ID, status type (in progress / success / failure), timestamp, and detailed description.

[0185] In one implementation, the front-end interface is an interactive interface set up in the web console. Users can view the build progress through this front-end interface. Optionally, the front-end interface can be a web page or an application window.

[0186] In one implementation, the computer device can insert a hook function into the build script (such as the scripts field of Makefile or package.json) so that the build script can generate a corresponding broadcast message when the hook function is executed.

[0187] For example, computer devices can use the logging module to record step status and send it to a message server via a socket.

[0188] In one implementation, the computer device can use a build tool plugin to trigger message generation in critical lifecycle events such as onBuildStart and onPackageComplete.

[0189] For example, Webpack's Compiler.hooks.done hook can capture compilation completion events and send messages.

[0190] In one implementation, the computer device can also monitor the start and exit of the build subprocess through system commands (such as ps or tasklist) or process management tools (such as PM2) to indirectly infer the step status.

[0191] In one implementation, the computer device can choose WebSocket to broadcast messages. This WebSocket is suitable for scenarios with high real-time requirements, establishing a long-lived connection between the server and the client, resulting in low message push latency.

[0192] Alternatively, the front-end uses the Socket.IO library, and the back-end handles the connection through the ws module (Node.js) or Spring WebSocket (Java).

[0193] In one implementation, a progress bar can be set in the front-end interface. The computer device can calculate the percentage based on the total number of steps in the message and the current completion number, and dynamically update the linear or circular progress bar.

[0194] In one implementation, status labels can be set in the front-end interface. The computer device can map the step status to different colors or icons (such as a green checkmark for success and a red cross for failure) and display a detailed description.

[0195] In one implementation, the computer device can also record the broadcast information as log information. Optionally, the computer device can append detailed logs from the message to the log area in chronological order, supporting scrolling viewing and keyword highlighting.

[0196] In this example, by capturing the status of automated build steps in real time and dynamically generating broadcast information, we achieve real-time synchronization between the front-end interface and the build process, as well as visualized monitoring of the packaging and deployment progress.

[0197] In one example, the computer device can also cancel the build of the hybrid application during the build process as needed after a build request has been issued. This process may include:

[0198] S3061. Based on the build request, generate a build task for the target application. The build task is used to perform automated builds of the target application.

[0199] For example, after receiving a build request, a computer device can parse the parameters in the request and combine them with a predefined template or configuration file to generate a build task. Based on this build task, the computer device can then automate the build of the target application.

[0200] In one implementation, the computer device can generate the build task between steps S301 and S302. Furthermore, the computer device can complete steps S302 to S304 based on the build task.

[0201] In one implementation, the build request is an information sent to the backend based on a build command triggered by the user on the frontend.

[0202] In one implementation, a build task is a logical unit describing specific build behavior. Typically, each build task has a unique build ID for unique identification. Optionally, the build task is used to indicate all the steps the hybrid application needs to perform.

[0203] In one implementation, the computer device can parse the build request to obtain its parameters. Then, based on these parameters, the computer device can generate a build context. Subsequently, based on this build context, the computer device can generate a build task.

[0204] Optionally, the build context includes parameters that can be used for the build task, extracted based on the parameters in the build request.

[0205] S3062, Cancellation controller for generating build tasks. The cancellation controller is used to monitor and obtain cancellation signals for user-triggered build tasks.

[0206] For example, after creating a build task, a computer device can initialize a Cancel Controller corresponding to that build task. This Cancel Controller is bound to the build task's build ID. This Cancel Controller can correspond to a monitoring region. The computer device can monitor this monitoring region through the Cancel Controller to determine whether the user intends to cancel the build task.

[0207] In one implementation, the monitoring area can be an interactive area set on the front-end interface. Optionally, the interactive area can include buttons, selection boxes, etc.

[0208] In one implementation, when a user performs a specified operation in the interactive area, the computer device can obtain the user's intent to complete the task. Optionally, the specified operation could be clicking a button, writing an "×" on the screen, etc.

[0209] In one implementation, the cancellation controller can be used to monitor whether a specified operation occurs in the interaction area. The cancellation controller is a component that manages the task cancellation lifecycle.

[0210] In one implementation, the cancellation signal is a signal triggered when the user performs a specified operation in the monitored area.

[0211] In one implementation, the cancellation controller can also trigger a cancellation signal when the execution status of the construction task meets the cancellation rules based on the computer device's preset cancellation rules.

[0212] S3063. Obtain the user-triggered build task cancellation signal through the cancellation controller, and generate a cancellation instruction based on the cancellation signal.

[0213] For example, a computer device can continuously listen for cancellation signals via a cancellation controller. Once a cancellation signal is detected, the cancellation controller can immediately generate a cancellation instruction. This cancellation instruction may include a build task ID.

[0214] In one implementation, the cancellation instruction may also include a cancellation reason. For example, the cancellation reason could be user-initiated cancellation, timeout cancellation, etc.

[0215] In one implementation, the cancellation instruction may also include a priority. For example, the priority could be immediate termination, graceful exit, etc.

[0216] Optionally, "Terminate immediately" can be used to instruct the computer device to directly terminate the build task and exit.

[0217] Optionally, graceful exit can be used to instruct a computer device to exit after completing the current step, thus avoiding data corruption.

[0218] In one implementation, the cancellation instruction includes a structured data object to specify the exact method and context information for terminating the build task.

[0219] S3064. In response to the cancel command, cancel the build task.

[0220] For example, upon receiving a cancellation instruction, a computer device may terminate the currently executing operation based on the current state of the task.

[0221] In one implementation, if a build task is in a waiting queue, it is removed directly.

[0222] In one implementation, if a build task is in progress, the computer device terminates the process by calling the process's termination interface. For example, the process termination interface could be `process.kill()`. Alternatively, the computer device could instruct the container platform (such as Kubernetes) to destroy the Pod.

[0223] In one implementation, the computer device can also clean up temporary files, release resources, and update the task status to "cancelled" after the build task is terminated, finally informing the front end of the cancellation result through an event notification mechanism. Optionally, this notification method can be a callback function, message queue, broadcast, etc.

[0224] In this example, by generating a cancellation control mechanism for each build task, the build process can be flexibly cancelled, thereby improving the control flexibility of build tasks.

[0225] In one example, the computer device performs a cleanup operation after the build is complete to ensure available memory on the computer device. This build completion can be due to a successful build, a build exception, or a build cancellation. The process may include:

[0226] S307. When the cleanup conditions are met, perform the cleanup operation.

[0227] The cleanup condition is any one of the following: The target application builds successfully. An exception occurs during the build process of the target application. A cancellation command is triggered during the execution of the target application's build task.

[0228] For example, the computer device continuously monitors the build status during the build process of the target application. When it detects that the build status meets preset cleanup conditions, the computer device automatically triggers a cleanup operation.

[0229] In one implementation, the build status may include build success, build exception, build cancellation, file being pulled, file being pulled successfully, file being packaged, file being packaged successfully, etc.

[0230] In one implementation, the cleanup conditions can be the rules for triggering the cleanup operation. Cleanup conditions can include various build states such as successful build, build exception, and build cancellation.

[0231] In one implementation, the cleanup operation is used to perform actions such as deletion, release, or reset of temporary data or resources generated during the build process to ensure a clean environment. Optionally, the cleanup operation typically includes deleting temporary files, releasing resources (such as database connections and memory caches), updating the task status to "cleaned up," and recording a cleanup log.

[0232] In one implementation, temporary files are typically intermediate products generated during the build process and usually do not need to be retained. Examples include temporary directories for Electron and Python.

[0233] In one implementation, resource release can be the return of system resources occupied by the build task. These system resources may include file handles, network connections, GPU memory, etc. This resource release can prevent memory leaks.

[0234] In one implementation, the cleanup condition can be that the target application was successfully built.

[0235] Optionally, the computer device can evaluate the final output release package after the build task has completed all build steps. If the release package meets expectations, the computer device can determine that the build was successful and immediately initiate cleanup.

[0236] Optionally, the computer device may also generate corresponding broadcast information to announce the build progress when the build is determined to be successful. Additionally, the computer device may also generate corresponding log information to record the build success.

[0237] Optionally, the cleanup operation at this time can prioritize deleting temporary folders under the build directory (such as / tmp / build-123), then shut down temporarily started service processes (such as the test web server), and finally update the task status in the database to "success + cleanup".

[0238] In one implementation, the cleanup condition can be that an exception occurs in the target application during the build process.

[0239] Optionally, when a build task is interrupted due to code errors, missing dependencies, or environmental issues, the computer device can capture the exception information, determine it as a build exception, and perform cleanup.

[0240] Optionally, the cleanup operation at this time can prioritize retaining the exception log (for troubleshooting), then delete the incomplete output files (to avoid misleading residue), and finally update the task status to "failed + cleaned up".

[0241] Alternatively, the computer device can use process management tools (such as systemd or PM2) to monitor the build process and automatically trigger a cleanup script if the process exits abnormally (such as SIGSEGV).

[0242] Alternatively, computer devices can also detect error keywords (such as ERROR, Failed) through log analysis tools (such as ELK Stack) and trigger cleanup tasks (such as deleting temporary files via a Lambda function call to AWS S3).

[0243] In one implementation, the cleanup condition can be that a cancellation instruction is triggered during the execution of the build task.

[0244] Optionally, when a user actively cancels a build task through the front-end interface or API, the computer device's cancellation controller transmits a cancellation signal to the build engine, which immediately terminates the current step (such as stopping compilation or closing download threads) and performs cleanup.

[0245] Optionally, the cleanup logic at this time can be to ensure resource release (such as closing database transactions), delete temporary files, and update the task status to "cancelled + cleaned up".

[0246] In one implementation, for containerized environments, such as Kubernetes, a computer device can trigger container exit by deleting a Pod (kubectl delete pod), and the preStop hook inside the container executes cleanup commands.

[0247] In one implementation, for the cancellation of distributed tasks, the computer device can send a "cancel" message to the task queue in a message queue-driven build system (such as RabbitMQ). Upon receiving the message, the consumer performs cleanup and returns an acknowledgment.

[0248] In this example, the cleanup logic is triggered by judging the build status, thereby automatically releasing computer resources based on the build status and improving the efficiency of cleaning up temporary data.

[0249] In one example, step S307 above, performing a cleanup operation, includes:

[0250] S3071. Delete the Electron temporary directory and the Python temporary directory.

[0251] For example, a computer device can automatically scan the system's Electron temporary directory and Python temporary directory during a cleanup operation. The computer device can then delete files and subdirectories within these directories.

[0252] In one implementation, the Electron temporary directory can be the code for the Electron portion of the hybrid application, as well as intermediate files generated during the build process. Optionally, its path can be / tmp / electron-build-xxx or a hidden folder under the user's directory (such as ~ / .cache / electron).

[0253] In one implementation, the Electron temporary directory typically contains uncompressed resources, cached files, or intermediate artifacts generated during the packaging process.

[0254] In one implementation, the Python temporary directory can contain the Python code from the hybrid application, as well as intermediate files generated during the build process. Optionally, this Python temporary directory can store the Python interpreter or toolchain. For example, it could store pip, setuptools, etc. Optionally, the path to this Python temporary directory might be / tmp / pip-install-xxx or __pycache__ in the project directory.

[0255] In one implementation, the Python temporary directory may contain virtual environment remnants, compiled .pyc files, or downloaded dependency packages.

[0256] In one implementation, the computer device can directly specify the known paths to the Electron temporary directory and the Python temporary directory, and call system commands (such as rm -rf in Linux or rmdir / s / q in Windows) to delete them.

[0257] In another implementation, the computer device can locate the Electron temporary directory and the Python temporary directory through environment variables (such as TEMP or TMPDIR), and combine them with wildcards to match the target folder, thereby enabling the deletion of the Electron temporary directory and the Python temporary directory.

[0258] In another implementation, computer devices can use the built-in cleanup plugins of build tools (such as Webpack and ElectronBuilder) to automatically handle temporary files. For example, computer devices can use ElectronBuilder's asarUnpack configuration to specify the temporary file patterns to be cleaned up.

[0259] S3072. Close the file handle that is open.

[0260] For example, when a build task terminates or is cleaned up, the computer device scans all open file handles in the current process. The computer device can identify and close handles associated with the build task, such as handles to log files, configuration files, and lock files.

[0261] In one implementation, the computer device must ensure that the file is not occupied by other processes when closing the file handle, thereby avoiding permission errors or data corruption.

[0262] In one implementation, if the handle cannot be closed directly, the computer device may attempt to force release or log a warning message.

[0263] In one implementation, a file handle is a unique identifier assigned to a process by the operating system for accessing a file. The process creates a handle when opening a file and releases it when closing the file.

[0264] In one implementation, in Linux, the computer device uses the lsof command to list the files opened by a process, filters the target file, and then calls kill -9 to terminate the child process holding the handle.

[0265] In one implementation, the computer device can also explicitly close the handle using the file operation API built into the programming language. For example, this API could be Python's file.close() or Java's FileChannel.close().

[0266] In one implementation, the computer device can use a cross-platform library (such as psutil for Python) to obtain a list of files opened by a process and close file handles in batches.

[0267] S3073. Remove the build task from the active build list. The active build list includes all build tasks. It records the execution progress and status of build tasks.

[0268] For example, a computer device can remove a build task from the list of active builds when the build task is completed, fails, or is canceled.

[0269] In one implementation, the active build list is a collection that records all build tasks that are currently executing or pending. This active build list may contain information such as build ID, status (running / failed / successful), and progress percentage. The active build list is typically stored as key-value pairs (such as task ID and status) or as a queue.

[0270] In one implementation, the build ID is a unique identifier for the build task, typically generated by the scheduler (such as a UUID or timestamp).

[0271] In one implementation, the removal operation must ensure data consistency (e.g., using locking mechanisms in a multi-threaded environment). After removal, the list length is reduced, and associated resources (such as memory and database connections) are released.

[0272] In one implementation, if the list of active builds is stored in memory (such as a Python list or Java's ConcurrentHashMap), the computer device can directly call the remove(taskId) or delete(key) method to delete the build task.

[0273] In one implementation, if the list of active builds is stored in a database (such as MySQL or Redis), the computer device can execute an SQL delete statement or call the Redis DEL command to delete the build task.

[0274] In this example, by automating the cleanup of Electron and Python temporary directories, releasing file handles, and dynamically updating the build task status, the goal of efficient recycling of build environment resources and precise management of task status is achieved.

[0275] Figure 4 A flowchart illustrating an automated application building method provided in this application embodiment is shown below. Figures 1 to 3 Based on the illustrated embodiments, as Figure 4 As shown, taking computer devices as the execution subject, for Electron+Python hybrid applications, the automated build process in a single operation includes the following steps:

[0276] S401, Request reception and verification.

[0277] For example, the computer device can access the build request generation interface triggered when a user selects the "Integrated Build" type via a web console. On this build request generation interface, the computer device can access the build parameters entered by the user. Alternatively, on the same interface, the computer device can access the default values ​​preset for the build parameters. The computer device can generate a build request in response to the user clicking the "Start Build" button. The computer device can then send this build request to a preset backend interface. The backend interface can access and validate the build request.

[0278] In one implementation, the build parameters may include Electron branch parameters, Python branch parameters, target platform, version number, and whether to upload to OSS.

[0279] Optionally, the Electron branch parameter can be denoted as electronRef. The default value for this Electron branch parameter is test. When the default value test is selected, it can be confirmed that an Electron branch exists.

[0280] Optionally, the Python branch parameter can be denoted as pythonRef. The value of this Python branch parameter can be fixed to main. This fixed value, main, can be used to indicate the existence of a Python branch.

[0281] Optionally, the target platform can be denoted as "platform". For example, the target platform can be win32, darwin, linux, etc.

[0282] Alternatively, the version number can be written as "version". For example, the version number could be "2.3.1".

[0283] Optionally, the option to upload to OSS can be denoted as uploadToOSS. The value of this option can be either true or false.

[0284] In one implementation, the build request can be a POST request.

[0285] In one implementation, the backend interface can be / api / build / combined.

[0286] In one implementation, the backend interface can validate the validity of the parameters in the build request. For example, it can verify whether an API Key is included. Alternatively, it can verify whether the API Key conforms to preset rules. Another example is verifying whether all required fields have been filled in.

[0287] S402, Create a build context.

[0288] For example, the computer device can also generate a build context object based on parameters in the build request. This build context object can include multiple data items. After generating the build context object, the computer device can add the build task to the active builds map.

[0289] For example, the build context object may include build ID, status, start time, user configuration, abort controller, etc.

[0290] In one implementation, the computer device can generate a unique build ID through a build manager. This build ID serves as a unique identifier for the automated build operation of the application.

[0291] Alternatively, the build ID can use a universally unique identifier (UUID).

[0292] In one implementation, the build type can include Electron build, Python build, integrated build, etc. For hybrid applications, the build type can be an integrated build.

[0293] In one implementation, the status can include pending, waiting, or completed. If the current build request needs to wait for a pending build request to complete its processing before execution, its status can be pending. For example, if the current concurrency limit has been reached, the current build request's status can be pending.

[0294] In one implementation, the start time is the timestamp corresponding to the build request.

[0295] In one implementation, the user configuration (config) may include parameters such as the platform and version number set by the user.

[0296] In one implementation, the abort controller is used to abort the build process.

[0297] In one implementation, the computer device can check the current number of concurrent builds. If the current number of concurrent builds exceeds the limit, they are queued and wait.

[0298] Optionally, the upper limit for the number of concurrent builds can be determined based on the computing power of the computer device. For example, it could be 3.

[0299] S403, concurrently fetch source code.

[0300] For example, the computer device can create two separate temporary directories: an Electron temporary directory and a Python temporary directory. The computer device can concurrently execute code fetches using the `Promise.all` method. The computer device can download archive files from the code repository using the GitLab API. The downloaded archive files are in .tar.gz or .zip format. The computer device can then unzip the archive files to the target temporary directory and delete them.

[0301] In one implementation, the temporary Electron directory can be denoted as temp / build_electron_{uuid}_{timestamp}. The temporary Python directory can be denoted as temp / build_python_{uuid}_{timestamp}.

[0302] S404, Concurrently building the Electron and Python portions of an application.

[0303] For example, a computer device can launch two build tasks simultaneously and create two build sub-processes for each build task. These build sub-processes include an Electron build sub-process (electronBuilder.js) and a Python build sub-process (pythonBuilder.js).

[0304] In one implementation, the computer device can concurrently execute two build tasks using Promise.all. This maximizes the utilization of system resources and reduces the overall build time.

[0305] In one implementation, the execution process of the two construction sub-processes can be as follows: Figure 5 As shown.

[0306] In one implementation, within the Electron build subprocess (electronBuilder.js), the computer device can perform the following steps:

[0307] S4041. After entering the Electron temporary directory, execute `npm install` to install dependencies. Optionally, this dependency can be a Node.js package manager.

[0308] S4042. Execute the corresponding build script according to the platform and environment.

[0309] In a Windows production environment, the build script can be `npm run build:win:prod`. In a Windows testing environment, the build script can be `npm run build:win:test`. In a macOS production environment, the build script can be `npm run build:mac:prod`. In a macOS testing environment, the build script can be `npm run build:mac:test`.

[0310] S4043. Execute electron-builder to generate an installation package or portable version to the dist / directory.

[0311] S4044. After extracting the build artifacts, return the build result path. In Windows, the computer can extract the build artifacts by searching for .exe files or the win-unpacked directory. In macOS, the computer can extract the build artifacts by searching for .dmg or .app files.

[0312] In one implementation, within the Python build subprocess (pythonBuilder.js), the computer device can perform the following steps:

[0313] S4045. After entering the Python temporary directory, detect and activate the Python virtual environment.

[0314] S4046. Execute pip install -r requirements.txt to install dependencies.

[0315] S4047. Execute the PyInstaller packaging command. Optionally, it can be packaged into a single .exe file. Optionally, the console window can be hidden during the packaging process.

[0316] S4048. After PyInstaller generates the executable file to the dist / directory, it returns the path to the build artifact. Optionally, the build artifact is the .exe file.

[0317] S405, Combine and construct the product.

[0318] For example, the computer device can first create the final output directory. Then, the computer device can copy the Electron build artifacts to that output directory. And, the computer device can copy the Python build artifacts to that output directory. Afterwards, the computer device can copy the launcher files.

[0319] For example, the final output directory could be output / MyApp-v2.3.1-{timestamp} /

[0320] In one implementation, if it's a win-unpacked directory, the computer device can copy the entire directory to the output directory. If it's an .exe installer, the computer device can copy the installer to the output directory.

[0321] In one implementation, the computer device can maintain the original directory structure of the Electron build artifacts when copying them to the output directory.

[0322] In one implementation, the computer device can copy the .exe file generated by Python to the root directory of the output directory. The computer device can standardize the filename format by renaming it. For example, the format can be standardized to python-service.exe.

[0323] In one implementation, the computer device can copy a one-click launcher from assets / APP.exe to the output directory. This one-click launcher is responsible for starting the Electron and Python processes sequentially.

[0324] In one implementation, the product merging structure can be as follows: Figure 6 As shown.

[0325] S406. Create a release package.

[0326] For example, a computer device can use the Archiver library to create a ZIP archive. This process may include setting compression parameters, adding an entire output directory to the archive, generating the archive file, and recording compression information.

[0327] The compression information may include the original size, the compressed size, and the compression ratio.

[0328] S407, Upload to cloud storage.

[0329] For example, if the user selects the "Upload to OSS" option parameter when generating the build request (i.e., the parameter value is TRUE), the computer device can upload the release package generated in step S406 to the cloud platform.

[0330] The computer device can extract the version number from the filename. The computer device can generate the OSS storage path. The computer device can upload data using the OSS SDK of the cloud platform. The computer device can generate a public access URL. The computer device can record the upload result, which can be either successful or failed.

[0331] In one implementation, even if the upload fails during the cloud platform's upload process, it does not affect the storage and use of the local build artifacts.

[0332] S408. Clean up temporary files.

[0333] For example, the computer device can delete the Electron temporary directory and all its contents. Similarly, the computer device can delete the Python temporary directory and all its contents. Furthermore, the computer device can retain the final build artifact. Optionally, this build artifact can be a compressed file. Finally, the computer device can record a cleanup log.

[0334] S409. Notification construction complete.

[0335] For example, the computer device can update the build status to success or failure. The computer device can broadcast the build result via WebSocket. All connected web consoles simultaneously receive the broadcast notification and update their interfaces.

[0336] In one implementation, the broadcast content may include information such as message type, build ID, status, result details, artifact path, OSS access link, file size, and build time.

[0337] Optionally, the message type can be a build result notification.

[0338] Optionally, the ID can be a unique identifier.

[0339] Optionally, the status can be success / failure.

[0340] For example, the artifact path could be artifacts / MyApp-Setup-v2.3.1.zip.

[0341] Alternatively, the OSS access link can be a public download address.

[0342] For example, the file size can be 120MB.

[0343] For example, the build time can be about 3 minutes.

[0344] In this embodiment, through fully automated processes such as request reception and verification, context creation, concurrent fetching and building, artifact merging and packaging, upload and storage, and cleanup notifications, efficient integration, building, and unified release management of Electron+Python hybrid applications are achieved.

[0345] Figure 7 This is a flowchart illustrating a log push method provided in an embodiment of this application. Figure 8 A flowchart for establishing bidirectional real-time communication using WebSocket. Figures 1 to 6 Based on the illustrated embodiments, as Figure 7 and Figure 8 As shown, with computer equipment as the execution subject, the visualization monitoring process is mainly implemented through logs. Log execution can mainly include the following steps:

[0346] S701, Log Push.

[0347] For example, the computer device can first classify the logs. In this application, logs can be divided into four categories: general information, success messages, warning messages, and exception messages. The computer device can encapsulate the log sending function and integrate it into the build process. Furthermore, the computer device can generate and send corresponding logs based on the steps and results of the build execution during the build process.

[0348] In one implementation, "info" refers to general information. This general information can correspond to processes such as dependency installation and file copying.

[0349] In one implementation, "success" represents a successful message. This success message can be generated after the build is complete or the upload is successful.

[0350] In one implementation, "warning" refers to a warning message. This warning message can be logged in scenarios such as skipping certain files or providing performance optimization suggestions.

[0351] In one implementation, "error" refers to exception information. This error message can be generated in cases of build failure, network errors, etc.

[0352] S702, progress status push.

[0353] For example, the computer device can first define the progress state. Then, the computer device can push the state when the state changes.

[0354] In one implementation, the status can include pending, running, success, failed, canceled, etc.

[0355] S703, Send a progress report.

[0356] For example, the computer device can send a progress report when each stage is completed.

[0357] In one implementation, the progress report may include the following stages and progress: Code pull complete: 20%. Electron build complete: 50%. Python build complete: 70%. Artifact merging complete: 85%. Upload complete: 100%.

[0358] S704, Error Handling and Reconnection.

[0359] For example, the computer device can automatically reconnect via a client after being disconnected. Optionally, this client is a web console.

[0360] In one implementation, the computer device can detect and establish a connection signal through a heartbeat keep-alive mechanism.

[0361] In one implementation, the server can send a ping message every 30 seconds. The client can respond with a pong message upon receiving a ping, thus confirming a successful connection.

[0362] In one implementation, if the computer device does not receive a pong message for 60 seconds, it will actively disconnect.

[0363] In this embodiment, transparent monitoring of the construction process and stable and reliable real-time communication are achieved through multi-category log classification and push, real-time progress status updates, generation of phased progress reports, and automatic reconnection and heartbeat keep-alive mechanisms.

[0364] Figure 9 A flowchart of a concurrency control method provided in an embodiment of this application is shown. Figures 1 to 8 Based on the illustrated embodiments, as Figure 9 As shown, taking a computer device as the execution subject, to prevent too many build tasks from running simultaneously and exhausting system resources, the computer device implements a semaphore-based concurrency control mechanism. This process includes the following steps:

[0365] Computer devices can use concurrency control to ensure that the number of build tasks running simultaneously does not exceed a limit. For example, this limit could be three. Furthermore, computer devices can use queue management to write build tasks exceeding the parallel limit into a waiting queue, awaiting execution. Based on this waiting queue, the computer device can automatically schedule the next task in the queue after completing the previous one. The execution order in this queue can be planned according to the first-in, first-out (FIFO) principle. This limitation on the number of parallel tasks prevents system overload and ensures that each build task has sufficient resources. Moreover, the waiting queue mechanism ensures that all requests are eventually processed.

[0366] In this embodiment, by limiting the maximum number of build tasks that can run simultaneously through concurrency control and combining it with queue management and automatic scheduling mechanisms, the system achieves the effect of reasonable allocation of resources, avoids overload, and ensures that all build requests are processed in an orderly manner according to the first-in-first-out principle.

[0367] Figure 10 A flowchart illustrating a method for canceling a construction task, as provided in an embodiment of this application. Figures 1 to 9 Based on the illustrated embodiments, as Figure 10 As shown, taking computer devices as the execution subject, this application can also implement a graceful cancellation mechanism using the AbortController API to support users in aborting long-running build tasks. The execution flow of this cancellation mechanism can include:

[0368] When implementing build task cancellation functionality, a separate cancellation controller needs to be created for each build task. This cancellation controller can accurately deliver cancellation signals to time-consuming asynchronous operations such as code fetching and file downloading. These asynchronous operations periodically check for cancellation signals during execution. Once a cancellation signal is detected, the asynchronous operation can immediately stop its current step and throw a cancellation exception.

[0369] For users, they can click the "Cancel Build" button on the front-end interface to trigger a cancellation request. The front-end can then send this cancellation request to the back-end. The cancellation request can include the build ID. The back-end can then use this build ID to find the corresponding task in the active build list. If the task is found, the back-end can trigger a cancellation signal and log "User has canceled build". Subsequently, all ongoing operations will enter a cleanup process upon receiving the signal.

[0370] In one example, the resource cleanup process can be as follows: Figure 11 As shown, it includes the following steps:

[0371] For example, the computer device can execute a unified cleanup mechanism when the build result is successful, failed, or canceled. First, the computer device cleans up temporary files, including deleting any dependency files that may exist in the Electron temporary directory, as well as virtual environments and source code in the Python temporary directory. Second, the computer device releases system resources, closing all open file handles and releasing resources such as compressed streams. Simultaneously, the computer device performs state management, removing completed or interrupted tasks from the active build map to make room for subsequent pending tasks. Finally, the computer device records a cleanup completion log for problem tracking and auditing.

[0372] In one example, the computer device also supports a variant of Docker containerized builds. By creating a Docker image containing Node.js, Python, and PyInstaller, a temporary container is started and the source code is mounted and executed during each build. After the build is complete, the artifacts are copied to the host machine and the container is destroyed, thereby providing a completely isolated build environment and effectively avoiding environmental pollution problems.

[0373] In another example, for large-scale teams, computing equipment can also be scaled up as a distributed build cluster. By deploying multiple build workers and having a central scheduler dynamically allocate tasks based on Redis or message queues such as RabbitMQ, load balancing and high concurrency support can be achieved, with a single node failure not affecting the overall service. This setup can support higher concurrent builds, achieve load balancing, and improve overall throughput. Furthermore, in this process, a single node failure does not affect the overall service.

[0374] In another example, for scenarios with frequent builds, an incremental build optimization strategy can be adopted. The computing device aims to maintain a build cache for the project, allowing it to rebuild only the changed parts after code changes are detected. The computing device can reuse the dependency cache from the last build, skipping `npm install` or `pip install`, thereby significantly reducing build time from 15 minutes to 3-5 minutes, significantly reducing network bandwidth consumption and improving development iteration efficiency.

[0375] In this embodiment, precise interruption is achieved by creating an independent cancellation controller for the build task. Combined with a unified cleanup mechanism, Docker containerized isolation, distributed cluster expansion, and incremental build optimization strategies, the build process achieves controllability, efficient resource utilization, high concurrency support, and rapid iteration.

[0376] Figure 12 A structural diagram of an automated application building apparatus provided in this application embodiment is shown below. Figure 12As shown, the automated build device 1200 for this application includes:

[0377] Module 1201 is used to obtain the build request of the target application, which is used to automatically build the target application; the target application is a hybrid application built with Electron and Python.

[0378] Parallel module 1202 is used to create an Electron temporary directory and a Python temporary directory in response to a build request; concurrently pull the Electron part and Python part of the target application into the Electron temporary directory and the Python temporary directory respectively; in response to a build request, create two build sub-processes; use the build sub-processes to concurrently process the Electron part of the target application in the Electron temporary directory and the Python part of the target application in the Python temporary directory, and generate build artifacts respectively.

[0379] The release module 1203 is used to extract the build artifacts of the two build sub-processes and write the build artifacts to the output directory; the output directory is packaged to obtain the release package of the target application.

[0380] In one example, parallel module 1202 is used for:

[0381] After entering the Electron temporary directory or Python temporary directory, execute the corresponding installation command to install the corresponding environment and dependency libraries;

[0382] The corresponding build script is executed based on the platform and environment of the Electron temporary directory or Python temporary directory to generate the installation package or installation directory; the installation package or installation directory includes the build artifacts.

[0383] In one example, the publishing module 1203 is used for:

[0384] Write the executable file from the Python build artifacts to the output directory; the executable file includes dependent libraries;

[0385] Write the main program, language packs, dependency libraries, and application resources from the Electron build artifacts to the output directory.

[0386] In one example, the publishing module 1203 is used for:

[0387] Write the launcher of the target application to the output directory.

[0388] In one example, the publishing module 1203 is used for:

[0389] During the automated build process of the target application, broadcast messages are generated and sent based on the execution steps and results. These broadcast messages are used to instruct the front-end interface to modify and update the progress and status of the automated packaging and deployment of the target application.

[0390] In one example, the application's automated build device 1200 also includes:

[0391] Cancellation module 1204 is used to generate a build task for the target application based on the build request; the build task is used to perform automated build of the target application; a cancellation controller for generating the build task is used to monitor and obtain cancellation signals of the build task triggered by the user; the cancellation controller obtains the cancellation signal of the build task triggered by the user and generates a cancellation instruction based on the cancellation signal; in response to the cancellation instruction, the build task is cancelled.

[0392] In one example, the application's automated build device 1200 also includes:

[0393] The cleaning module 1205 is used to perform cleaning operations when cleaning conditions are met;

[0394] The cleanup conditions include any one of the following:

[0395] The target application was built successfully;

[0396] The target application encountered an exception during the build process;

[0397] The build task of the target application is canceled during execution.

[0398] In one example, the cleanup module 1205 is used for:

[0399] Delete the Electron temporary directory and the Python temporary directory;

[0400] Close any open file handles;

[0401] Remove the build task from the active build list; the active build list includes all build tasks and is used to record the execution progress and status of build tasks.

[0402] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0403] In this embodiment, the automated application building device is presented in the form of a functional unit. Here, a unit refers to an application-specific integrated circuit (ASIC), a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0404] Figure 13 A structural diagram of a computer device provided in an embodiment of this application, such as... Figure 13 As shown, the computer device 1300 includes one or more processors 1301, memory 1302, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 13 Take the 1301 processor as an example.

[0405] Processor 1301 may be a central processing unit, a network processor, or a combination thereof. Processor 1301 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0406] The memory 1302 stores instructions executable by at least one processor 1301 to cause the at least one processor 1301 to perform the method shown in the above embodiments.

[0407] The memory 1302 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 1302 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 1302 may optionally include memory remotely located relative to the processor 1301, and these remote memories can be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0408] The memory 1302 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 1302 may also include a combination of the above types of memory.

[0409] The computer device also includes a communication interface 1303 for communicating with other devices or communication networks.

[0410] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the methods shown in the above embodiments are implemented.

[0411] This application provides a computer program product including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method of any embodiment of this application.

[0412] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

[0413] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for automatically building an application, characterized in that, The method includes: Obtain the build request for the target application, which is used to automatically build the target application; the target application is a hybrid application built with Electron and Python. In response to the build request, an Electron temporary directory and a Python temporary directory are created; the Electron and Python parts of the target application are concurrently pulled into the Electron temporary directory and the Python temporary directory, respectively; In response to the build request, two build sub-processes are created; using the build sub-processes, the Electron part of the target application in the Electron temporary directory and the Python part of the target application in the Python temporary directory are processed concurrently, and build artifacts are generated respectively. Extract the build artifacts from the two build sub-processes and write them to the output directory; package the output directory to obtain the release package of the target application.

2. The method according to claim 1, characterized in that, Using the aforementioned build sub-process, the Electron portion of the target application in the Electron temporary directory and the Python portion of the target application in the Python temporary directory are processed concurrently, and build artifacts are generated respectively, including: After entering the Electron temporary directory or Python temporary directory, execute the corresponding installation command to install the corresponding environment and dependency libraries; The corresponding build script is executed according to the operating system platform and build environment where the Electron temporary directory or Python temporary directory is located, generating an installation package or installation directory; the installation package or installation directory includes build artifacts.

3. The method according to claim 1, characterized in that, Extract the build artifacts from the two build sub-processes and write the build artifacts to the output directory, including: Write the executable file from the Python build artifacts to the output directory; the executable file includes dependent libraries; Write the main program, language packs, dependency libraries, and application resources from the Electron build artifacts to the output directory.

4. The method according to claim 3, characterized in that, The method further includes: Write the launcher of the target application to the output directory.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: During the automated build process of the target application, broadcast information is generated and sent based on the execution steps and results; the broadcast information is used to instruct the front-end interface to modify and update the progress and status of the automated packaging and deployment of the target application.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: Based on the build request, a build task for the target application is generated; the build task is used to automatically build the target application. A cancellation controller for the build task is generated; the cancellation controller is used to monitor and acquire cancellation signals of the build task triggered by the user. The cancellation controller obtains the user-triggered build task cancellation signal and generates a cancellation instruction based on the cancellation signal. In response to the cancellation command, the build task is cancelled.

7. The method according to any one of claims 1-4, characterized in that, The method further includes: Perform the cleanup operation when the cleanup conditions are met; The cleaning condition is any one of the following: The target application was successfully built. The target application encountered an error during the build process; The cancellation instruction is triggered during the execution of the target application's build task.

8. The method according to claim 7, characterized in that, Perform cleanup operations, including: Delete the Electron temporary directory and the Python temporary directory; Close any open file handles; Remove the build task from the active build list; wherein the active build list includes all build tasks; the active build list is used to record the execution progress and status of the build tasks.

9. An automated application building apparatus, characterized in that, The device includes: The acquisition module is used to acquire the build request of the target application, which is used to automatically build the target application; the target application is a hybrid application built with Electron and Python. A parallel module is configured to, in response to the build request, create an Electron temporary directory and a Python temporary directory; concurrently pull the Electron and Python parts of the target application into the Electron temporary directory and the Python temporary directory, respectively; in response to the build request, create two build sub-processes; and use the build sub-processes to concurrently process the Electron part of the target application in the Electron temporary directory and the Python part of the target application in the Python temporary directory, and generate build artifacts respectively. The publishing module is used to extract the build artifacts from the two build sub-processes and write the build artifacts into the output directory; and to package the output directory to obtain the publishing package of the target application.

10. A computer device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the method of any one of claims 1 to 8.

Images