CN118170420A - A code management method, system and computing device - Google Patents

Abstract

The embodiment of the application provides a code management method, a code management system and a computing device, relates to the technical field of computing devices, and can improve the processing efficiency of access control engineering and ensure the progress of project development. The method includes receiving a merge request; the merge request is for requesting to merge object code with source code and indicates whether to generate a software package; the software package comprises object code and source code, and an operating environment supporting the operation of the object code and the source code; in response to the merging request, merging the target code and the source code to obtain a first code; compiling a first code; updating the source code based on the target code to obtain a second code after the first code is successfully compiled and verified; in the case where the merge request indicates to generate a software package, the second code is packaged to generate the software package.

Description

A code management method, system and computing device

Technical Field

The embodiments of the present application relate to the technical field of computing devices, and in particular, to a code management method, system and computing device.

Background technique

In the process of software development, the Codehub system and the Jenkins system are generally used to build an access control project, which is used to review and automatically compile and verify the newly added code. Usually, the Codehub system reviews the newly added code. After the review is passed, the Jenkins system compiles and verifies the newly added code that has passed the review. After verification, the Jenkins system can also deploy the newly added code to the test environment or production environment for further testing or online operation. It can be seen that the processing process of the access control project for the newly added code is an important factor affecting the progress of software development. How to improve the efficiency of the access control project in view of this process has become a technical problem that needs to be solved urgently.

Summary of the invention

The embodiments of the present application provide a code management method, system and computing device, which can improve the efficiency of access control projects and ensure the progress of project development.

In a first aspect, an embodiment of the present application provides a code management method, the method comprising: receiving a merge request; the merge request is used to request a merge of a target code and a source code and indicate whether to generate a software package; the software package includes the target code and the source code, and an operating environment that supports the operation of the target code and the source code; in response to the merge request, merging the target code and the source code to obtain a first code; compiling the first code; after the compilation and verification of the first code is successful, updating the source code based on the target code to obtain a second code; and when the merge request indicates the generation of a software package, packaging the second code to generate a software package.

The embodiment of the present application provides a code management method. In the method, the project construction platform can receive and respond to the merge request of the code review platform, execute the merge of the code and compile verification, and can further package the second code obtained based on the update to generate the software package when the merge request indicates the generation of the software package. It can be seen that the method provided by the embodiment of the present application can perform the step of packaging the second code to generate the software package on demand based on the indication of the merge request. In this way, it is possible to avoid the project construction platform from packaging the code generated by each merge request indiscriminately, which wastes computing resources while increasing the processing flow and affecting the processing efficiency of the project construction platform. In addition, when the developer has the need to generate a software package, there is no need for the developer to manually configure the command so that the project construction platform executes the packaging process, thereby reducing the technical threshold for developers to use the project construction platform.

In a possible implementation, when the merge request includes the first field, or when the merge request does not include the second field, the merge request is used to indicate generation of a software package; wherein the first field is a field used to indicate generation of a software package, and the second field is a field used to indicate not generation of a software package.

In another possible implementation, generating a software package based on the second code includes: obtaining a configuration file; the configuration file is a file used to support the running of the source code; determining a target configuration file from the configuration file; the target configuration file is used to indicate a method for generating the software package based on the code; determining a package name of the software package according to a file name of the target configuration file; and packaging the second code based on the package name to generate the software package.

In another possible implementation, the merge request includes: the repository address of the target code and information of the merge patch; the merge patch is used to merge the target code with the source code to obtain the first code; merging the target code with the source code to obtain the first code includes: downloading the target code to the local code repository according to the repository address of the target code; the local code repository is a storage space for storing code in the project build platform, and the local code repository also includes source code; obtaining the merge patch according to the information of the merge patch; configuring the merge patch to the local code repository to complete the merge of the target code and the source code to obtain the first code.

In another possible implementation, the merge request also includes: the repository address of the configuration file; compiling the first code, including: downloading the configuration file to the local recipe repository according to the repository address of the configuration file; the local recipe repository is a storage space for storing configuration files in the project build platform; determining the corresponding target configuration file from the local recipe repository according to the repository address of the target code; modifying the address for indexing the code in the target configuration file to the address of the local code repository; and compiling the first code in the local recipe repository.

In another possible implementation, the project construction platform is connected to the code review platform through a transit platform; receiving a merge request includes: receiving a second merge request from the transit platform; the second merge request is a request after the transit platform processes the first merge request sent by the code review platform; wherein the first merge request is a request in a format that complies with a hypertext transfer protocol, and the second merge request is a request in a format that complies with a format that complies with a project construction platform.

In a second aspect, an embodiment of the present application provides a code management system, including a code review platform and a project construction platform; the code review platform is connected to the project construction platform; the code review platform is used to generate a merge request and send the merge request to the project construction platform; the merge request is used to request a merge of a target code and a source code and indicate whether to generate a software package; the software package includes the target code and the source code, and an operating environment that supports the operation of the target code and the source code; the project construction platform is used to, in response to the merge request, merge the target code and the source code to obtain a first code; compile the first code; after the compilation and verification of the first code is successful, update the source code based on the target code to obtain a second code; when the merge request indicates the generation of a software package, package the second code to generate a software package.

In a possible implementation, when the merge request includes the first field, or when the merge request does not include the second field, the merge request is used to indicate generation of a software package; wherein the first field is a field used to indicate generation of a software package, and the second field is a field used to indicate not generation of a software package.

