Front-end project packaging method, device, electronic device and storage medium

Abstract

The present disclosure provides a front-end project packaging method, device, electronic device and storage medium, including connecting to a code repository, obtaining a first file, a second file and a third file; the first file is used to provide project description and dependency configuration information, the second file is used to associate information of the first file, and the third file is used to provide project initial code; generating a container based on a container orchestration engine, and creating a target image in the container; copying the first file and the second file and storing them in the target image; based on the first file, adding a first resource file in the target image, the first resource file is used to provide project dependencies and conversion statements; converting the project initial code in the third file into target code in the target image; and pushing the target image with the target code to an image repository.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a front-end project packaging method, device, electronic device, and storage medium. Background Art

[0002] Currently, most front-end project code requires compilation and building to generate executable target code. Containerization technology is now highly mature, and front-end projects are often deployed using containerization to more efficiently utilize system resources, simplify maintenance and scalability, and address inconsistent front-end runtime environments. These containers must be deployed across multiple server hosts. To better manage multiple containers, we use a container orchestration engine to address this issue. Existing packaging methods involve generating a container, building the project within the container, and then packaging and pushing it to a repository.

[0003] Since the container in the container orchestration engine will be destroyed once pushed to the remote warehouse, for projects that often need to be packaged, after the first packaging is completed, the container needs to be regenerated for packaging each time. However, the resource files that must be used in packaging, mainly used to provide project dependencies, do not need to be updated every time. This results in the resource files originally generated in the container having to be reinstalled each time, which is very time-consuming. Summary of the Invention

[0004] The present disclosure provides a front-end project packaging method, device, electronic device and storage medium to at least solve the above technical problems existing in the prior art.

[0005] In one aspect, the present disclosure provides a method, comprising: connecting to a code repository and obtaining a first file, a second file, and a third file; the first file is used to provide project description and dependency configuration information, the second file is used to associate information of the first file, and the third file is used to provide initial project code;

[0006] Generate a container based on a container orchestration engine, and create a target image in the container;

[0007] Copying the first file and the second file and storing them in the target image;

[0008] Based on the first file, adding a first resource file to the target image, where the first resource file is used to provide project dependencies and conversion statements;

[0009] Converting the project initial code in the third file into target code in the target image;

[0010] Push the target image with the target code to the image repository.

[0011] In one embodiment, before connecting to the code repository, the method includes:

[0012] Obtaining the first file, the third file, and the fourth file locally, wherein the fourth file includes instructions for creating the target image;

[0013] generating the second file according to the first file;

[0014] The first file, the second file, the third file and the fourth file are stored in the remote code repository.

[0015] In one possible implementation, the creating the target image includes: obtaining the fourth file from the code repository, and creating the target image in the container according to the fourth file.

[0016] In one embodiment, converting the project initial code in the third file into target code in the target image includes:

[0017] The first file includes a conversion instruction, and the conversion instruction is used to instruct execution of a conversion statement stored in the first resource file;

[0018] The conversion instruction is executed in the target image to execute the conversion statement and convert the project initial code in the third file into target code.

[0019] In one embodiment, after adding the first resource file to the target image and before converting the initial project code in the third file into the target code in the target image, the method further includes:

[0020] The first resource file is copied to obtain a second resource file.

[0021] In one embodiment, after obtaining the target code and before pushing the target image having the target code to an image repository, the method further includes:

[0022] Copy the first resource file or the second resource file, and copy the target code in the second stage.

[0023] Another aspect of the present disclosure provides an apparatus comprising:

[0024] An acquisition module is used to connect to the code repository and obtain a first file, a second file, and a third file; the first file is used to provide project description and dependency configuration information, the second file is used to associate information of the first file, and the third file is used to provide the initial code of the project;

[0025] A processing module, configured to generate a container based on a container orchestration engine and create a target image in the container;

[0026] Used to copy the first file and the second file and store them in the target image;

[0027] used to add a first resource file in the target image based on the first file, where the first resource file is used to provide project dependencies and conversion statements;

[0028] The processing module is further configured to convert the initial project code in the third file into target code in the target image;

