Application dependency release method and device, equipment and storage medium

Abstract

The invention relates to an application dependency release method and device, equipment and a storage medium. According to the main technical scheme, the method comprises the steps of obtaining a code change file path of a change code in an application program, and according to the code change file path, if it is determined that code change exists in a target service module of the application program, obtaining an associated sub-module with code change in a Maven item to which the target service module belongs, according to the configuration information of the target service module and the configuration information of the associated sub-module, and the module version numbers of the target service module and the associated sub-module, judging whether the target service module and the associated sub-module are uploaded to the Maven warehouse or not according to the configuration information of the target service module and the associated sub-module, and according to the judgment result and the module version numbers of the target service module and the associated sub-module, determining whether the target service module is uploaded to the Maven warehouse. According to the method, the target business module and the associated sub-module are constructed to perform dependency release, whether the change code needs to be uploaded to the module of the Maven warehouse or not can be judged, and the related module is automatically uploaded, so that the dependency of manual operation is reduced, the software development and deployment efficiency is improved, and the risk of generating problems is reduced.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an application dependency publishing method, apparatus, device, and storage medium. Background Art

[0002] Software projects developed based on the Java language basically use Maven for project dependency management, and declare the version of the dependent code library in the Project Object Model (POM) file in the project. Maven supports multi-module projects, allowing a large project to be split into multiple sub-modules. Each sub-module can be built and tested independently and can share common dependencies and configurations. In a multi-module project, each sub-module has its own pom.xml file to define its own dependencies and build configuration. For example, if the sub-module is used to define server-side logic, then the sub-module is a service module; if the sub-module is used to define an interface, then the sub-module is an interface module.

[0003] When a project interface changes, developers on the service provider side need to write code in the corresponding interface declaration module and upload the latest version of the module to the Maven repository using the mvn deploy command. Simultaneously, developers on the service caller side need to modify the module dependency declaration in the Maven pom.xml file of the relevant project based on the new module version number provided by the service provider. This entire process is manual, and failure to update the latest version in a timely manner can lead to code compilation errors or system failures, reducing the efficiency and stability of the automated release process. Summary of the Invention

[0004] Based on this, the present application provides an application-dependent publishing method, apparatus, device and storage medium to solve the technical problem that the latest version cannot be updated in time, causing code compilation errors or system failures, thereby reducing the work efficiency of the automatic publishing process and the system stability.

[0005] In a first aspect, a method for publishing application dependencies is provided, the method comprising: obtaining a code change file path of a code change in the application, and determining, based on the code change file path, whether a target business module of the application has a code change;

[0006] If the target business module of the application has code changes, obtain the associated submodules with code changes in the Maven project to which the target business module belongs, as well as the module version numbers of the target business module and the associated submodules;

[0007] According to the configuration information of the target business module and associated submodules, determine whether the target business module and associated submodules are uploaded to the Maven warehouse and obtain the judgment result;

[0008] According to the judgment result and the module version numbers of the target business module and associated submodules, the target business module and associated submodules are built for dependency release.

[0009] According to one achievable method in an embodiment of the present application, determining whether a code change exists in a target business module of an application program based on a code change file path includes:

[0010] Get the first-level directory of the code change file path and determine whether there is a pom.xml file in the first-level directory;

[0011] If a pom.xml file exists in the first-level directory, confirm that there are code changes in the target business module of the application;

[0012] If the pom.xml file does not exist in the first-level directory, make sure that no code changes have occurred in the target business module of the application.

[0013] According to an achievable method in an embodiment of the present application, based on the judgment result and the module version numbers of the target business module and the associated submodules, the target business module and the associated submodules are constructed for dependency publishing, including:

[0014] If the judgment result is that the target business module and the associated submodules are uploaded to the Maven repository, the module version numbers of the target business module and the associated submodules are judged based on their module version numbers to determine whether they are official version numbers, and the version number judgment result is obtained;

[0015] Based on the version number judgment result, the target business module and associated sub-modules are built for dependency release.