In another possible implementation, the project construction platform is specifically used to obtain a configuration file, determine a target configuration file from the configuration file; determine a package name of a software package according to the file name of the target configuration file; package the second code based on the package name to generate a software package; wherein the configuration file is a file used to support the running of source code, and the target configuration file is used to indicate a method of generating a software package based on the code.

In another possible implementation, the merge request includes: the repository address of the target code and information of the merge patch; the merge patch is used to merge the target code with the source code to obtain the first code; the project construction platform is specifically used to, in response to the merge request, download the target code to the local code repository according to the repository address of the target code; the local code repository is a storage space for storing code in the project construction platform, and the local code repository also includes source code; according to the information of the merge patch, obtain the merge patch; configure the merge patch to the local code repository to complete the merge of the target code and the source code to obtain the first code.

In another possible implementation, the merge request also includes: the repository address of the configuration file; the project build platform is specifically used to download the configuration file to the local recipe repository according to the repository address of the configuration file; the local recipe repository is a storage space in the project build platform for storing configuration files; according to the repository address of the target code, determining the corresponding target configuration file from the local recipe repository; modifying the address for indexing the code in the target configuration file to the address of the local code repository; and compiling the first code in the local recipe repository.

In another possible implementation, the code management system also includes: a transfer platform; the transfer platform is used to connect the code review platform and the project construction platform; the transfer platform is used to receive a first merge request sent by the code review platform, and generate a second merge request based on the first merge request, and send the second merge request to the project construction platform; wherein the first merge request is a request that complies with the format specified by the Hypertext Transfer Protocol, and the second merge request is a request that complies with the format specified by the project construction platform.

In a third aspect, an embodiment of the present application provides a computing device, which includes a processor and a memory; the processor is coupled to the memory; the memory is used to store computer instructions, and the computer instructions are loaded and executed by the processor to enable the computing device to implement the method of the first aspect above.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which includes: computer software instructions; when the computer software instructions are executed in a computing device, the computing device implements the method of the first aspect above.

In a fifth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run on a computing device, the computing device executes the steps of the related method described in the second aspect to implement the method of the first aspect.

The beneficial effects of the second to fifth aspects mentioned above can be referred to the corresponding description of the first aspect and will not be repeated here.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a schematic diagram of the composition of a code management system provided in an embodiment of the present application;

FIG2 is a schematic diagram of another code management system provided in an embodiment of the present application;

FIG3 is a flow chart of a code management method provided in an embodiment of the present application;

FIG4 is a flow chart of another code management method provided in an embodiment of the present application;

FIG5 is a flow chart of another code management method provided in an embodiment of the present application;

FIG6 is a flowchart of a merge event execution provided by an embodiment of the present application;

FIG7 is a schematic diagram of the composition of a code management device provided in an embodiment of the present application;

FIG8 is a schematic diagram of the composition of a computing device provided in an embodiment of the present application.

Detailed ways

The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

It should be noted that, in the embodiments of the present application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplarily" or "for example" is intended to present related concepts in a specific way.

In order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical items or similar items with basically the same functions and effects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order.

The technical terms involved in the embodiments of the present application are explained below.

1. Open baseboard manager controller (OpenBMC) is a Linux distribution of BMC, designed to manage servers across heterogeneous systems, including enterprise, high performance computing (HPC), telecommunications and cloud-scale data centers. OpenBMC provides an open and customizable BMC firmware solution so that server manufacturers and developers can customize and extend the functionality of the BMC.

2. Yocto: is an open source collaborative software that provides templates, tools and methods to create customized Linux systems and embedded products without worrying about the hardware system.

3. Jenkins: It is an open source continuous integration tool used to automate various tasks, including process management such as software project construction, testing and deployment. Among them, continuous integration has the following characteristics: automated and periodic integrated testing process, from obtaining code, compiling and building, running tests, result recording, test statistics, etc. are all completed automatically without manual intervention.

4. Codehub: It is a web-based code review tool. Codehub can distribute the code submitted by a developer to other developers to realize multi-person code review. After the review is passed, Codehub can further process the code, such as sending it to Jenkins for deployment. It implements code management based on the distributed version control system (git). The feature of git is that it can support different developers to operate the source code of the jointly developed project on their respective user-side devices to fix source code failures or add new functions.

5. bitbake: It is a task execution engine, similar to a script interpreter. It is mainly used to parse and execute build scripts, build software packages, and generate images in Yocto-based projects.

6. Gerrit: It is a web-based code review tool with similar functions to Codehub, which can support multiple developers to collaborate on projects.

7. Branches and main branches: The concept introduced by git is also based on branches for code management in Jenkins. Code branches can be understood as different versions of the code. For example, a code can have two branches, one for developers to test and the other for the official online operation of the code. Taking the source code as an example, if the source code has only one version, it is called the main branch of the source code by default. When the developer is developing, he can copy the source code to the user-side device based on the main branch of the source code to develop based on the source code. For the convenience of description, the new code is uniformly called the target code below (similarly, when the developer writes the target code, he may also create multiple branches based on the target code). The code after the target code and the source code are merged is called the first code, and the code obtained after the source code is updated based on the target code is called the second code. The difference between the first code and the second code is that the first code is to temporarily merge the target code and the source code for compilation verification, and the second code is to store the target code in the file or code library corresponding to the source code after determining that there is no problem with the target code, which is the updated code obtained, which can facilitate subsequent deployment and online.

8. Code repository: refers to a storage space used to store code (such as source code and object code). The local code repository mentioned in the embodiments of the present application refers to a storage space created by the project construction platform for storing code.