[0029] The analysis module pushes the target image with the target code to the image warehouse.

[0030] Yet another aspect of the present disclosure provides an electronic device, comprising: a memory and a processor, wherein the memory stores a computer program executable by the processor, and the processor implements the above method when executing the computer program.

[0031] Another aspect of the present disclosure provides a storage medium, characterized in that a computer program is stored on the storage medium, and when the computer program is read and executed, the above method is implemented.

[0032] Based on the above solution, the present disclosure creates a target image in a container generated by a container orchestration engine, installs the first resource file in the target image by copying the first file and the second file, and continues to convert the project initial code in the third file into the target code in the target image; after pushing the target image to the image repository to complete the first packaging, when the front-end project is packaged subsequently, as long as the first resource file has not changed, even if the project initial code is changed, the first resource file cached in the image layer of the target image during the first packaging can be directly obtained. Compared with the existing technology, this reduces the process of reinstalling the first resource file and copying the first resource file to the target image, thereby effectively improving the speed of subsequent front-end project packaging. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 FIG2 is a flow chart of a front-end project packaging method provided by an embodiment of the present disclosure;

[0034] Figure 2 FIG2 is a flow chart of a method for repackaging after executing a front-end project packaging method according to an embodiment of the present disclosure;

[0035] Figure 3 FIG2 is a flow chart of a target image creation process provided by another embodiment of the present disclosure;

[0036] Figure 4Shown is a structural diagram of a front-end project packaging device provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0037] To make the purposes, features, and advantages of the present disclosure more apparent and understandable, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present disclosure, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present disclosure without creative work shall fall within the scope of protection of the present disclosure.

[0038] After the front-end project is packaged for the first time, in order to improve the speed of subsequent packaging, such as Figure 1 As shown, an embodiment of the present disclosure provides a front-end project packaging method, including:

[0039] Step 101: Connect to the code repository and obtain a first file, a second file, and a third file; the first file is used to provide project description and dependency configuration information, the second file is used to associate information from the first file, and the third file is used to provide the project initial code;

[0040] In one example, before connecting to the code repository, it is necessary to first obtain the local first file, the third file, and the fourth file. The fourth file includes instructions for creating a target image, and the second file can be generated based on the first file.

[0041] The first file, the second file, the third file, and the fourth file are stored in a remote code repository.

[0042] In one example, Docker containerization technology is used, so the target image is established under the Docker containerization technology system. This disclosure only takes the Docker containerization technology as an example and is not specifically limited here.

[0043] Among them, since the first file is usually used to provide project description and dependency configuration information, in Docker containerization technology, the first file of this function is usually named package.json file, but this disclosure does not make any specific limitation on this naming.

[0044] The second file is generated based on the first file. The second file is usually used to associate information of the first file, such as determining the corresponding version number of the information in the first file. In Docker containerization technology, the second file with this function is usually named yarn.lock file, but this disclosure does not make any specific restrictions on this naming.

[0045] The third file is usually used to provide the initial code of the project. In Docker containerization technology, the third file of this function is usually named as a project code file, but this disclosure does not make any specific limitation on this naming.

[0046] The fourth file usually stores instructions for creating a target image and other instructions for instructing execution. In Docker containerization technology, the third file of this function is usually named as a Dockerfile file, but this disclosure does not make any specific limitation on this name.

[0047] In this example, the code repository is a GitLab code repository. The type of code repository is not specifically limited here.

[0048] The first, third, and fourth files are pre-written and stored locally. The fourth file stores instructions for creating a target image and other instructions for instructing execution. It is understood that the instructions for creating the target image in the fourth file include instructions for creating an operational shell of the target image and for customizing settings such as copying, appending, and storing within the shell of the target image.

[0049] In this step 101 , in addition to obtaining the first file, the second file, and the third file, a fourth file is also obtained when connecting to the code repository.

[0050] In step 101, connecting to the code repository may be performed through a pipeline added to the container orchestration engine, but the specific method for implementing the connection and obtaining the code repository is not specifically limited here.