[0016] According to an achievable method in an embodiment of the present application, based on the version number judgment result, the target business module and associated submodules are constructed for dependency release, including:

[0017] If the version number judgment result shows that the module version number of the target business module and the associated submodule is the official version number, call the Nexus warehouse to query whether the module version number of the target business module and the associated submodule already exists;

[0018] If the module version number of the target business module and the associated submodule does not exist, call the first release process configured in Jenkins to build the target business module and the associated submodule for dependency release.

[0019] According to one achievable method in an embodiment of the present application, the method further includes:

[0020] If the version number judgment result is that the module version number of the target business module and the associated submodule is an informal version number, the first release process configured in Jenkins is called to build the target business module and the associated submodule for dependency release.

[0021] According to an achievable method in an embodiment of the present application, based on the judgment result and the module version numbers of the target business module and the associated submodules, the target business module and the associated submodules are constructed for dependency publishing, including:

[0022] If the judgment result is that the target business module and associated submodules do not need to be uploaded to the Maven repository, the second release process configured in Jenkins is called to build the target business module and associated submodules for dependency release.

[0023] According to one achievable method in an embodiment of the present application, the method further includes:

[0024] If there are no other modules with code changes in the Maven project to which the target business module belongs, call the second release process configured in Jenkins to build the target business module for dependency release.

[0025] In a second aspect, an application dependency publishing device is provided, the device comprising:

[0026] An acquisition module is used to obtain the code change file path of the changed code in the application, and determine whether there is a code change in the target business module of the application based on the code change file path;

[0027] Get module, also used to obtain the associated submodules with code changes in the Maven project to which the target business module belongs, as well as the module version numbers of the target business module and the associated submodules if there are code changes in the target business module of the application;

[0028] The judgment module is used to judge whether the target business module and the associated submodules are uploaded to the Maven warehouse according to the configuration information of the target business module and the associated submodules, and obtain the judgment result;

[0029] The release module is used to build the target business module and the associated submodules for dependency release based on the judgment result and the module version numbers of the target business module and the associated submodules.

[0030] According to a third aspect, a computer device is provided, comprising:

[0031] at least one processor; and

[0032] a memory communicatively connected to the at least one processor; wherein,

[0033] The memory stores computer instructions that can be executed by the at least one processor, and the computer instructions are executed by the at least one processor to enable the at least one processor to perform the method involved in the first aspect above.

[0034] In a fourth aspect, a computer-readable storage medium is provided, on which computer instructions are stored, characterized in that the computer instructions are used to enable a computer to execute the method involved in the above-mentioned first aspect.

[0035] According to the technical content provided in the embodiments of the present application, the code change file path of the changed code in the application is obtained, and based on the code change file path, it is determined whether there is a code change in the target business module of the application; if there is a code change in the target business module of the application, the associated sub-module with the code change in the Maven project to which the target business module belongs, as well as the module version numbers of the target business module and the associated sub-modules are obtained; based on the configuration information of the target business module and the associated sub-modules, it is determined whether the target business module and the associated sub-modules have been uploaded to the Maven warehouse, and a judgment result is obtained; based on the judgment result and the module version numbers of the target business module and the associated sub-modules, the target business module and the associated sub-modules are constructed for dependency release, which can determine whether the changed code needs to be uploaded to the module of the Maven warehouse, and automatically upload the relevant modules, thereby reducing the steps of manually executing commands by the original dependent developers, improving the efficiency of the software development and deployment process, and reducing the risk of problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 An application environment diagram of an application dependency publishing method in one embodiment;

[0037] Figure 2 A flowchart of a method for publishing application dependencies in one embodiment is shown;

[0038] Figure 3 A structural block diagram of an application dependency publishing device in one embodiment;

[0039] Figure 4 Schematic diagram of the structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0040] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0041] To facilitate understanding of the execution process of the application dependency publishing method provided by this application, the tools involved are introduced below:

[0042] Maven is a project management and build tool focused on building and dependency management for Java projects. Maven provides a complete lifecycle framework, including cleanup, compilation, testing, packaging, and deployment phases. Maven uses a POM file (pom.xml) to define a project's configuration and dependencies. Developers can declare the required dependencies and their versions in the POM file. Maven automatically downloads and installs these dependencies based on these declarations, eliminating the complexity of manually managing dependencies.

[0043] Git is a distributed version control system used to efficiently manage the version history of a project's source code and other files. GitLab provides version control features based on Git technology. Users can create code repositories, submit code, and view historical versions on GitLab.

[0044] Jenkins is an open-source continuous integration tool that integrates with code version control systems, monitors changes in code repositories, and automatically triggers build processes. It also supports multiple code development branches and separate build tasks for different runtime environments, providing build status, test reports, and build results.

[0045] Nexus is a Maven repository management software, mostly used to build private Maven repositories within companies, store and manage internally developed software components, and can act as a proxy for external repositories such as the Maven Central Repository, speeding up the download of Maven dependency libraries and reducing dependence on external networks.

[0046] For ease of understanding, the system to which this application is applicable is first described. The application dependency publishing method provided in this application can be applied to Figure 1 In the system architecture shown. Among them, the terminal 110 communicates with the server 120 through the network. The terminal 110 obtains the code change file path of the changed code in the application, and based on the code change file path, determines whether there is a code change in the target business module of the application. If there is a code change in the target business module of the application, the terminal 110 obtains the associated submodule with the code change in the Maven project to which the target business module belongs, as well as the module version number of the target business module and the associated submodule. Based on the configuration information of the target business module and the associated submodule, it is determined whether the target business module and the associated submodule have been uploaded to the Maven repository, and a judgment result is obtained. Based on the judgment result and the module version number of the target business module and the associated submodule, the target business module and the associated submodule are constructed for dependency release. Among them, the terminal 110 can be, but is not limited to, various personal computers, laptops, smart phones and tablets, and the server 120 can be implemented as an independent server or a server cluster consisting of multiple servers.

[0047] Figure 2 A flowchart of an application dependency publishing method provided in an embodiment of the present application, which can be performed as follows Figure 1 The terminal 110 in the system shown executes. Figure 2 As shown, the method may include the following steps:

[0048] S210 , obtaining a code change file path of the changed code in the application, and judging whether there is a code change in the target business module of the application according to the code change file path.

[0049] When a user submits code to GitLab, Git records all modified files and their paths. The modified file paths are retrieved through the webhook callback function configured in GitLab. By calling the modified file paths, you can determine which files were added, modified, or deleted in this code submission.

[0050] The target business module is a business module whose code is changed to meet business needs. Whether the target business module of the application has code changes is determined based on whether there is a pom.xml file in the first-level directory of the code change file path.

[0051] S220: If there is a code change in the target business module of the application, obtain the associated submodules with code changes in the Maven project to which the target business module belongs, as well as the module version numbers of the target business module and the associated submodules.

[0052] In a multi-module project, code changes in the target business module of the application may affect other modules. By checking whether there are code changes in other modules, you can more comprehensively understand the scope of the change and develop a more appropriate build and deployment strategy.

[0053] Based on the code change information of the target business module, determine whether other modules in the Maven project to which the target business module belongs also have code changes. Modules with code changes are associated items that the application release build process depends on, and are called associated submodules.

[0054] Obtain the module version numbers of the target business module and associated submodules to facilitate subsequent build and release operations.

[0055] S230: According to the configuration information of the target business module and the associated submodules, determine whether the target business module and the associated submodules are uploaded to the Maven repository, and obtain a determination result.

[0056] The configuration information of the target business module and associated submodules can include pom.xml configuration parameters, dependency management, build plugin configuration, project property definitions, etc. Among them, pom.xml configuration parameters include module coordinates, which are used to uniquely identify the module and distinguish module types. Maven project modules can include service modules and interface modules.