9. Recipe warehouse: refers to the storage space used to store relevant configuration files that support code execution. The local recipe warehouse mentioned in the embodiments of the present application refers to the storage space created by the project construction platform to store configuration files corresponding to the source code.

As described in the background technology, in the process of software development, the Codehub system and the Jenkins system are generally used to build the access control project. The access control project refers to compiling and verifying the target code. Only when the target code is guaranteed to run without problems can the target code be merged into the main branch of the source code or released to the test environment/production environment to reduce the occurrence of errors and failures. Among them, the test environment is used for further testing of the code before it goes online (i.e., it is released to the production environment). The test environment is basically similar to the production environment, which can ensure that the code runs without problems after going online. In the access control project built by the Codehub system and the Jenkins system, developers can submit the reviewed target code to the Jenkins system through the Codehub system. For example, the Codehub system can trigger the Jenkins system to perform automatic build tasks through a merge request (merge request, MR). The Jenkins system responds to the merge request and can perform automatic build tasks, including obtaining the target code submitted by the developer, merging it with the source code, and then compiling and verifying it. During the compilation and verification process, the relationship between the target code and the source code can be temporarily established so that the target code can be temporarily run for verification. If the compilation result indicates that the compilation is successful, the target code is allowed to be stored in the code library. If the compilation result indicates that the compilation has failed, the Jenkins system can prevent the newly added target code from being stored in the repository and notify the developer of the problems that need to be fixed. Code storage refers to the process of updating the source code based on the target code, which can be understood as writing the target code into the file corresponding to the source code (or storing the target code in the code library corresponding to the source code) to facilitate the subsequent online deployment of the code.

It should be understood that in the software development process, the code (such as the aforementioned source code and the first code) can only be executed in a specific computing device. For example, the code operation requires the computing device to be configured with an operating environment (such as a compiler installed, and dependent packages that support code operation, etc.). For other devices (such as user-side devices of general users), due to the lack of an operating environment, it is impossible to implement software operation by directly executing the code. In response to this situation, it is necessary to package the code into a software package (also called an installation package or an application (APP) package) and archive (store), so that the code can be sent to other devices in the form of a software package, so as to implement further testing of the code function by running the software package on other devices, or for users to download and use normally.

The current access control project has no reasonable way to handle whether to package the updated second code into a software package when processing merge requests. If the packaging step is performed for each merge request, the processing flow will be increased, affecting the processing efficiency of the access control project and further affecting the development progress of the project.

In addition, if the access control project does not perform the packaging step for merge requests by default, when the developer has the need to generate a software package, the developer is required to manually configure the access control project through commands to create a packaging task so that the access control project can perform the packaging action. This requires a high level of technical skills from the developer and will also affect the processing efficiency of the access control project.

For example, in the scenario of developing a new function, developers need to generate a software package when merging codes, so that the software package can be put online for users to download and use, so that users can experience the new function. In this case, developers need to generate a software package.

In the code maintenance scenario, there may be multiple developers who maintain different parts of the source code. In this case, if a developer submits a merge request and maintains the part he is responsible for, it is not very meaningful to package the source code to generate a software package (because it is necessary to package after all developers submit merge requests to ensure that all parts of the software package are maintained). In other words, in this case, the developer does not need to generate a software package.

Based on this, the embodiment of the present application provides a code management method. In the method, the project construction platform can receive and respond to the merge request of the code review platform, execute the merge of the code and compile verification, and can further package the second code obtained by the update based on the merge request instruction to generate a software package to generate a software package. It can be seen that in the method provided by the embodiment of the present application, the project construction platform can perform the step of packaging the second code to generate a software package on demand based on the instruction of the merge request. In this way, it is possible to avoid the project construction platform from packaging the code generated by each merge request indiscriminately, wasting computing resources while increasing the processing flow, affecting the processing efficiency of the project construction platform. In addition, when the developer has the need to generate a software package, there is no need for the developer to manually configure the command so that the project construction platform executes the process of packaging, thereby reducing the technical threshold for developers to use the project construction platform.

FIG1 is a schematic diagram of the composition of a code management system provided in an embodiment of the present application. As shown in FIG1 , a code management system 100 includes a code review platform 101 and a project construction platform 102 .

The code review platform 101 is used to generate a merge request and send the merge request to the project construction platform 102; the merge request is used to request to merge the target code and the source code and indicate whether to generate a software package; the software package includes the target code and the source code, and an operating environment that supports the operation of the target code and the source code;

The project construction platform 102 is used to, in response to a merge request, merge the target code and the source code to obtain a first code; compile the first code; after the first code compilation is successfully verified, update the source code based on the target code to obtain a second code; and when the merge request indicates to generate a software package, package the second code to generate a software package.

In some implementations, when the merge request includes a first field, or when the merge request does not include a second field, the merge request is used to indicate generation of a software package; wherein the first field is a field used to indicate generation of a software package, and the second field is a field used to indicate not generation of a software package.

In some embodiments, the project construction platform 102 is specifically used to obtain a configuration file, determine a target code target configuration file from the configuration file; determine a package name of a software package according to the file name of the target configuration file; package the second code based on the package name to generate a software package; wherein the configuration file is a file used to support source code operation, and the target configuration file is used to indicate a method for generating a software package based on the code.

In some embodiments, the merge request includes: the repository address of the target code and the information of the merge patch; the merge patch is used to merge the target code with the source code to obtain the first code; the project construction platform 102 is specifically used to, in response to the merge request, download the target code to the local code repository according to the repository address of the target code; the local code repository is a storage space for storing code in the project construction platform, and the local code repository also includes source code; according to the information of the merge patch, obtain the merge patch; configure the merge patch to the local code repository to complete the merge of the target code and the source code to obtain the first code.