[0051] Step 102: Generate a container based on the container orchestration engine, and create a target image container in the container;

[0052] In one example, the container orchestration engine uses Kubernetes, but other types may also be used, without specific limitation. A pipeline is added to the container orchestration engine, and the pipeline includes multiple configuration stages. For example, the container orchestration engine may first connect to the repository code through the pipeline and execute step 101 above. Next, the container orchestration engine generates a container through the pipeline. Finally, within the container, a target image is created based on the fourth file.

[0053] As described in step 101 above, the target image here is an empty shell of the target image. By continuing to execute the instructions pre-set in the fourth file in the subsequent steps, operations can be gradually performed in the target image to ultimately obtain a target image with the required content. In other words, the empty shell of the target image is filled until the target image with the required content is obtained. Therefore, the subsequent steps 103 to 105 can be regarded as the process of improving the target image, or the process of further creating the target image.

[0054] It should be understood that the pipeline is pre-set in the container orchestration engine, and the container orchestration engine implements the steps of this solution by executing the pipeline. The execution of step 101 can also be performed through the pipeline of the container orchestration engine, that is, this operation is completed in the container orchestration engine. Other methods can also be adopted, which are not specifically limited here.

[0055] Step 103: copy the first file and the second file and store them in the target image;

[0056] In one example, copying the first file and the second file is equivalent to copying the first file and the second file. According to the content of step 101, the fourth file stores the instructions for creating the target image. Therefore, when the fourth file is locally, it already includes the instructions for copying the first file and the second file and is only executed after the target image is created.

[0057] Since this step is executed after the target image is created, the instructions for copying the first file and the second file are executed according to the characteristics of the target image, and the target image will accordingly generate a first image layer, and the generation results of executing the instructions for copying the first file and the second file will be cached in the first image layer.

[0058] It should be understood that, in one example, the technology for building the target image using the fourth file is Docker containerization technology. In the subsequent packaging process, when creating the target image, Docker will search for reusable existing images in the cache, such as the first file and the second file that have been cached in the first image layer. If subsequent packaging needs to be reused, they can be directly obtained from the first image layer.

[0059] Step 104: Add a first resource file to the target image based on the first file, where the first resource file is used to provide project dependencies and conversion statements.

[0060] By executing the add instruction through the first file, a first resource file can be generated, wherein the first resource file contains the dependencies required for running the project initial code and the target code in the third file, as well as the conversion statement for converting the project initial code in the third file into the target code.

[0061] In one example, in Docker containerization technology, an add instruction is executed through a first file to generate a first resource file, wherein the add instruction can be named yarn.install, which is not specifically limited here.

[0062] Since the first resource file is mainly used to provide the dependencies required by the project, in docker containerization technology, the first resource file of this function is usually named node_modules file, but this disclosure does not make specific restrictions on this name.

[0063] As can be seen from step 101, the fourth file contains instructions for creating the target image, including instructions for creating an operational shell of the target image and customizing settings within the shell for copying, adding, and storing resources. Therefore, the fourth file already contains instructions for adding resources based on the first file, i.e., generating the first resource file, and is only executed after step 103 is completed.

[0064] Since this step 104 is executed after the target image is created, according to the characteristics of the target image, the instruction of adding based on the first file, that is, generating the first resource file, is executed. The target image will accordingly generate a second image layer, and the generation result of the instruction of adding based on the first file, that is, generating the first resource file, is cached in the second image layer.

[0065] Step 105, converting the project initial code in the third file into target code in the target image;

[0066] The first file includes a conversion instruction, and the conversion instruction is used to instruct the execution of the conversion statement stored in the first resource file;

[0067] The conversion instruction is executed in the target image to execute the conversion statement and convert the project initial code in the third file into the target code.

[0068] Before uploading the first file to the remote code repository, a conversion instruction is pre-built in the local first file, and the conversion instruction is used to instruct the execution of the conversion statement stored in the first resource file;

[0069] In one example, the coding language used in the third file is TypeScript, the coding language used in the target code is JavaScript, and the conversion statement includes tsc, the scripting language for converting TypeScript to TypeScript. This is merely an example, and the specific coding language type is not specifically limited here.