[0057] According to the configuration information of the target business module and associated sub-modules, determine the type of the target business module and associated sub-modules. If its type is a service module, the judgment result is that the target business module and associated sub-modules do not need to be uploaded to the Maven warehouse; if its type is an interface module, the judgment result is that the target business module and associated sub-modules are uploaded to the Maven warehouse.

[0058] S240 , constructing the target business module and the associated submodules for dependency publishing according to the judgment result and the module version numbers of the target business module and the associated submodules.

[0059] If the judgment result is that the target business module and associated submodules do not need to be uploaded to the Maven repository, the relevant release process is directly called to build the target business module and associated submodules for dependency release.

[0060] If the judgment result is that the target business module and associated sub-modules are uploaded to the Maven repository, it is necessary to first determine whether the version number defined by the target business module and associated sub-modules is the official version number. For modules with official version numbers, it is necessary to determine whether the module already exists. Based on the judgment result, the relevant release process is called to build the target business module and associated sub-modules for dependency release.

[0061] It can be seen that the embodiment of the present application obtains the code change file path of the changed code in the application, and judges whether there is a code change in the target business module of the application based on the code change file path. If there is a code change in the target business module of the application, the associated sub-module with the code change in the Maven project to which the target business module belongs, as well as the module version number of the target business module and the associated sub-module are obtained. According to the configuration information of the target business module and the associated sub-module, it is judged whether the target business module and the associated sub-module are uploaded to the Maven warehouse to obtain the judgment result. According to the judgment result and the module version number of the target business module and the associated sub-module, the target business module and the associated sub-module are constructed for dependency release. It can judge whether the changed code needs to be uploaded to the module of the Maven warehouse, and automatically upload the relevant modules, reducing the steps of manually executing commands by the original dependent developers, improving the efficiency of the software development and deployment process, and reducing the risk of problems.

[0062] As an achievable method, judging whether there are code changes in the target business module of the application based on the code change file path includes:

[0063] Get the first-level directory of the code change file path and determine whether there is a pom.xml file in the first-level directory;

[0064] If a pom.xml file exists in the first-level directory, confirm that there are code changes in the target business module of the application;

[0065] If the pom.xml file does not exist in the first-level directory, make sure that no code changes have occurred in the target business module of the application.

[0066] If there are code changes in the target business module of the application, record the code changes in the target business module and record the version number defined in pom.xml and the Git commit version number of the target business module at the time of this submission.

[0067] As an achievable method, based on the judgment result and the module version numbers of the target business module and associated submodules, the target business module and associated submodules are constructed for dependency release, including:

[0068] If the judgment result is that the target business module and the associated submodules are uploaded to the Maven repository, the module version numbers of the target business module and the associated submodules are judged based on their module version numbers to determine whether they are official version numbers, and the version number judgment result is obtained;

[0069] Based on the version number judgment result, the target business module and associated sub-modules are built for dependency release.

[0070] If the judgment result is that the target business module and associated submodules are uploaded to the Maven warehouse, determine whether the module version number exists in the Nexus warehouse. If it exists, there is no need to build and upload again. If not, build and upload.

[0071] The official version number is usually stored in the Nexus repository. Before determining whether the module with the version number exists in the Nexus repository, first determine whether the module version number is the official version number. If not, there is no need to determine whether the module version number exists in the Nexus repository.

[0072] The tail field of the version number is used as a preset field to determine whether the module version number is an official version number. The preset field is -SNAPSHOT.

[0073] If the module version number does not end with "-SNAPSHOT", the version number judgment result is that the module version number of the target business module and associated sub-modules is the official version number; if the module version number ends with "-SNAPSHOT", the version number judgment result is that the module version number of the target business module and associated sub-modules is the unofficial version number.

[0074] Specifically, based on the version number judgment result, the target business module and associated submodules are built for dependency release, including:

[0075] If the version number judgment result shows that the module version number of the target business module and the associated submodule is the official version number, call the Nexus warehouse to query whether the module version number of the target business module and the associated submodule already exists;