In some embodiments, the merge request also includes: the warehouse address of the configuration file; the project construction platform 102 is specifically used to download the configuration file to the local recipe warehouse according to the warehouse address of the configuration file; the local recipe warehouse is a storage space in the project construction platform for storing configuration files; according to the warehouse address of the target code, the corresponding target configuration file is determined from the local recipe warehouse; the address of the target configuration file used to index the code is modified to the address of the local code warehouse; the first code is compiled in the local recipe warehouse. Among them, the local code warehouse and the local recipe warehouse can be understood as different directories in the same computing device. It should be understood that by modifying the address, the target configuration file can access the code in the local code warehouse to perform subsequent code compilation processes.

In some embodiments, as shown in FIG. 2 , the code management system 100 further includes: a transfer platform 103; the transfer platform 103 is used to connect the code review platform 101 and the project construction platform 102; the transfer platform 103 is used to receive a first merge request sent by the code review platform, generate a second merge request based on the first merge request, and send the second merge request to the project construction platform; wherein the first merge request is a request in a format that complies with the hypertext transfer protocol (HTTP), and the second merge request is a request in a format that complies with the project construction platform.

For ease of description, the merge request sent by the code review platform 101 to the transit platform 103 is referred to as the first merge request below. The merge request sent by the transit platform 103 to the project construction platform 101 is referred to as the second merge request. Both the first merge request and the second merge request can be POST requests, which are characterized by carrying the relevant parameters required for this merge (such as the target warehouse address, etc.) in the request body to ensure security. The difference between the first merge request and the second merge request is that the first merge request is a request that complies with the format specified by the Hypertext Transfer Protocol, while the second merge request is a request that complies with the format specified by the Jenkins system.

For example, taking the development of the OpenBMC project based on Yocto as an example, a access control project (i.e., the code management system of the technical solution of this application) is built based on the Jenkins system and the Codehub system. The access control project can manage and deploy the relevant codes of the OpenBMC project.

First, build a Jenkins system to deploy the OpenBMC project. As an example, the uniform resource locator (URL) address of the Jenkins system can be "http://Jenkins.com". Further, create a Jenkins task as a door access control project. For example, the door access control project can be named MR_OpenBMC_APP, and the corresponding URL address is: http://[Jenkins address]job/[door access control project name]/buildWithParameters.

Optionally, due to the differences between the Codehub system and the Jenkins system, there are certain differences in the communication protocols between the two systems (for example, there are certain differences in the format of carrying request parameters). Therefore, in order to facilitate the Jenkins system to receive and execute the merge request sent by the Codehub system, a transit web service can be built to receive the merge request from Codehub and trigger the Jenkins system to execute the merge task. For example, the URL address of the transit web service is "http://zhongzhuan.com".

The code review platform in the embodiment of the present application may be the above-mentioned Codehub system or gerrit system, which is used to implement the review of the code and initiate a merge request to request that the target code that has passed the review be merged into the source code. The transit platform may be a transit Web service built by software, which is used as a transit node between the code review platform and the project construction platform, and is used to convert the first merge request sent by the code review platform into a second merge request that can be parsed by the project construction platform. The project construction platform may be the above-mentioned Jenkins system, which is used to obtain the target code and the source code according to the merge request, merge and compile them, and after successful compilation, package and store the software package.

It is understandable that each platform in the above code management system can be deployed in different computing devices, and each computing device is connected by communication. Alternatively, each platform in the above code management system can be deployed in the same computing device. Alternatively, one platform in the above code management system can be deployed in one computing device, and the other two platforms can be deployed in another computing device. The embodiment of the present application does not limit this specific implementation.

The computing device used in the technical solution provided in the embodiments of the present application may specifically be a blade server, a high-density server, a rack server or a high-performance server, or a general-purpose server, a graphics processing unit (GPU) server, a data processing unit (DPU) server or an artificial intelligence (AI) server, etc.

Fig. 3 is a flow chart of a code management method provided in an embodiment of the present application. Exemplarily, the code management method provided in an embodiment of the present application can be applied to the project construction platform of the code management system shown in Fig. 1 or Fig. 2.

As shown in FIG3 , the code management method provided in the embodiment of the present application may specifically include the following steps:

S301. Receive a merge request from the code review platform.

Among them, the merge request is used to request to merge the target code and the source code.

In an embodiment of the present application, if the developer has completed the writing of the target code and needs to merge the target code into the source code, by merging the target code into the source code, operations such as supplementing the function of the source code or fixing vulnerabilities can be implemented. The developer can perform operations on the code review platform, so that the code review platform initiates a merge request to the project construction platform.

As an example, the merge request includes the following parameters: information of the merged patch, the repository address of the target code, and the repository address of the configuration file. Optionally, the merge request may also include the MR title, the branch identifier of the target code, the branch identifier of the source code, the MR initiator identifier, etc.

The MR title can be used to describe the content of this code merge, so that other developers can understand the purpose of this merge. For example, the MR title is "This time fixes xxx fault", which is used to indicate that the purpose of this merge is to repair the xxx fault.

The warehouse address of the target code is the address of the storage space where the target code is stored. As mentioned above, the code management system supports collaborative development by multiple developers. Therefore, each developer will create a storage space (called a target warehouse) on his or her own user-side device to store the target code. At the same time, there may be multiple versions of the target code, that is, the target code has multiple different branches. For example, for the implementation of the same function, the developer has written two implementation methods respectively, which can correspond to two branches of the target code. When a merge is required, the developer will send a merge request through the code review platform to notify the project construction platform of the target warehouse address where the target code to be merged is located, so that the project construction platform can download the target code from the target warehouse based on the target warehouse address for merging. Optionally, the branch identifier of the target code can also be indicated in the merge request, so that the project construction platform can obtain the target code on the corresponding branch according to the branch identifier.