[0070] It can be understood that step 105 is based on the completion of step 104. When step 104 is completed, the first file has been stored in the target image and the first resource file has been added. Therefore, the conversion of the project initial code in the third file into the target code is performed based on the joint action of the existing first file, third file and first resource file.

[0071] According to the content in step 101, the fourth file stores the instructions for creating the target image. Therefore, when the fourth file is written, it is written to execute the conversion instructions according to the first file, the first resource file and the third file to obtain the target code, and it will be executed only after step 104 is completed.

[0072] Since this step is performed after the target image is created, according to the characteristics of the target image, the instruction for converting the project initial code in the third file into the target code is executed, and the target image will accordingly generate a third image layer, and the generation result of the instruction for converting the project initial code in the third file into the target code is cached in the third image layer.

[0073] Step 106: Push the target image with the target code to the image repository;

[0074] It should be understood that after step 105 is executed, the target image stores the target code that can be used for the project to run and the first resource file that can provide dependencies for the target code to run. Therefore, pushing the target image with the target code is only used to determine the node where the target image is created, and does not mean that the target image only contains the target code.

[0075] When the target image is pushed to the image repository, the container in the pipeline is destroyed.

[0076] Based on the above solution, the present disclosure creates a target image in a container generated by a container orchestration engine, installs the first resource file in the target image by copying the first file and the second file, and continues to convert the project initial code in the third file into the target code in the target image; after pushing the target image to the image warehouse to complete the first packaging, when the front-end project is packaged subsequently, as long as the first resource file has not changed, even if the project initial code is changed, the first resource file cached in the image layer of the target image during the first packaging can be directly obtained. Compared with the existing technology, the process of reinstalling the first resource file and copying the first resource file to the target image is reduced, thereby effectively improving the speed of subsequent front-end project packaging.

[0077] By executing the packaging method disclosed herein, after the first packaging is completed, when a new round of packaging is required, the cache generated in the target image in the above steps can be used. That is, the technical solution disclosed herein has a better use effect in the subsequent packaging process after the first packaging is completed.

[0078] Specifically, Figure 2As shown, when packaging is performed again, it is determined whether the dependency needs to be changed. The basis for the determination is whether the first file and the second file obtained again from the code repository have changed compared with the first packaging. If the first file and the second file have not changed, it is determined that the dependency does not need to be changed, that is, the first resource file does not need to be changed. Therefore, the first resource file cached in the second image layer of the target image can be directly obtained; on the basis that the first resource file has not changed, it is determined whether the project initial code in the third file has changed. If the project initial code has not changed, the target code can also be directly obtained from the third image layer of the target image; on the basis that the first resource file has not changed, if the project initial code has changed, then step 105 can be re-executed, and the conversion speed of converting the project initial code into the target code has little effect on the project packaging.

[0079] Only when it is determined that the first file and the second file have changed, that is, the first resource file needs to be changed, it is necessary to start from copying the first file and the second file and storing them in the target image, that is, it is necessary to perform all the same steps as the first packaging.

[0080] It should be understood that the aforementioned method of determining if unchanged (i.e., using the cache) is based on the cache characteristics of Docker containerization technology. The target image automatically compares the image if unchanged. If the target image does not execute the relevant instructions (here, the relevant instructions refer to the execution instructions of steps 103 through 105 above), and directly retrieves the cache generated during the initial packaging. Therefore, simply implementing steps 101 through 106 in the present disclosure can achieve the aforementioned beneficial effects during subsequent packaging without requiring additional intervention.

[0081] Therefore, compared with the two most time-consuming steps in the prior art, which require re-adding to generate the first resource file and copying the generated first resource file and target code to the target image, the present disclosure uses a caching mechanism to effectively improve the speed of front-end project packaging in the case where multiple packaging is required after the first packaging.

[0082] In one example, in order to better utilize the cache, such as Figure 3 As shown, an embodiment of the present disclosure further provides a method for creating a target image, which is mainly performed after the above step 102, including:

[0083] Step 301: copy the first file and the second file and store them in the target image;