[0076] If the module version number of the target business module and the associated submodule does not exist, call the first release process configured in Jenkins to build the target business module and the associated submodule for dependency release.

[0077] If the version number judgment result is that the module version number of the target business module and the associated submodule is an informal version number, the first release process configured in Jenkins is called to build the target business module and the associated submodule for dependency release.

[0078] Among them, the specific process of calling the first release process configured by Jenkins to build the target business module and associated sub-modules for dependent release includes: pulling the engineering code of the target business module and associated sub-modules from the Git repository, and switching the working directory of Jenkins when executing the pipeline script to the directory where the engineering code is located, so that subsequent construction, testing and other steps can be executed correctly. According to the calling parameter <array of module names to be uploaded>, assemble the Maven command parameters and execute the Maven command to build: mvn deploy-pl <array of module names to be uploaded>, mvn deploy is used to build and upload the specified module to the Nexus repository. The -pl parameter is used to specify the module to be built. Upload the jar package to the nexus repository and ensure that the correct Nexus repository information is configured in the Maven settings.xml file so that the mvn deploy command can successfully upload the built JAR package.

[0079] As an achievable method, based on the judgment result and the module version numbers of the target business module and associated submodules, the target business module and associated submodules are constructed for dependency release, including:

[0080] If the judgment result is that the target business module and associated submodules do not need to be uploaded to the Maven repository, the second release process configured in Jenkins is called to build the target business module and associated submodules for dependency release.

[0081] In addition, the method includes:

[0082] If there are no other modules with code changes in the Maven project to which the target business module belongs, call the second release process configured in Jenkins to build the target business module for dependency release.

[0083] The specific process for invoking the second release process configured in Jenkins to build the target business module for dependency release includes: pulling the target business module's project code from the Git repository, switching the Jenkins working directory when executing the pipeline script to the project code directory, and ensuring that subsequent build commands are executed in the correct directory. In the pipeline script, variables are used to receive parameters, and Maven commands are assembled by calling the parameter <business module>. The Maven command "mvn package -pl <business module>" is executed to build and deploy the target business module.

[0084] By analyzing the code submission records of R&D personnel, we can obtain the related items that the application release and build process depends on, and automatically perform corresponding build and release operations on the related items, reducing the offline operation and communication costs of R&D personnel and improving the work efficiency of IT system continuous integration and automatic release processes.

[0085] It should be understood that although Figure 2 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this application, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Figure 2 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0086] Figure 3 This is a schematic diagram of the structure of an application-dependent publishing device provided in an embodiment of the present application. The device can be set at Figure 1 The terminal 110 in the system shown is used to perform the following operations: Figure 2 The method flow shown in . Figure 3 As shown, the device may include: an acquisition module 310, a judgment module 320 and a publishing module 330. The main functions of each component module are as follows:

[0087] An acquisition module 310 is configured to acquire a code change file path of a changed code in an application, and determine, based on the code change file path, whether a code change exists in a target business module of the application;

[0088] The acquisition module 310 is further configured to, if there is a code change in the target business module of the application, acquire the associated submodules in the Maven project to which the target business module belongs that have code changes, as well as the module version numbers of the target business module and the associated submodules;

[0089] A judgment module 320 is configured to judge whether the target business module and the associated submodule are uploaded to a Maven repository based on the configuration information of the target business module and the associated submodule, and obtain a judgment result;

[0090] The publishing module 330 is configured to construct the target business module and the associated submodules for dependency publishing according to the judgment result and the module version numbers of the target business module and the associated submodules.

[0091] As an implementable method, the acquisition module 310 is specifically used to: obtain the first-level directory of the code change file path, and determine whether there is a pom.xml file under the first-level directory; if there is a pom.xml file under the first-level directory, determine that there is a code change in the target business module of the application; if there is no pom.xml file under the first-level directory, determine that there is no code change in the target business module of the application.