The information of the merge patch can be used by the project build platform to obtain the merge patch. The merge patch can be a tool and a step execution sequence, which is used to merge the target code into the source code, specifically into a branch of the source code. The merge patch can also generate a unique identifier (MR number) for the merge request, and the developer can query the relevant information of the corresponding merge request based on the MR number. It should be understood that the information of the merge patch can be the storage address of the merge patch, or other parameters used to instruct the project build platform to obtain the merge patch, such as the identifier of the merge patch.

The branch identifier of the source code indicates the branch of the source code to be merged into the target code. Based on the branch identifier of the source code in the merge request, it can be determined which branch of the source code the target code needs to be merged into, generally the main branch.

The repository address of the configuration file is used to indicate the storage location of the configuration file. The configuration file is used to indicate the execution order of the code, the dependency packages, compilers, etc. required during the code running process, which are essential factors for compiling the code.

The MR initiator ID can help other developers check who initiated the merge request. In addition, the MR initiator ID can also be used to archive software packages, that is, different directories are created for different initiators to store corresponding software packages, which facilitates unified management of software packages.

In one implementation, when the project construction platform is connected to the code review platform through the transit platform, the above S301 can be implemented as follows: receiving a second merge request from the transit platform; the second merge request is a request after the transit platform processes the first merge request sent by the code review platform. The first merge request is a request in a format that complies with the HTTP protocol, and the second merge request is a request in a format that complies with the project construction platform.

Among them, the webhook module in the code review platform supports initiating a first merge request to a specified URL (the address of the transfer platform) based on the developer's instructions. Furthermore, the transfer platform sends a second merge request to the project construction platform based on the parameters carried in the first merge request, so that the project construction platform executes processes such as code merging and compilation.

Exemplarily, the transit platform may parse the first merge request, extract the parameters of the request body in the first merge request, construct a second merge request that complies with the format specified by the project construction platform, and send it to the project construction platform.

S302: In response to the merge request, merge the target code and the source code to obtain a first code.

S303: Compile the first code.

S304: After the first code is compiled and verified successfully, the source code is updated based on the target code to obtain a second code.

For S302-S304 above, in an embodiment of the present application, after receiving a merge request, in response to the merge request, the project construction platform can obtain the target code and the source code, merge the target code and the source code to obtain the first code. Then run the first code for compilation, and judge whether there is a problem with the target code according to the compilation result. If there is no problem with the compilation result, the source code is updated to obtain the second code (i.e., the process of code storage), so that the second code can be deployed to a specified test environment or a production environment for use later.

In one implementation, if there is a problem with the compilation result, the current target code is prohibited from being stored (ie, the source code is not updated), and information related to the problem is returned to the initiator of the merge request so that the initiator can make further modifications to the target code.

For details of the merging process in S302, please refer to the description corresponding to FIG. 4 below. For details of the compiling process in S303, please refer to the description corresponding to FIG. 5 below.

S305: When the merge request indicates to generate a software package, generate the software package based on the second code.

In an embodiment of the present application, the project construction platform determines that the merge request indicates the generation of a software package. If the merge request indicates the generation of an archived software package, the process of packaging the second code into a software package is executed. In addition, the software package can also be stored to facilitate the subsequent testing and running of the first code on other devices. It can be seen that when the developer does not have the need to generate a software package, the project construction platform can generate a software package for the updated second code after the first code is verified, without the user having to perform additional packaging operations, thereby improving the processing efficiency of the code management system.

Exemplarily, whether the first merge request indicates to generate a software package may be determined in the following manner:

If the merge request includes the first field (for example, when the developer enters the MR title, the MR title carries the field of "generate software package"), or includes the second field (for example, when the developer enters the MR title, the MR title carries the field of "do not generate software package"), it means that the code management system needs to generate a software package for storage during this merge process.

If the merge request does not include the first field or the second field, it means that the code management system does not need to generate a software package during this merge process. After receiving the merge request, the project construction platform can execute the above S302 instead of S303. It can be seen that when the developer does not have the need to generate a software package, the project construction platform only compiles and verifies the first code and stores the code in the library, and does not execute the process of packaging and generating the software package. This can reduce the time spent in the process of generating the software package and improve the processing efficiency of the code management system. In addition, the on-demand generation and archiving of the software package according to the content in the merge request, rather than indiscriminately generating and storing the software packages corresponding to all merge requests, can avoid the waste of storage resources.

In one implementation, the merge request includes: the repository address of the target code and information of the merge patch. The merge patch is used to merge the target code with the source code to obtain the first code. The merge of the target code with the source code to obtain the first code in S302 above can be implemented as follows, as shown in FIG4:

S401, downloading the target code to the local code warehouse according to the warehouse address of the target code, wherein the local code warehouse is a storage space for storing codes in the project construction platform, and the local code warehouse also includes source code.

S402: Obtain a merged patch according to information of the merged patch.

S403: deploy the merged patch into the local code repository to complete the merging of the target code and the source code to obtain the first code.