[0084] Step 302: Add a first resource file to the target image based on the first file, where the first resource file is used to provide project dependencies and conversion statements.

[0085] Step 303: copy the first resource file to obtain a second resource file;

[0086] Since step 303 is also executed in the target image, the obtained second resource file is also stored in the target image.

[0087] Step 304: Convert the project initial code in the third file into target code in the target image;

[0088] According to step 105 above, converting the project code file in the third file into a target code file requires the use of the conversion statement in the first resource file. Since the second resource file is copied from the first resource file, in this step 304, the project initial code in the third file can be converted into the target code based on the second resource file and the first file.

[0089] Step 305: copy the first resource file or the second resource file, and copy the target code.

[0090] In one example, step 305 preferentially copies the first resource file. Since step 305 is also executed in the target image, the third resource file can be obtained in the target image by copying the first resource file. Similarly, the same target code can be obtained in the target image by copying the target code. Therefore, after obtaining the third resource file and the target code, the step of pushing the target image to the image repository can be executed.

[0091] It is understandable that the method of the above steps 301 to 305 is pre-configured in the fourth file and will only be executed after step 102 is completed.

[0092] An embodiment of the present invention also provides a front-end project packaging device, such as Figure 4 As shown, the device includes:

[0093] An acquisition module 10 is configured to connect to a code repository and acquire a first file, a second file, and a third file; the first file is configured to provide project description and dependency configuration information, the second file is configured to associate information from the first file, and the third file is configured to provide initial project code;

[0094] A processing module 20 is configured to generate a container based on a container orchestration engine and create a target image in the container;

[0095] Used to copy the first file and the second file and store them in the target image;

[0096] used to add a first resource file in the target image based on the first file, where the first resource file is used to provide project dependencies and conversion statements;

[0097] The processing module 20 is further configured to convert the project initial code in the third file into target code in the target image;

[0098] The analysis module 30 pushes the target image with the target code to the image repository.

[0099] The system further includes a pre-processing module 40, which is configured to obtain the first file, the third file, and the fourth file locally before connecting to the code repository, wherein the fourth file includes instructions for creating the target image, and generate the second file according to the first file;

[0100] The pre-processing module 40 is further configured to store the first file, the second file, the third file, and the fourth file in the remote code repository.

[0101] In addition to the above-mentioned methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions, which, when executed by a processor, enable the processor to execute the steps of the method according to various embodiments of the present application described in the above-mentioned "Exemplary Method" section of this specification.

[0102] The computer program product may be written in any combination of one or more programming languages ​​to implement the program code for performing the operations of the embodiments of the present application, including object-oriented programming languages ​​such as Java, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0103] In addition, an embodiment of the present application may also be a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, enable the processor to execute the steps of the method according to various embodiments of the present application described in the above "Exemplary Method" section of this specification.

[0104] The computer-readable storage medium can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can, for example, include but is not limited to a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0105] The basic principles of the present application have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, and effects mentioned in this application are merely illustrative and not restrictive, and it should not be assumed that these advantages, strengths, and effects are required of each embodiment of this application. In addition, the specific details disclosed above are merely illustrative and facilitating understanding, and are not restrictive. The above details do not limit this application to necessarily being implemented using the above specific details.

[0106] The block diagrams of the devices, devices, equipment, and systems involved in this application are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, or configured in any manner. Words such as "include," "comprise," "have," and the like are open-ended words, meaning "including but not limited to," and can be used interchangeably therewith. The words "or" and "and" used herein refer to the words "and / or" and can be used interchangeably therewith, unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to," and can be used interchangeably therewith.

[0107] It should also be noted that in the apparatus, device, and method of the present application, each component or each step can be decomposed and / or recombined, and such decomposition and / or recombination should be regarded as equivalent solutions of the present application.

[0108] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present application. Therefore, the present application is not intended to be limited to the aspects shown herein, but rather to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0109] The above description has been provided for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present application to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations thereof.

Claims

