Method and device for publishing two-party package assembly, electronic equipment and storage medium
By parsing the project object model file and replacing it with the target change repository, the unavailability issue caused by component repository permissions was resolved, enabling reliable and accurate component release and simplifying the operation process.
Patent Information
- Application Number
- CN202211683349.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-12-27
- Publication Date
- 2026-02-13
- Estimated Expiration
- 2042-12-27
AI Technical Summary
In the company's internal software development, the excessively open administrator privileges of the component repository have led to the replacement of stable version components. This may result in components becoming unusable in the future due to code changes without version updates. Furthermore, the existing release method has issues such as abnormal releases not being repeatable and the returns not being intuitive enough.
By parsing the project object model file, the initial repository is replaced with the target change repository, and the components in the target change repository are used for publishing, ensuring that the stable repository is not affected. At the same time, accurate publishing is achieved by selecting components through the component publishing page instead of command line operations.
This avoids component unavailability issues caused by relying on repository control permissions, ensures the reliability and accuracy of releases, simplifies the operation process, and reduces human error.
Smart Images

Figure CN116185475B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of component publishing, in particular to a two-party package component publishing method and device, electronic equipment and storage medium. BACKGROUND
[0002] In the process of internal software development of a company, some Maven components of the company are provided for internal personnel to use, and the Maven components are uniformly published to a corresponding component repository. The Maven components provided for internal personnel to use are referred to as two-party package components. The publishing of the two-party package components is manually specified in a project, and a packaging command is locally run.
[0003] The component repository includes a stable repository and a snapshot repository. The package version of the stable repository is irreplaceable, and the package version of the snapshot repository is a snapshot version, and the package is replaceable. A large number of open administrator permissions are provided. Since everyone has administrator permissions of the component repository, the stable version of the component can be replaced at will, thereby causing the component to be unavailable in the future due to code changes but no version changes. SUMMARY
[0004] Therefore, embodiments of the present application provide a two-party package component publishing method and device, electronic equipment and storage medium to solve the problem of unavailable components caused by dependence on repository control permissions.
[0005] According to a first aspect, embodiments of the present application provide a two-party package component publishing method, comprising:
[0006] obtaining a branch of a target code repository and description field information of a two-party package component to be published, to obtain a project object model file;
[0007] parsing the project object model file to determine an initial repository in the project object model file;
[0008] replacing the initial repository with a target snapshot repository to determine an updated project object model file;
[0009] determining the two-party package component to be published based on information of the two-party package component to be published;
[0010] publishing the two-party package component to be published to the target snapshot repository according to the updated project object model file.
[0011] The method for publishing two-party package components provided by the embodiment of the application determines an initial warehouse by analyzing a project object model file, and uniformly replaces the initial warehouse with a target change warehouse, and the components in the target change warehouse can be replaced and modified, so that the publishing of the two-party package components does not affect the components in the stable warehouse, and the problem of unavailable components caused by the control authority of the dependent warehouse is avoided.
[0012] In some embodiments, the branch of the target code warehouse and the description field information of the two-party package component to be published are acquired to obtain a project object model file, including:
[0013] In response to a selection operation of the branch of the target code warehouse in the component publishing page, the branch of the target code warehouse is determined;
[0014] The project object model file is determined based on the branch of the target code warehouse;
[0015] The project object model file is analyzed, and the description field information of the two-party package component to be published in the project object model file is read;
[0016] The description field information is written into a field control of the component publishing page to display the description field information.
[0017] The method for publishing two-party package components provided by the embodiment of the application selects a two-party package component to be distributed through a page instead of through a command line, which is simple and less prone to errors for an operator, and can ensure the accurate publishing of the two-party package components.
[0018] In some embodiments, the project object model file is determined based on the branch of the target code warehouse, including:
[0019] An implementation instance under the branch of the target code warehouse is acquired through a calling interface of the target code warehouse;
[0020] The identifier of the project object model file is acquired through the name of the implementation instance;
[0021] The project object model file is acquired through the identifier of the project object model file.
[0022] In some embodiments, the two-party package component to be published is determined based on the information of the two-party package component to be published, including:
[0023] The target reactor corresponding to the two-party package component to be published is determined based on the information of the two-party package component to be published;
[0024] The target reactor is analyzed to extract the identifier of the two-party package component to be published.
[0025] Determine the identification of the two-party package component to be released by using the identification of the two-party package component to be released.
[0026] The method for releasing the two-party package component provided by the embodiment of the present application can ensure the accuracy of the two-party package component to be released by extracting the identification of the two-party package component to be released from the target reactor corresponding to the two-party package component to be released.
[0027] In some embodiments, the target reactor is parsed to extract the identification of the two-party package component to be released, including:
[0028] The target reactor is parsed to obtain a list log containing the identification of the two-party package component to be released.
[0029] The identification of the two-party package component to be released is extracted from the list log based on a regular expression.
[0030] In some embodiments, the two-party package component to be released is released to the target change warehouse according to the updated project object model file, including:
[0031] The identification of the two-party package component to be released is queried from a package detail table to determine whether the two-party package component to be released has been released.
[0032] When the two-party package component to be released has not been released, the two-party package component to be released is released to the target change warehouse based on the updated project object model file.
[0033] The method for releasing the two-party package component provided by the embodiment of the present application performs a duplicate detection process before release, and the duplicate detection process is realized by relying on code control rather than the strategy of the warehouse itself, thereby ensuring the reliability of the release of the two-party package component.
[0034] In some embodiments, the method further includes:
[0035] After the two-party package component to be released is released, the package information of the two-party package component to be released is stored in the package detail table to update the package detail table.
[0036] The method for releasing the two-party package component provided by the embodiment of the present application leaves a trace every time the release is performed, saves a complete two-party package release process, and avoids the loss of related original information.
[0037] According to a second aspect, the embodiment of the present application further provides a two-party package component release device, including:
[0038] An acquisition module is configured to acquire a branch of a target code repository and information of a two-party package component to be released, so as to obtain a project object model file;
[0039] An analysis module is configured to analyze the project object model file and determine an initial repository in the project object model file;
[0040] A replacement module is configured to replace the initial repository with a target change repository and determine an updated project object model file;
[0041] A determination module is configured to determine the two-party package component to be released based on the information of the two-party package component to be released;
[0042] A release module is configured to release the two-party package component to be released to the target change repository according to the updated project object model file.
[0043] According to a third aspect, an electronic device is provided, including a memory and a processor, which are in communication connection with each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the two-party package component release method in the first aspect or any one of the implementation manners of the first aspect.
[0044] According to a fourth aspect, a computer readable storage medium is provided, which stores computer instructions for causing the computer to perform the two-party package component release method in the first aspect or any one of the implementation manners of the first aspect.
[0045] It should be noted that the corresponding beneficial effects of the two-party package component release device, the electronic device and the computer readable storage medium provided by the embodiments of the present application are described above in the description of the beneficial effects of the two-party package component release method, and will not be described here. BRIEF DESCRIPTION OF DRAWINGS
[0046] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings in the following description are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.
[0047] Figure 1 is a flowchart of the two-party package component release method according to the embodiments of the present application;
[0048] Figure 2 is a flowchart of the two-party package component release method according to the embodiments of the present application;
[0049] Figures 3a-3b is a schematic diagram of a component release page according to an embodiment of the present application;
[0050] Figure 4 is a flow chart of a two-party package component release method according to an embodiment of the present application;
[0051] Figure 5 is a flow chart of a two-party package component release method according to an embodiment of the present application;
[0052] Figure 6 is a structural block diagram of a two-party package component release device according to an embodiment of the present application;
[0053] Figure 7 is a hardware structure schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION
[0054] In order to make the objects, technical solutions and advantages of embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.
[0055] In the existing release process, the user manually specifies a release repository in a project and locally runs a packaging command. As described above, since the user has the administrator permission of the component repository, the user can arbitrarily replace the stable components in the stable repository, which can also be referred to as stable components, thereby causing the stable components to be unavailable in the future due to code changes but no version changes. That is, since the component repository is largely open to the administrator permission, and the administrator is used to overwrite the permission of the stable component. Therefore, it is basically impossible to control the permission by using the component repository. At the same time, controlling the permission by using the component repository itself also has two defects: (1) Abnormal release cannot be repeatedly released. For example, four components are released this time, two of which are successfully released, and the third fails. Next time, the previous two components must be upgraded in version, otherwise it will fail. However, in fact, the research and development hopes to upgrade all the components in this release. (2) Abnormal return is not intuitive enough. If the component repository is used for abnormal return, it is a string of English 403 forbidden. This is not friendly enough for the user. And it is difficult to customize the explanation to support the user to take the next step. For example, to upgrade the permission or upgrade the component version. Therefore, the administrator permission is largely open, which causes the above problems.
[0056] Further, the original release warehouse is manually configured in the project, and each project is sent to different target warehouses, so that the same package may exist in different warehouses, which causes unknown reference.
[0057] Based on this, the embodiment of the application provides a release method of a two-party package component, which is used for solving the problem that a stable version component is replaced; further, the method is also used for solving the problem that multiple target warehouses exist; further, the method is used for solving a planned package release process and avoiding local manual package release.
[0058] According to the embodiment of the application, a release method of a two-party package component is provided, and it should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described herein can be executed in an order different from that shown herein.
[0059] In the embodiment, a release method of a two-party package component is provided, which can be used for electronic devices such as mobile terminals, computers and the like, Figure 1 is a flowchart of the release method of the two-party package component according to the embodiment of the application, as shown in Figure 1 The flowchart includes the following steps:
[0060] S11, obtaining a branch of a target code warehouse and description field information of a two-party package component to be released, to obtain a project object model file.
[0061] For one project, there is corresponding program code in each stage of project development, and the program code is managed by a target code warehouse. The branch of the target code warehouse is used to determine a project object model (pom) file, and the pom.xml file saved in an xml extensible markup language format. The file is used to manage: source code, configuration file, information and role of a developer, problem tracking system, organization information, project authorization, url of the project, dependency relationship of the project and the like. A complete pom.xml file is placed in the root directory of the project.
[0062] The description field information of the two-party package component to be released is used to determine the two-party package component to be released, and the description field information includes but is not limited to profile and module. The description field information can be specified by a user, or can be obtained by parsing the pom.xml file, and the like, and the obtaining manner is not limited herein, and is set according to actual needs.
[0063] S12, parsing the project object model file to determine an initial warehouse in the project object model file.
[0064] Maven manages the way of target warehouse to create a new distributionManagement tag under pom.xml in the project root directory, and add repository and snapshotRepository under the tag. Among them, repository is stable warehouse, and snapshot is variable warehouse. (The package version of stable warehouse is not replaceable, and snapshot is snapshot version, and the package is replaceable).
[0065] Specify unique id and url under repository. Among them, id is mainly used to get the configuration of settings.xml on the package machine <servers>Matched. <servers>The username and password are stored in the maven repository. The account password is used for the package release authority verification of the maven repository, and the url is the repository address. In this way, the initial repository in the pom.xml file can be determined.
[0066] S13, replacing the initial repository with the target change repository to determine an updated project object model file.
[0067] The reason for replacement is to converge the package release address and avoid the user-defined package release address, so that the package release can be uniformly managed. The target change repository is a repository used to store the two-party package components, and the initial repository in the pom.xml file is replaced with the target change repository, so that the pom.xml file is updated to obtain the updated project object model file.
[0068] After the pom.xml file of the original project is parsed by gopom.Parse(pomPath) and the corresponding instance is generated, the target change repository DistributionManagement is replaced to obtain the updated project object model file.
[0069] S14, determining the two-party package component to be released based on the information of the two-party package component to be released.
[0070] The information of the two-party package component to be released is equivalent to positioning the two-party package component to be released, and the two-party package component to be released is determined from the code repository.
[0071] S15, releasing the two-party package component to be released to the target change repository according to the updated project object model file.
[0072] The target change repository is recorded in the updated project object model file, and after the two-party package component to be released is determined, the package release interface is called to release the two-party package component to be released to the target change repository.
[0073] The two-party package component release method provided in the embodiment determines the initial repository by parsing the project object model file, and uniformly replaces the initial repository with the target change repository. The components in the target change repository can be replaced and modified, so that the release of the two-party package component does not affect the components in the stable repository, and the problem of unavailable components caused by the control authority of the dependent repository is avoided.
[0074] In the embodiment, a two-party package component release method is provided, which can be used in electronic devices such as mobile terminals, computers, etc. Figure 2 The flowchart of the two-party package component release method according to the embodiment of the application is shown in Figure 2 The flowchart includes the following steps:
[0075] S21, obtain the branch of the target code repository and the description field information of the two-party package component to be released, to obtain the project object model file.
[0076] Specifically, the above S21 includes:
[0077] S211, in response to the selection operation of the branch of the target code repository in the component release page, to determine the branch of the target code repository.
[0078] The component release page is used to provide user interaction processing. The user selects the branch of the target code repository on the component release page, and the branch of the target code repository is determined. For example. Figure 3a And Figure 3b Two schematic diagrams of the component release page are shown, Figure 3a The difference between Figure 3b The difference lies in the display content, Figure 3a Display Profile, Figure 3b Display release module module.
[0079] S212, determine the project object model file based on the branch of the target code repository.
[0080] After selecting the branch of the target code repository, pom.xml can be obtained.
[0081] In some embodiments, the above S212 includes:
[0082] (1) Obtain the implementation instance under the branch of the target code repository through the calling interface of the target code repository.
[0083] (2) Obtain the identifier of the project object model file through the name of the implementation instance.
[0084] (3) Obtain the project object model file through the identifier of the project object model file.
[0085] Through the calling interface GitLabAPI of the target code repository, GitTree under the branch of the target code repository is obtained. GitTree is one of the implementation methods of code repository Git, which is a specific implementation instance for recording and storing file content and unique identifier.
[0086] The unique identifier of pom.xml is obtained by matching pom.xml through GitTree.Name, and the source code file is obtained by calling the GitlabAPI interface according to the Path of the matched GitTree, to obtain the target object model file.
[0087] S213, parse the project object model file and read the description field information of the two-party package component to be released in the project object model file.
[0088] The pom.xml file is parsed using maven-model, a tool for Maven to parse pom.xml files. By generating a model object from the parsed pom.xml, the description fields "modules" and "profile" of the components to be released in the third-party package can be obtained.
[0089] The purpose of Profiles is to optimize the user experience for developers specifying activation parameters. Parsing Profiles avoids the tedious manual filling by developers and prevents errors caused by mis-entry. Reason: Currently, developers use Profiles to customize configuration parameters. It is primarily used to differentiate environments such as: TEST (development environment), QUA (testing environment), PRE (pre-release environment), and PROD (production environment). It builds based on different environments, and different environments can use placeholders to release different versions of the package. For example, the version (Version) could be: 1.0.0-TEST or 1.0.0-QUA, etc.
[0090] The purpose of a Module is similar to that of a Profile. The main purpose of a Module is to address the common pitfalls of developers working on projects that may be divided into multiple sub-modules, such as Modules A, B, and C. However, the SDK that actually provides external capabilities may only be provided by Module A, thus providing a quick selection function.
[0091] S214. Write the description field information into the field control of the component's publishing page to display the description field information.
[0092] After obtaining the description field information, it is written back to the field control on the component publishing page, so that the description field information is displayed on the component publishing page.
[0093] S22, parse the project object model file to determine the initial repository in the project object model file.
[0094] Please see details Figure 1 S12 of the illustrated embodiment will not be described again here.
[0095] S23, replace the initial repository with the target change repository, and determine the updated project object model file.
[0096] Please see details Figure 1 S13 of the illustrated embodiment will not be described again here.
[0097] S24, determine the third-party package component to be released based on the information of the third-party package component to be released.
[0098] Please see details Figure 1 S14 of the illustrated embodiment will not be described again here.
[0099] S25, publishing the to-be-published two-party package component to the target change warehouse according to the updated project object model file.
[0100] For details, please refer to Figure 1 S15 of the embodiment shown will not be repeated here.
[0101] The two-party package component publishing method provided in the embodiment is realized by selecting a to-be-distributed two-party package component through a page instead of a command line, which is relatively simple for an operator to operate and is less prone to errors, and can ensure accurate publishing of the two-party package component.
[0102] A two-party package component publishing method is provided in the embodiment and can be used for electronic devices such as mobile terminals, computers, and the like. Figure 4 The flowchart of the two-party package component publishing method according to the embodiment of the present application is shown in Figure 4 The flowchart includes the following steps:
[0103] S31, obtaining a branch of a target code warehouse and description field information of a to-be-published two-party package component to obtain a project object model file.
[0104] For details, please refer to Figure 2 S21 of the embodiment shown will not be repeated here.
[0105] S32, parsing the project object model file to determine an initial warehouse in the project object model file.
[0106] For details, please refer to Figure 1 S12 of the embodiment shown will not be repeated here.
[0107] S33, replacing the initial warehouse with a target change warehouse to determine an updated project object model file.
[0108] For details, please refer to Figure 1 S13 of the embodiment shown will not be repeated here.
[0109] S34, determining a to-be-published two-party package component based on information of the to-be-published two-party package component.
[0110] Specifically, the above S34 includes:
[0111] S341, determining a target reactor corresponding to the to-be-published two-party package component based on information of the to-be-published two-party package component.
[0112] The information profile and the module initialization command of the to-be-distributed two-party package component are used to determine the target reactor corresponding to the to-be-published two-party package component.
[0113] S342, parse the target reactor to extract the identifier of the two-party package component to be released.
[0114] The mvn validate command is run through docker to parse the target reactor to extract the identifier of the two-party package component to be released. The identifier of the two-party package component to be released includes module, groupId, artifactId, and version, wherein module is the module name of maven; groupId: one of the three coordinates in the maven technical system, Maven mainly confirms the uniqueness of the two-party package through groupId, artifactId, and version. GroupId: generally the reverse of the company domain name; artifactId: one of the three coordinates, generally used for the description of a technical artifact of a certain technology, for example, telot-ci-web is the API layer of the automated test component; version: one of the three coordinates, generally used for unique version control, mainly used for component evolution and upgrade.
[0115] In some embodiments, the above S342 includes:
[0116] (1) parse the target reactor to obtain a manifest log containing the identifier of the two-party package component to be released.
[0117] (2) extract the identifier of the two-party package component to be released from the manifest log based on a regular expression.
[0118] The mvn validate command is run through docker to parse a manifest log containing module, groupId, artifactId, and version. The log is saved as a file to prepare for the subsequent analysis and duplication detection. The module, groupId, artifactId, and version are extracted from the manifest log through a regular expression.
[0119] S343, determine the two-party package component to be released using the identifier of the two-party package component to be released.
[0120] After determining the identifier of the two-party package component to be released, the identifier can be used to locate the two-party package component to be released in the target code repository.
[0121] S35, release the two-party package component to be released to the target change repository according to the updated project object model file.
[0122] Specifically, the above S35 includes:
[0123] S351, query the package details table based on the identifier of the two-party package component to be released to determine whether the two-party package component to be released has been released.
[0124] According to the groupId, artifactId and version of the to-be-released two-party package component, the package release details table is queried to determine whether the to-be-released two-party package component has a record in the package release details table. If there is a record, it indicates that the to-be-released two-party package component has been released, and if it has been released, it does not need to be released again.
[0125] S352, when the to-be-released two-party package component is not released, the to-be-released two-party package component is released to the target change repository based on the updated project object model file.
[0126] If the to-be-released two-party package component has not been released, a package release command mvn clean deploy is generated, and a docker run is performed through the original docker container to release the to-be-released two-party package component to the target change repository based on the updated project object model file.
[0127] The two-party package component release method provided in the embodiment extracts the identification of the to-be-released two-party package component corresponding to the target reactor, which can ensure the accuracy of the to-be-released two-party package component finally determined. The duplicate detection processing is performed before release, and the duplicate detection processing is realized by relying on code control rather than the strategy of the repository itself, which ensures the reliability of the two-party package component release.
[0128] In some embodiments, the above method further comprises: after the to-be-released two-party package component is released, storing the package release information of the to-be-released two-party package component in the package release details table to update the package release details table. Specifically, the jobId and package information of this package release are generated to request a body, and the backend interface is called to save the package release record. Wherein, JobId is the unique identification of GitLab-Runner, which is used to identify the unique identification of the package release task; the package information is module, groupId, artifactId and version. For each package release, a trace is left to save the complete two-party package release process and avoid loss of related original information.
[0129] As a specific application example of the embodiment of the application, Figure 5 The release flowchart of the two-party package component is shown, the user inputs the application, profile and module, the front-end application passes the task parameters to be executed (i.e., profile and module), and the back-end application triggers GitLab. The initial repository is replaced through the GitLab tool. The reactor is parsed to determine whether the to-be-released two-party package component has been released, if not, the package release command is run; if it has been released, the release fails. After the release is executed, the local package release record is recorded to update the package release details table. Based on this, the user can reference the two-party package component released this time in the project.
[0130] There is also provided in the present embodiments a publishing device for a two-party package assembly, which is used to implement the above-mentioned embodiments and preferred embodiments, and the description of which has been made above. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.
[0131] The present embodiments provide a publishing device for a two-party package assembly, as shown in Figure 6 comprises:
[0132] An obtaining module 41 is configured to obtain a branch of a target code repository and information of a two-party package assembly to be published, so as to obtain a project object model file;
[0133] An analyzing module 42 is configured to analyze the project object model file, and determine an initial repository in the project object model file;
[0134] A replacing module 43 is configured to replace the initial repository with a target change repository, and determine an updated project object model file;
[0135] A determining module 44 is configured to determine the two-party package assembly to be published based on the information of the two-party package assembly to be published;
[0136] A publishing module 45 is configured to publish the two-party package assembly to be published to the target change repository according to the updated project object model file.
[0137] In some embodiments, the obtaining module 41 comprises:
[0138] A responding unit is configured to respond to a selection operation of the branch of the target code repository in a component publishing page, so as to determine the branch of the target code repository;
[0139] A first determining unit is configured to determine the project object model file based on the branch of the target code repository;
[0140] A first analyzing unit is configured to analyze the project object model file, and read description field information of a two-party package assembly to be published in the project object model file;
[0141] A writing unit is configured to write the description field information into a field control of the component publishing page, so as to display the description field information.
[0142] In some embodiments, the first determining unit comprises:
[0143] The first obtaining subunit is configured to obtain, through an invoking interface of the target code warehouse, an implementation instance under a branch of the target code warehouse.
[0144] The second obtaining subunit is configured to obtain the identification of the project object model file through the name of the implementation instance.
[0145] The third obtaining subunit is configured to obtain the project object model file through the identification of the project object model file.
[0146] In some embodiments, the determining module 44 comprises:
[0147] The second determining unit is configured to determine, based on the information of the to-be-released two-party package component, a target reactor corresponding to the to-be-released two-party package component.
[0148] The second analyzing unit is configured to analyze the target reactor to extract the identification of the to-be-released two-party package component.
[0149] The third determining unit is configured to determine the to-be-released two-party package component by using the identification of the to-be-released two-party package component.
[0150] In some embodiments, the second analyzing unit comprises:
[0151] The analyzing subunit is configured to analyze the target reactor to obtain a manifest log containing the identification of the to-be-released two-party package component.
[0152] The extracting subunit is configured to extract the identification of the to-be-released two-party package component from the manifest log based on a regular expression.
[0153] In some embodiments, the releasing module 45 comprises:
[0154] The querying unit is configured to query a package detail table based on the identification of the to-be-released two-party package component to determine whether the to-be-released two-party package component has been released.
[0155] The releasing unit is configured to release the to-be-released two-party package component to the target change warehouse based on the updated project object model file when the to-be-released two-party package component has not been released.
[0156] In some embodiments, the apparatus further comprises:
[0157] The storage module is configured to store, after the to-be-released two-party package component is released, package information of the to-be-released two-party package component into the package detail table to update the package detail table.
[0158] In this embodiment, the device for issuing second-party package components is presented in the form of functional units. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above-mentioned functions.
[0159] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.
[0160] This invention also provides an electronic device having the above-described features. Figure 6 The device for distributing two-way package components is shown.
[0161] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention, such as... Figure 7 As shown, the electronic device may include: at least one processor 51, such as a CPU (Central Processing Unit), at least one communication interface 53, memory 54, and at least one communication bus 52. The communication bus 52 is used to enable communication between these components. The communication interface 53 may include a display screen or a keyboard; optionally, the communication interface 53 may also include a standard wired interface or a wireless interface. The memory 54 may be high-speed RAM (Random Access Memory) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 54 may also be at least one storage device located remotely from the aforementioned processor 51. The processor 51 may be combined with... Figure 6 The described apparatus has an application program stored in memory 54, and the processor 51 calls the program code stored in memory 54 to perform any of the above method steps.
[0162] The communication bus 52 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 52 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 7 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0163] The memory 54 can include a volatile memory, such as a random-access memory (RAM), and / or can include a non-volatile memory, such as a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD). The memory 54 can also include a combination of the above-mentioned types of memories.
[0164] The processor 51 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.
[0165] The processor 51 can further include a hardware chip. The hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0166] Optionally, the memory 54 is further configured to store program instructions. The processor 51 can invoke the program instructions to implement the method for publishing a two-party package component as shown in any of the embodiments of the present application.
[0167] The embodiment of the present application further provides a non-transitory computer storage medium, which stores computer executable instructions, and the computer executable instructions can execute the method for publishing the two-party package component in any method embodiment described above. The storage medium can be a magnetic disk, an optical disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a Flash Memory, a Hard Disk Drive (HDD) or a Solid-State Drive (SSD), etc. The storage medium can also include a combination of the above-mentioned types of memories.
[0168] Although the embodiments of the present application are described in conjunction with the drawings, various modifications and changes can be made by those skilled in the art without departing from the spirit and scope of the present application, and such modifications and changes are intended to fall within the scope of the appended claims.< / servers> < / servers>
Claims
1. A method for publishing a third-party package component, characterized in that, include: Obtain the branch information of the target code repository and the description field information of the third-party package components to be released, in order to obtain the project object model file, including: In response to the selection operation of the branch of the target code repository mentioned on the component release page, the branch of the target code repository is determined; The project object model file is determined based on the branch of the target code repository; The project object model file is parsed to read the description field information of the third-party package component to be released in the project object model file; Write the description field information into the field control of the component publishing page to display the description field information; The project object model file is parsed to determine the initial repository in the project object model file; Replace the initial repository with the target modified repository and determine the updated project object model file; Determining the second-party package component to be released based on its information includes: Based on the information of the second-party package component to be released, determine the target reactor corresponding to the second-party package component to be released; The target reactor is parsed to extract the identifier of the third-party package component to be released; The third-party package component to be released is identified using its identifier; The third-party package component to be released is published to the target change repository based on the updated project object model file.
2. The method according to claim 1, characterized in that, The step of determining the project object model file based on the branch of the target code repository includes: By calling the interface of the target code repository, obtain the implementation instance under the branch of the target code repository; The identifier of the project object model file is obtained by using the name of the implementation instance; The project object model file is obtained by identifying the project object model file.
3. The method according to claim 1, characterized in that, The step of parsing the target reactor to extract the identifier of the third-party package component to be released includes: Parse the target reactor to obtain an inventory log containing the identifiers of the third-party package components to be released; The identifier of the third-party package component to be released is extracted from the manifest log based on regular expressions.
4. The method according to claim 1, characterized in that, The step of publishing the third-party package component to be released to the target change repository according to the updated project object model file includes: Based on the identifier of the second-party package component to be released, query the package delivery details table to determine whether the second-party package component to be released has already been released; When the third-party package component to be released has not been released, the third-party package component to be released is released to the target change repository based on the updated project object model file.
5. The method according to claim 4, characterized in that, The method further includes: After the third-party package component to be released is released, the packet sending information of the third-party package component to be released is stored in the packet sending details table to update the packet sending details table.
6. A dispensing device for a two-way package component, characterized in that, include: The acquisition module is used to obtain the branches of the target code repository and the description field information of the third-party package components to be released, in order to obtain the project object model file, including: In response to the selection operation of the branch of the target code repository mentioned on the component release page, the branch of the target code repository is determined; The project object model file is determined based on the branch of the target code repository; The project object model file is parsed to read the description field information of the third-party package component to be released in the project object model file; Write the description field information into the field control of the component publishing page to display the description field information; The parsing module is used to parse the project object model file and determine the initial repository in the project object model file; The replacement module is used to replace the initial repository with the target modified repository and determine the updated project object model file; The determining module is used to determine the second-party package component to be published based on the information of the component to be published, including: Based on the information of the second-party package component to be released, determine the target reactor corresponding to the second-party package component to be released; The target reactor is parsed to extract the identifier of the third-party package component to be released; The third-party package component to be released is identified using its identifier; The publishing module is used to publish the third-party package component to be published to the target change repository based on the updated project object model file.
7. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the method for publishing the second-party package component as described in any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the method of publishing the second-party package component according to any one of claims 1-5.