Exemplarily, the project construction platform parses the merge request and obtains the warehouse address of the target code. Based on the warehouse address, the warehouse storing the target code is accessed through a network request, and the corresponding target code is downloaded (if the branch identifier of the target code is instructed in the merge request, the target code on the corresponding branch can be downloaded) to the local code warehouse created by the project construction platform itself. Furthermore, the project construction platform obtains the merge patch based on the branch of the source code and the information of the merge patch, and configures the merge patch to the local code warehouse. As mentioned above, the merge patch is a tool for merging the target code with the source code. After the project construction platform obtains the merge patch and configures it to the local code warehouse, the merge patch can be run to read the target code downloaded to the local code warehouse and merge it to the source code (if the branch identifier of the source code is indicated in the merge request, the corresponding merge patch can be obtained according to the branch identifier to merge the target code to the source code of the specified branch), and the first merged code is obtained.

In one implementation, the merge request also includes: the repository address of the configuration file. Compiling the first code in S303 above, as shown in FIG5 , can be implemented as follows:

S501. Download the configuration file to the local recipe warehouse according to the warehouse address of the configuration file. The local recipe warehouse is a storage space in the project construction platform for storing configuration files.

S502: According to the warehouse address of the target code, determine the corresponding target configuration file from the local recipe warehouse.

S503: Modify the address for indexing the code in the target configuration file to the address of the local code repository.

S504: Compile the first code in the local recipe repository.

It should be understood that after obtaining the first code, the project construction platform also needs to compile the first code to run so that the first code can achieve the expected function. In addition, as mentioned above, the operation of the code needs to rely on the operating environment (such as certain dependent packages are required to run normally). Therefore, the project construction platform can access the recipe warehouse storing the configuration file according to the warehouse address of the configuration file, and download the configuration file to the local recipe warehouse. Further, the target configuration file for indexing the code location is queried from the configuration file, and the address for indexing the code in the target configuration file is modified to the address of the local code warehouse, and then the project construction platform executes the code compilation command in the local recipe warehouse, so that the configuration file can run to build the operating environment, and read the first code from the local code warehouse according to the address of the target configuration file for compilation.

It can be understood that if the first code is compiled successfully, it means that there is no problem with the target code written by the developer in this merger, and the project construction platform allows the code to be stored, that is, the source code is updated based on the target code. Conversely, if the first code fails to compile, it means that there is a problem with the target code written by the developer in this merger, and the project construction platform prohibits the code from being stored, and feedbacks the error corresponding to the compilation failure to the developer, so that the developer can modify the target code based on the error.

It should be understood that the target code is stored in the target warehouse of the developer's user-side device. When necessary, the project construction platform can access the target warehouse and download it for use, which can realize the distributed development of the project and improve the efficiency of project development. In addition, the project construction platform can execute the compilation steps in sequence through script configuration such as configuration files and merge patches, without manual participation, thus improving development efficiency.

In related solutions, when there is a need to generate a software package, the developer needs to manually configure the package name of the software package, which requires additional manual operations and affects efficiency. The code management method provided in the embodiment of the present application uses the warehouse address of the target code to infer the corresponding configuration file and software package name, and automatically completes the generation of the software package, which is specifically described as follows:

In one implementation, the second code is packaged to generate a software package in S305, including: 1. Obtaining a configuration file. 2. Determining a target configuration file corresponding to the target code from the configuration file. 3. Determining a package name of the software package according to the file name of the target configuration file. 4. Packaging the second code based on the package name to generate a software package.

The specific process of obtaining the configuration file and determining the target configuration file can be found in the description of the above implementation, and will not be repeated here.

It should be understood that when the code is packaged, the developer needs to specify the package name of the software package for archiving and storage. However, in general, the package name configured by the software package is related to the project name corresponding to the source code, and contains information such as the version corresponding to the current project. This requires the developer to manually query the relevant information of the source code to determine the package name, and the operation is relatively cumbersome. Considering that the role of the target configuration file is to describe the way the code generates the software package, its naming is strongly related to the project name. Therefore, in the embodiment of the present application, the project construction platform extracts the package name based on the target configuration file, and executes a packaging command (such as a bitbake command, or other commands for packaging) based on the package name to package the second code as a software package, and the software package is stored, so that the software package generation and archiving are automatically completed without the need for the developer to participate.

Exemplarily, taking the OpenBMC project as an example, the file format of the corresponding target configuration file is bb type or bbappend type. The naming of these two files usually follows certain conventions and specifications to ensure the maintainability and clarity of the project, and to facilitate management and identification by developers. In addition, considering that underscores and certain wildcards will conflict with key characters of the operating system, it is also necessary to ensure that such characters are not included in the package name of the software package when generating the software package. Therefore, for files of type bb, the package name of the corresponding software package can be obtained by removing the "_" in the file name. For files of type bbappend, the package name of the corresponding software package can be obtained by removing the "_" and wildcard in the file name. After determining the package name, the project construction platform can use a packaging command to package the first code into a software package based on the package name.

It should be understood that the storage location of the software package can be a preset local location or a preset cloud location, and the present application embodiment does not impose specific restrictions on this. In addition, during the process of archiving and storing the software package, it can be archived according to the initiator's identification, which is convenient for determining the developer corresponding to the currently merged software package, so that the corresponding developer can be notified to perform maintenance later.

In some scenarios, the technical solution of the embodiment of the present application is explained by taking the keywords in the MR title in the merge request as an example. When initiating a merge request, the developer can edit the MR title to determine whether the current operation is to store the software package. Optionally, a function can be developed on the code review platform to display a control when a merge request needs to be initiated. If the developer clicks the control, the project construction platform will generate a software package and archive it when merging the code. In the default state, the software package will not be generated and saved.