[0092] As an implementable method, the publishing module 330 is specifically used to: if the judgment result is that the target business module and the associated sub-module are uploaded to the Maven warehouse, judge whether the module version number of the target business module and the associated sub-module is the official version number according to the module version number of the target business module and the associated sub-module, and obtain the version number judgment result; based on the version number judgment result, build the target business module and the associated sub-module for dependency release.

[0093] As an implementable method, the release module 330 is specifically used to: if the version number judgment result is that the module version number of the target business module and the associated sub-module is the official version number, call the Nexus warehouse to query whether the module version number of the target business module and the associated sub-module already exists; if the module version number of the target business module and the associated sub-module does not exist, call the first release process configured in Jenkins to build the target business module and the associated sub-module for dependent release.

[0094] As an implementable method, the release module 330 is also used to: if the version number judgment result is that the module version number of the target business module and the associated sub-module is an informal version number, call the first release process configured in Jenkins to build the target business module and the associated sub-module for dependent release.

[0095] As an achievable method, the publishing module 330 is specifically used to: if the judgment result is that the target business module and the associated sub-module do not need to be uploaded to the Maven warehouse, call the second publishing process configured in Jenkins to build the target business module and the associated sub-module for dependency publishing.

[0096] As an implementable method, the publishing module 330 is further used to: if there are no other modules with code changes in the Maven project to which the target business module belongs, call the second publishing process configured in Jenkins to build the target business module for dependency publishing.