1. A front-end project packaging method, characterized in that: include: Connect to the code repository and obtain the first, second, and third files; The first file is used to provide project description and dependency configuration information, the second file is used to associate information of the first file, and the third file is used to provide project initial code; Generate a container based on a container orchestration engine, and create a target image in the container; Copying the first file and the second file and storing them in the target image, and caching the first file and the second file in the first image layer of the target image; Based on the first file, adding a first resource file to the target image, where the first resource file is used to provide project dependencies and conversion statements, and caching the first resource file in the second image layer of the target image; Converting the project initial code in the third file into target code in the target image, and caching the target code in a third image layer of the target image; Pushing the target image with the target code to the image warehouse; After generating a container based on the container orchestration engine and creating a target image in the container, the method further includes: When packaging again, determining whether the first file and the second file obtained have changed compared to the first file and the second file obtained for the first time; if not, obtaining the first resource file from the second image layer of the target image; On the basis that the first resource file has not been changed, determining whether the obtained project initial code of the third file has changed from the project initial code of the third file obtained for the first time; if not, obtaining the target code from the third image layer of the target image; Push the target image with the target code to the image repository.

2. The front-end project packaging method according to claim 1, characterized in that: Before connecting to the code repository, the method includes: Obtaining the first file, the third file, and the fourth file locally, wherein the fourth file includes instructions for creating the target image; generating the second file according to the first file; The first file, the second file, the third file and the fourth file are stored in the remote code repository.

3. The front-end project packaging method according to claim 2, characterized in that: The creating the target image includes: obtaining the fourth file from the code repository, and creating the target image in the container according to the fourth file.

4. The front-end project packaging method according to claim 2, characterized in that: The converting the project initial code in the third file into the target code in the target image includes: The first file includes a conversion instruction, and the conversion instruction is used to instruct execution of a conversion statement stored in the first resource file; The conversion instruction is executed in the target image to execute the conversion statement and convert the project initial code in the third file into target code.

5. The front-end project packaging method according to any one of claims 1 to 4, characterized in that: After adding the first resource file to the target image and before converting the initial project code in the third file into the target code in the target image, the method further includes: The first resource file is copied to obtain a second resource file.

6. The front-end project packaging method according to claim 5, characterized in that: After obtaining the target code and before pushing the target image with the target code to the image repository, the method further includes: The first resource file or the second resource file is copied, and the target code is copied.

7. A front-end project packaging device, characterized in that: include: The acquisition module is used to connect to the code repository and obtain the first file and the second file; and third document; The first file is used to provide project description and dependency configuration information, the second file is used to associate information of the first file, and the third file is used to provide project initial code; A processing module, configured to generate a container based on a container orchestration engine and create a target image in the container; for copying the first file and the second file and storing them in the target image, and caching the first file and the second file in the first image layer of the target image; for adding a first resource file to the target image based on the first file, where the first resource file is used to provide project dependencies and conversion statements, and caching the first resource file in the second image layer of the target image; The processing module is further configured to convert the project initial code in the third file into target code in the target image, and cache the target code in the third image layer of the target image; An analysis module pushes the target image with the target code to an image repository; The processing module is further configured to, when repackaging, determine whether the first file and the second file obtained have changed compared to the first file and the second file obtained for the first time; if not, obtain the first resource file from the second image layer of the target image; On the basis that the first resource file has not changed, it is determined whether the project initial code of the third file obtained has changed from the project initial code of the third file obtained for the first time; if not, the target code is obtained from the third image layer of the target image.

8. The front-end project packaging device according to claim 7, characterized in that: Also includes: a preprocessing module, configured to obtain the first file, the third file, and the fourth file locally before connecting to the code repository, wherein the fourth file includes instructions for creating the target image, and generate the second file based on the first file; The pre-processing module is further configured to store the first file, the second file, the third file, and the fourth file in the remote code repository.

9. An electronic device, characterized in that: include: A memory and a processor, wherein the memory stores a computer program executable by the processor, and when the processor executes the computer program, the front-end project packaging method described in any one of claims 1 to 6 is implemented.

10. A storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is read and executed, the front-end project packaging method described in any one of claims 1 to 6 is implemented.

Images