Figure 6 is a merge event execution flow chart provided by an embodiment of the present application. As shown in Figure 5, first, 1. Initiate a merge request. 2. The transit platform forwards the merge request to the project construction platform. 3. Download the target code to the local code repository. 4. Download the merge patch configuration to the local code repository. 5. Download the configuration file and modify the address used to index the code in the target configuration file. 6. Determine the package name of the software package based on the target configuration file. 7. Compile. When the compilation is unsuccessful, 8. Intercept the code from being stored in the library and end. When the compilation is successful, 9. Execute the code from being stored in the library. Further judge, 10. Whether the merge request indicates to generate a software package. If indicated, 11. Generate a software package and archive it. If not indicated, 12. Exit the process.

The embodiment of the present application provides a code management method, in which the project construction platform can receive and respond to the merge request of the code review platform, and after executing the merge and compilation verification of the code, it can be further based on the second code package obtained by the update to generate the software package when the merge request indicates the archive generation software package. It can be seen that in the method provided by the embodiment of the present application, the project construction platform can perform the step of packaging the second code to generate the software package on demand based on the instruction of the merge request. This can avoid the project construction platform from packaging the code generated by each merge request indiscriminately, and wastes computing resources while increasing the processing flow, affecting the processing efficiency of the project construction platform. In addition, when the developer has the need to generate a software package, there is no need for the developer to manually configure the command so that the project construction platform executes the process of packaging, reducing the technical threshold for developers to use the project construction platform.

Furthermore, in the code management method provided in the embodiment of the present application, the project construction platform can independently infer the corresponding configuration file based on the address of the target code repository, and determine the package name of the software package based on the configuration file, without the need for developers to manually edit the package name, thereby further improving the processing efficiency of the code management system.

It can be seen that the above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. In order to achieve the above functions, the embodiment of the present application provides a hardware structure and/or software module corresponding to each function. Those skilled in the art should easily appreciate that, in combination with the modules and algorithm steps of each example described in the embodiment disclosed herein, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

In an exemplary embodiment, the present application further provides a code management device. The code management device can be applied to the aforementioned project construction platform. The code management device can include one or more functional modules for implementing the code management method of the above method embodiment.

For example, Fig. 7 is a schematic diagram of the composition of a code management device provided in an embodiment of the present application. As shown in Fig. 7, the code management device includes: a receiving module 701 and a processing module 702. The receiving module 701 is connected to the processing module 702.

The receiving module 701 is used to receive a merge request; the merge request is used to request to merge the target code and the source code and indicate whether to generate a software package; the software package includes the target code and the source code, and an operating environment that supports the operation of the target code and the source code;

The processing module 702 is used to, in response to the merge request, merge the target code and the source code to obtain the first code;

The processing module 702 is further used to compile the first code;

The processing module 702 is also used to update the source code based on the target code to obtain the second code after the first code is successfully compiled and verified;

The processing module 702 is further configured to package the second code to generate a software package when the merge request indicates to generate a software package.

In some implementations, when the merge request includes a first field, or when the merge request does not include a second field, the merge request is used to indicate generation of a software package; wherein the first field is a field used to indicate generation of a software package, and the second field is a field used to indicate not generation of a software package.

In some embodiments, the processing module 702 is specifically used to obtain a configuration file; the configuration file is a file used to support the running of the source code; determine a target configuration file from the configuration file; the target configuration file is used to indicate a method for generating a software package based on the code; determine a package name of the software package according to the file name of the target configuration file; and package the second code based on the package name to generate a software package.

In some embodiments, the merge request includes: the repository address of the target code and the information of the merge patch; the merge patch is used to merge the target code with the source code to obtain the first code; the processing module 702 is specifically used to download the target code to the local code repository according to the repository address of the target code; the local code repository is a storage space for storing code in the project construction platform, and the local code repository also includes source code; according to the information of the merge patch, obtain the merge patch; configure the merge patch to the local code repository to complete the merge of the target code and the source code to obtain the first code.

In some embodiments, the merge request also includes: the repository address of the configuration file; the processing module 702 is specifically used to download the configuration file to the local recipe repository according to the repository address of the configuration file; the local recipe repository is a storage space for storing configuration files in the project construction platform; according to the repository address of the target code, determining the corresponding target configuration file from the local recipe repository; modifying the address for indexing the code in the target configuration file to the address of the local code repository; and compiling the first code in the local recipe repository.

In some embodiments, the project construction platform is connected to the code review platform via a transit platform; the receiving module 701 is specifically used to receive a second merge request from the transit platform; the second merge request is a request after the transit platform processes the first merge request sent by the code review platform; wherein, the first merge request is a request in a format that complies with the Hypertext Transfer Protocol, and the second merge request is a request in a format that complies with the project construction platform.

In an exemplary embodiment, the present application also provides a computing device. FIG8 is a schematic diagram of the composition of the computing device provided in the present application. As shown in FIG8, the computing device may include: a processor 801 and a memory 802; the memory 802 stores instructions executable by the processor 808; when the processor 801 is configured to execute the instructions, the computing device implements the method described in the aforementioned method embodiment.

The embodiment of the present application also provides a computer-readable storage medium. All or part of the processes in the above method embodiment can be completed by computer instructions to instruct the relevant hardware, and the program can be stored in the above computer-readable storage medium. When the program is executed, it may include the processes of the above method embodiments. The computer-readable storage medium can be any of the above embodiments or memory. The above computer-readable storage medium can also be an external storage device of the above recovery device, such as a plug-in hard disk, a smart memory card (smart media card, SMC), a secure digital (secure digital, SD) card, a flash card (flashcard), etc. equipped on the above recovery device. Further, the above computer-readable storage medium can also include both the internal storage unit of the above recovery device and an external storage device. The above computer-readable storage medium is used to store the above computer program and other programs and data required for the above recovery device. The above computer-readable storage medium can also be used to temporarily store data that has been output or is to be output.