[0097] The same or similar parts between the above embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0098] It should be noted that the embodiments of this application may involve the use of user data. In actual applications, user-specific personal data can be used in the scheme described herein within the scope permitted by applicable laws and regulations, provided that it complies with the applicable laws and regulations of the country where the user is located (for example, with the user's explicit consent, effective notification to the user, and explicit authorization by the user).

[0099] According to an embodiment of the present application, the present application also provides a computer device and a computer-readable storage medium.

[0100] like Figure 4 , which is a block diagram of a computer device according to an embodiment of the present application. The term "computer device" is intended to refer to various forms of digital computers or mobile devices. Digital computers may include desktop computers, portable computers, workstations, personal digital assistants, servers, mainframe computers, and other suitable computers. Mobile devices may include tablet computers, smartphones, wearable devices, and the like.

[0101] like Figure 4As shown, computer device 400 includes a computing unit 401, ROM 402, RAM 403, a bus 404, and an input / output (I / O) interface 405. Computing unit 401, ROM 402, and RAM 403 are connected to each other via bus 404. Input / output (I / O) interface 405 is also connected to bus 404.

[0102] The computing unit 401 can perform various processes in the method embodiment of the present application according to the computer instructions stored in the read-only memory (ROM) 402 or the computer instructions loaded from the storage unit 408 into the random access memory (RAM) 403. The computing unit 401 can be various general and / or special processing components with processing and computing capabilities. The computing unit 401 may include but is not limited to a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units for running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. In some embodiments, the method provided in the embodiment of the present application can be implemented as a computer software program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 408.

[0103] The RAM 403 may also store various programs and data required for the operation of the computer device 400. Part or all of the computer program may be loaded and / or installed on the computer device 400 via the ROM 402 and / or the communication unit 409.

[0104] The input unit 406, output unit 407, storage unit 408, and communication unit 409 in the computer device 400 can be connected to the I / O interface 405. The input unit 406 can be, for example, a keyboard, a mouse, a touch screen, a microphone, etc.; the output unit 407 can be, for example, a display, a speaker, an indicator light, etc. The computer device 400 can exchange information and data with other devices via the communication unit 409.

[0105] It should be noted that the device may also include other components necessary for normal operation, or may only include components necessary for implementing the solution of this application, rather than all the components shown in the figure.

[0106] Various implementations of the systems and techniques described herein can be realized in digital electronic circuitry, integrated circuitry, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof.

[0107] The computer instructions for implementing the method of the present application can be written in any combination of one or more programming languages. These computer instructions can be provided to the computing unit 401, so that when the computer instructions are executed by the computing unit 401, such as a processor, the steps involved in the method embodiment of the present application are performed.

[0108] The computer-readable storage medium provided herein may be a tangible medium that may contain or store computer instructions for executing the steps involved in the method embodiments of the present application. The computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, and other forms of storage media.

[0109] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. An application dependency publishing method, characterized in that: The method comprises: Obtain a code change file path for a code change in an application, and determine, based on the code change file path, whether a code change exists in a target business module of the application; If there is a code change in the target business module of the application, obtain the associated submodules with code changes in the Maven project to which the target business module belongs, as well as the module version numbers of the target business module and the associated submodules; Determine whether the target business module and the associated submodule are uploaded to the Maven repository based on the configuration information of the target business module and the associated submodule, and obtain a determination result; According to the judgment result and the module version numbers of the target business module and the associated submodules, the target business module and the associated submodules are constructed for dependency publishing.

2. The method according to claim 1, characterized in that The determining, based on the code change file path, whether there is a code change in the target business module of the application program includes: Obtain the first-level directory of the code change file path, and determine whether there is a pom.xml file in the first-level directory; If a pom.xml file exists in the first-level directory, determining that a code change exists in the target business module of the application; If the pom.xml file does not exist in the first-level directory, it is determined that no code changes occur in the target business module of the application.

3. The method according to claim 1, characterized in that The step of constructing the target business module and the associated submodule for dependency publishing based on the judgment result and the module version numbers of the target business module and the associated submodule includes: If the judgment result is that the target business module and the associated submodule are uploaded to the Maven repository, determine whether the module version numbers of the target business module and the associated submodule are official version numbers based on the module version numbers of the target business module and the associated submodule, and obtain a version number judgment result; Based on the version number judgment result, the target business module and the associated submodules are constructed for dependency release.

4. The method according to claim 3, characterized in that Based on the version number judgment result, the target business module and the associated submodule are constructed for dependency release, including: If the version number judgment result is that the module version numbers of the target business module and the associated submodule are official version numbers, call the Nexus warehouse to query whether the module version numbers of the target business module and the associated submodule already exist; If the module version numbers of the target business module and the associated submodule do not exist, the first release process configured by Jenkins is called to build the target business module and the associated submodule for dependency release.

5. The method according to claim 4, characterized in that The method further comprises: If the version number judgment result is that the module version numbers of the target business module and the associated submodule are informal version numbers, call the first release process configured in Jenkins to build the target business module and the associated submodule for dependency release.

6. The method according to claim 1, wherein The step of constructing the target business module and the associated submodule for dependency publishing based on the judgment result and the module version numbers of the target business module and the associated submodule includes: If the judgment result is that the target business module and the associated submodules do not need to be uploaded to the Maven repository, the second release process configured in Jenkins is called to build the target business module and the associated submodules for dependency release.

7. The method according to claim 1, characterized in that The method further comprises: If there are no other modules with code changes in the Maven project to which the target business module belongs, the second release process configured in Jenkins is called to build the target business module for dependency release.

8. An application dependency publishing device, characterized in that: The device comprises: An acquisition module is used to obtain a code change file path of a changed code in an application, and determine whether a code change exists in a target business module of the application according to the code change file path; The acquisition module is further configured to, if there is a code change in the target business module of the application, acquire the associated submodule with the code change in the Maven project to which the target business module belongs, as well as the module version numbers of the target business module and the associated submodule; A judgment module, configured to judge whether the target business module and the associated submodule are uploaded to the Maven warehouse according to the configuration information of the target business module and the associated submodule, and obtain a judgment result; A publishing module is used to construct the target business module and the associated submodule for dependency publishing according to the judgment result and the module version numbers of the target business module and the associated submodule.

9. A computer device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores computer instructions that can be executed by the at least one processor. The computer instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer instructions stored thereon, characterized in that: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 7.

Images