An embodiment of the present application also provides a computer program product, which includes a computer program. When the computer program product is run on a computer, the computer is enabled to execute any one of the code management methods provided in the above embodiments.

Although the present application is described herein in conjunction with various embodiments, in the process of implementing the claimed application, those skilled in the art may understand and implement other variations of the disclosed embodiments by viewing the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other components or steps, and "one" or "an" does not exclude multiple situations. A single processor or other unit may implement several functions listed in a claim. Certain measures are recorded in different dependent claims, but this does not mean that these measures cannot be combined to produce good results.

Although the present application has been described in conjunction with specific features and embodiments thereof, it is obvious that various modifications and combinations may be made thereto without departing from the spirit and scope of the present application. Accordingly, this specification and the drawings are merely exemplary illustrations of the present application as defined by the appended claims, and are deemed to have covered any and all modifications, variations, combinations or equivalents within the scope of the present application. Obviously, those skilled in the art may make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims (10)

1.A method of code management, the method comprising:

receiving a merging request; the merge request is used for requesting to merge the target code and the source code and indicating whether to generate a software package; the software package comprises the target code, the source code and an operating environment supporting the target code and the source code to operate;

responding to the merging request, and merging the target code and the source code to obtain a first code;

Compiling the first code;

After the first code compiling verification is successful, updating the source code based on the target code to obtain a second code;

And packing the second code to generate a software package under the condition that the combination request indicates to generate the software package.

2. The method of claim 1, wherein the step of determining the position of the substrate comprises,

In the case that the merge request includes a first field or in the case that the merge request does not include a second field, the merge request is to indicate generation of a software package;

The first field is a field for indicating that the software package is generated, and the second field is a field for indicating that the software package is not generated.

3. The method of claim 1 or 2, wherein said packaging the second code to generate a software package comprises:

acquiring a configuration file; the configuration file is a file for supporting the running of the source code;

Determining a target configuration file from the configuration files; the target configuration file is used for indicating a mode of generating a software package based on codes;

determining the package name of the software package according to the file name of the target configuration file;

and packing the second code based on the package name to generate the software package.

4. A method according to any of claims 1-3, wherein the merge request comprises: the warehouse address of the target code and the information of the merged patch; the merging patch is used for merging the target code and the source code to obtain the first code;

the merging the target code and the source code to obtain a first code includes:

Downloading the target code to a local code warehouse according to the warehouse address of the target code; the local code warehouse is a storage space for storing codes in the project construction platform, and the local code warehouse also comprises the source codes;

Acquiring a combined patch according to the information of the combined patch;

and configuring the merging patch into the local code warehouse to finish merging the target code and the source code to obtain the first code.

5. The method of claim 4, wherein the merge request further comprises: a repository address of the configuration file; the compiling the first code includes:

Downloading the configuration file to a local formula warehouse according to the warehouse address of the configuration file; the local formula warehouse is a storage space used for storing the configuration file in the project construction platform;

determining a corresponding target configuration file from the local recipe warehouse according to the warehouse address of the target code;

modifying the address for indexing codes in the target configuration file to be the address of the local code warehouse;

The first code is compiled in the local recipe store.

6. The method according to any one of claims 1-5, wherein the method is applied to a project construction platform, which is connected to a code review platform through a relay platform;

The receiving a merge request includes:

receiving a second merging request of the transfer platform; the second merging request is a request which is processed by the first merging request and is sent by the transfer platform to the code review platform;

Wherein the first combined request is a request conforming to a hypertext transfer protocol, HTTP, specification format, and the second combined request is a request conforming to the project build platform specification format.

7. The code management system is characterized by comprising a code review platform and an item construction platform; the code review platform is connected with the project construction platform;

The code review platform is used for generating a merging request and sending the merging request to the project construction platform; the merge request is used for requesting to merge the target code and the source code and indicating whether to generate a software package; the software package comprises the target code, the source code and an operating environment supporting the target code and the source code to operate;

The project construction platform is used for responding to the merging request and merging the target code and the source code to obtain a first code; compiling the first code; after the first code compiling verification is successful, updating the source code based on the target code to obtain a second code; and packing the second code to generate a software package under the condition that the combination request indicates to generate the software package.

8. The system of claim 7, wherein the system further comprises a controller configured to control the controller,

The project construction platform is specifically used for acquiring a configuration file and determining a target configuration file from the configuration file; determining the package name of the software package according to the file name of the target configuration file; packaging the second code based on the package name to generate the software package;

The configuration file is a file for supporting the source code to run, and the target configuration file is used for indicating a mode of generating a software package based on codes.

9. The system of claim 7 or 8, wherein the code management system further comprises: a transfer platform; the transit platform is used for connecting the code review platform and the project construction platform;

The transfer platform is used for receiving the first merging request sent by the code review platform, generating a second merging request according to the first merging request and sending the second merging request to the project construction platform;

Wherein the first combined request is a request conforming to a hypertext transfer protocol, HTTP, specification format, and the second combined request is a request conforming to the project build platform specification format.

10. A computing device, the computing device comprising a processor and a memory; the processor is coupled with the memory; the memory is for storing computer instructions that are loaded and executed by the processor to cause the computing device to implement the code management method of any of claims 1-6.