Source code path-based application orchestration construction method and device, equipment and medium

Abstract

The application relates to a source code path-based application arrangement construction method and device, equipment and medium, and relates to the technical field of computer software development.The application comprises the following steps: receiving a Git server Webhook event, extracting a target commit identifier and repository information after verification, calling a Git API to obtain a list of changed files, matching the list of changed files with a preset application source code path prefix mapping table, accurately determining an effective changed application set, creating a CI task for each application in the set and binding the target commit identifier, triggering an application process pipeline to perform single-application construction and release, triggering a blueprint pipeline when multiple-application combination release is required, sequentially calling each application process pipeline according to a preset arrangement relationship, and transmitting a unified target commit identifier.The scheme realizes accurate triggering of construction tasks and automatic and orderly arrangement of multiple applications, avoids invalid construction, eliminates manual arrangement errors, and ensures the consistency of the version of the combination release.

Description

Technical Field

[0001] This application relates to the field of computer software development technology, specifically to an application orchestration and construction method, apparatus, device, and medium based on source code path. Background Technology

[0002] With the evolution of software engineering architecture, the Monorepo pattern has been widely adopted in the development of large-scale software projects due to its advantages such as facilitating code sharing, unified dependency management, and simplified refactoring. In the Monorepo pattern, multiple applications or modules coexist in the same Git repository for version control. However, this pattern presents significant challenges to continuous integration and continuous delivery (CI / CD) systems, especially in the building and release phases of multiple applications, where existing technical solutions often struggle to balance efficiency and accuracy.

[0003] Currently, mainstream CI / CD systems (such as Jenkins, GitLab CI, GitHub Actions, etc.) typically use full builds or path filtering builds based on simple rules when dealing with single-repository multi-application scenarios.

[0004] First, developers need to write complex regular expressions or path matching rules (such as Glob patterns) in CI / CD configuration files to try to determine which application builds to trigger based on the path of code changes. However, as the project scales up and the directory structure between applications becomes increasingly complex, manually maintaining these rules becomes extremely difficult. Rule configuration is prone to omissions or misjudgments, resulting in builds that should not be built (risk of missed tests) or builds that should not be built (waste of resources).

[0005] Secondly, in actual business operations, it is often necessary to release multiple related applications together (for example, the "user side" and "merchant side" of an e-commerce app need to be released together). Existing technical solutions usually lack automated orchestration mechanisms, requiring manual creation of complex pipeline dependencies or sequential execution of multiple build tasks. This manual orchestration method is cumbersome and highly susceptible to version inconsistencies or release failures due to human error. Summary of the Invention

[0006] In view of this, this application provides an application orchestration and build method, apparatus, device, and medium based on source code paths. Its main purpose is to address the challenges of increasingly complex directory structures between applications as projects grow, making manual rule maintenance extremely difficult, prone to omissions or misjudgments in rule configuration, and the common lack of automated orchestration mechanisms in existing technical solutions, which necessitate manually creating complex pipeline dependencies or executing multiple build tasks sequentially. This manual orchestration method is cumbersome and highly susceptible to version inconsistencies or release failures due to human error.

[0007] Firstly, this application provides an application orchestration and construction method based on source code paths, including: Receive webhook push events sent by the Git server, perform legality verification on the webhook push events, and after the verification is successful, parse and extract the target commit identifier, repository identifier and branch name from the webhook push events; Based on the target commit identifier and the repository identifier, the application programming interface of the Git server is called to obtain the list of changed file paths corresponding to this commit. Obtain a pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table, and determine the valid set of changed applications; For each application in the set of valid change applications, a corresponding CI build task is created, and the CI build task is bound to the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application; When there is a demand for a combined release of multiple applications, the blueprint pipeline is triggered. The blueprint pipeline sequentially calls the application process pipelines corresponding to each application according to the pre-configured multi-application orchestration relationship, and passes the target commit identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

[0008] Secondly, this application provides an application orchestration and construction apparatus based on source code paths, comprising: The receiving module is used to receive Webhook push events sent by the Git server, perform legality verification on the Webhook push events, and after the verification is successful, parse and extract the target commit identifier, repository identifier and branch name from the Webhook push events. The acquisition module is used to call the application programming interface of the Git server based on the target commit identifier and the repository identifier to obtain a list of changed file paths corresponding to this commit; The matching module is used to obtain a pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table, and determine the valid set of changed applications. The binding module is used to create a corresponding CI build task for each application in the set of valid change applications, and bind the CI build task to the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application; The triggering module is used to trigger the blueprint pipeline when there is a demand for a combined release of multiple applications. The blueprint pipeline sequentially calls the application process pipelines corresponding to each application according to the pre-configured multi-application orchestration relationship, and passes the target submission identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

[0009] Thirdly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the application orchestration and construction method based on source code path described in the first aspect.

[0010] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the application orchestration and construction method based on source code path described in the first aspect.

[0011] By utilizing the above technical solutions, this application provides an application orchestration and construction method, apparatus, device, and medium based on source code paths. Compared with existing technologies, this application can receive Webhook push events sent by a Git server, perform legality verification on the Webhook push events, and after successful verification, parse and extract the target commit identifier, repository identifier, and branch name from the Webhook push events; based on the target commit identifier and repository identifier, call the application programming interface of the Git server to obtain the list of changed file paths corresponding to this commit; obtain a pre-configured application source code path prefix mapping table, and map each file path in the changed file path list... The path is matched with the source code path prefix in the application source code path prefix mapping table to determine the valid set of changed applications. A corresponding CI build task is created for each application in the valid set of changed applications, and the CI build task is bound to the target commit identifier to trigger the application process pipeline to execute the build and release. The application process pipeline is used to execute the build and release process of a single application. When there is a demand for a combined release of multiple applications, the blueprint pipeline is triggered. The blueprint pipeline calls the application process pipeline corresponding to each application in sequence according to the pre-configured multi-application orchestration relationship, and passes the target commit identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

[0012] Using the above technical solution, this application employs a pre-configured application source code path prefix mapping table. When code is committed, the system automatically retrieves a standard list of changed file paths from the Git server and directly matches it with the source code path prefixes in the mapping table. This automatically calculates the effective set of applied changes, simplifying complex rule writing into a simple prefix mapping table configuration. Regardless of project size or directory structure complexity, only the mapping table needs to be maintained. The system automatically calculates changes, completely avoiding the risk of missed testing due to manual configuration and preventing resource waste caused by misjudgments.

[0013] This application introduces the concept of a Blueprint Pipeline. When multiple applications need to be deployed together, there is no longer a need to manually create complex pipeline dependencies or sequential tasks; instead, the Blueprint Pipeline is triggered. Based on the pre-configured multi-application orchestration relationship, the Blueprint Pipeline automatically calls the corresponding application process pipelines for each application sequentially, passing down a unique target commit identifier, thus achieving complete automation and standardization of multi-application deployment. By passing down a unified target commit identifier, strong consistency between the versions of the deployed applications is ensured, completely eliminating the problems of tedious, error-prone manual orchestration, version inconsistencies, and deployment failures.

[0014] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating an application orchestration and construction method based on source code path provided in this application embodiment; Figure 2 This application provides an example of a multi-application orchestration and construction system architecture based on source code path association. Figure 3 A complete flowchart of multi-application orchestration building and deployment is provided for embodiments of this application; Figure 4 A schematic diagram illustrating the principle of precise construction of source code path association differentials provided in this application embodiment; Figure 5 This is a schematic diagram of an application orchestration and construction device based on source code path, provided in an embodiment of this application. Detailed Implementation

[0018] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0019] The following description, with reference to the accompanying drawings, describes an application orchestration and construction method, apparatus, device, and medium based on source code paths according to embodiments of this application.

[0020] This application provides an application orchestration and build method, apparatus, device, and medium based on source code paths. Its main purpose is to address the challenges of increasingly complex directory structures between applications as projects grow, making manual rule maintenance extremely difficult, prone to omissions or misjudgments in rule configuration, and the lack of automated orchestration mechanisms in existing technical solutions, which often require manual creation of complex pipeline dependencies or sequential execution of multiple build tasks. This manual orchestration method is cumbersome and highly susceptible to version inconsistencies or release failures due to human error.

[0021] like Figure 1 As shown, embodiments of this application provide an application orchestration and construction method based on source code paths, including: Step 101: Receive the Webhook push event sent by the Git server, perform a validity check on the Webhook push event, and after the check passes, parse and extract the target commit identifier, repository identifier, and branch name from the Webhook push event.

[0022] In this embodiment, as Figure 2 As shown, after a developer performs a code push operation to a Git server (such as GitLab, Gitee, etc.), the Git server can send an HTTP POST request to the CI system based on a pre-configured Webhook address; this is the Webhook push event. To ensure the security of build tasks and prevent malicious requests from forging push events to trigger builds, the CI system can perform a validity check on the Webhook push event. The specific verification process may vary depending on the type of Git server platform.

[0023] On the Git server, pre-configure a server-side Webhook for the target code repository, set the trigger event type to push event, and generate a random key string (SecretToken) on the Git server's Webhook configuration page. This key string is also configured as a pre-set key in the CI system's Webhook receiving module.

[0024] The Webhook receiving module of the CI system can extract the signature field from the HTTP request header of the Webhook push event. Different verification strategies are employed depending on the type of Git server platform. If the Git server is a Type 1 platform, the CI system extracts the signature field (such as X-Gitlab-Token) from the HTTP request header of the Webhook push event and directly compares this signature field with the pre-set key string (SecretToken) in the CI system. If the two match perfectly, the verification is considered successful and processing is allowed; if they do not match, a 401 Unauthorized response is returned, and processing is refused.

[0025] If the Git server is a Type II platform, this verification uses an HMAC-based security mechanism. The CI system extracts the signature field (such as X-Gitee-Token) from the HTTP request header, performs an HMAC-SHA256 hash calculation on the HTTP request body (Payload byte stream) using a pre-set key string, and obtains a local signature value (with a sha256= prefix added to the result). Then, a constant-time comparison function is used to securely compare the local signature value with the signature field in the request header. If they match, the verification passes; otherwise, a 401 response is returned to reject the request. This mechanism effectively prevents timing attacks.

[0026] In a preferred implementation of this embodiment, the first type of platform can be the GitLab platform, and the second type of platform can be the Gitee platform. However, this application is also applicable to other Git server platforms that support the Webhook mechanism (such as GitHub, Bitbucket, Gitee, etc.). For the signature verification methods of different platforms, those skilled in the art can make corresponding adaptations according to the Webhook documentation provided by the platform, and these are all within the protection scope of this application.

[0027] The above verification mechanism can effectively prevent malicious requests from forging push events, ensuring that only push events sent by legitimate Git servers can trigger the CI build process.

[0028] After successful verification, the CI system parses the JSON request body of the Webhook push event and extracts the key fields of this push. The key fields may include the target commit identifier, repository identifier, and branch name.

[0029] Specifically, the JSON request body can be parsed to extract the latest commit SHA value of this push as the target commit identifier (i.e., commitId). This target commit identifier is a 40-digit hexadecimal string, such as "ab3d7f1e…", which is used for binding in subsequent versions. The unique repository identifier (such as repository.id) or the full path name of the repository (such as repository.full_name) in the JSON request body can be extracted as the repository identifier, which can be used to identify the target code repository; The value of the reference field (ref field) in the JSON request body can be extracted as the branch name, such as "refs / heads / main", which can be used to filter the build scope.

[0030] In some optional implementations of this embodiment, a list of all commit objects involved in this push can also be extracted from the commits[] array of the JSON request body. Each object contains information such as the commit ID, the list of modified / added / deleted files, and the commit timestamp, which is used to obtain the changed file path in subsequent steps.

[0031] Step 102: Based on the target commit identifier and repository identifier, call the Git server's application programming interface to obtain the list of changed file paths corresponding to this commit.

[0032] After obtaining the target commit identifier and repository identifier, the CI system needs to know which files were specifically modified in this commit to determine which application builds to trigger. Since the file change information contained in the Webhook push event may be incomplete (e.g., containing only a small amount of commit information), the CI system can proactively call the Git server API to obtain a complete list of changes. The specific retrieval process may include: Step 201: The CI system constructs an API request and calls the Git server's Diff API with the target commit identifier and repository identifier as input parameters.

[0033] The specific way to call the difference comparison API varies depending on the Git server platform: For the GitLab platform, the Commits API can be accessed via the following address: GET / api / v4 / projects / {project_id} / repository / commits / {commit_sha} / diff, Where {commit_sha} is the commitId extracted in step 101 as the parameter value, and {project_id} is the repository identifier extracted in step 101 as the parameter value.

[0034] For the Gitee platform, call the GET / api / v5 / repos / {repo} / commits / {commit_sha} interface, where {commit_sha} is the commitId extracted in step 101 as the parameter value, and {repo} is the repository identifier extracted in step 101 as the parameter value.

[0035] Step 202: Receive the change information returned by the difference comparison interface. The change information includes added file paths, modified file paths, and removed file paths.

[0036] Specifically, the GitLab platform's Diff API returns a JSON array, where each element contains an `old_path` field and a `new_path` field for each file change record (corresponding to the old and new paths of the file, respectively). The CI system iterates through each diff record, extracts the `new_path` field (and for file deletion operations, extracts the `old_path` field), and summarizes the paths of all changed files. The `files[]` field in the Gitee platform's API return result is the list of changed files, and the `filename` field of each element is the relative path of the changed file.

[0037] Step 203: The CI system standardizes the file paths in the change information and summarizes them to generate a list of relative paths based on the repository root directory, which serves as the changed file path list (changed_files_list).

[0038] For example, a list of changed file paths can be represented as: ["service-a / src / main.java", "frontend / app-b / index.ts", "docs / README.md"]. Each path in this list is based on the repository root directory, preparing for subsequent path prefix matching.

[0039] Step 103: Obtain the pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table, and determine the valid set of changed applications.

[0040] like Figure 3 As shown, in this step, the CI system obtains a pre-configured and persistently stored application source code path prefix mapping table, and then matches the list of changed file paths obtained in step 102 with the source code path prefixes in the mapping table to determine the application scope affected by this commit. Specifically, step 103 includes the following sub-steps: Step 301: Obtain the pre-configured application source code path prefix mapping table. During the application registration phase, when the administrator creates an application in the CI system, they configure one or more source code path prefixes for each application. These prefixes represent the storage path of the application's source code in the Git repository, in the format of a path string starting with " / " (e.g., / service-a / , / frontend / app-b / ). The system persistently stores the mapping relationship between each application and its source code path prefix (Application ID → Path Prefix List) in the CI system database as the application source code path prefix mapping table.

[0041] Step 302: Traverse each changed file path in the list of changed file paths, and normalize each changed file path to ensure that the path starts with the root directory symbol / and does not contain any extra trailing symbols.

[0042] Step 303: Check the application source path prefix mapping table to see if there is a source path prefix that uses the changed file path as a prefix. Specifically, determine if the changed file path starts with a source path prefix in the mapping table (i.e., changed_file.startswith(prefix)).

[0043] If a match exists, meaning the changed file path uses the source code path prefix of a certain application as a prefix, then the application corresponding to that source code path prefix is ​​marked as the changed application, and that changed application is added to the set of valid changed applications.

[0044] For example, suppose the source code path prefix configured for application A is / service-a / , and the list of changed file paths includes / service-a / src / main.java, then the changed file path / service-a / src / main.java has / service-a / as its prefix, and the match is successful. Application A will then be added to the set of valid changed applications.

[0045] Step 304: Continue traversing the next changed file path until all changed file paths have been traversed, and finally output the set of valid changes after deduplication.

[0046] In a preferred implementation of this embodiment, after matching, the set of valid changed applications is deduplicated to ensure that each application appears only once in the set. For example, the final output set of valid changed applications can be represented as: {app_service_a, app_frontend_b}.

[0047] Step 104: Create a corresponding CI build task for each application in the effective change application set, and bind the CI build task with the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application.

[0048] This step takes the set of valid changed applications output in step 103 and the target commit identifier (commitId) extracted in step 101 as input. It creates a CI build task bound to the commitId for each matched application and triggers the first-level pipeline (i.e., the application process pipeline) to execute the build and release. Specifically, step 104 includes the following sub-steps: Step 401: Create a CI task object for each application in the set of valid change applications. The CI task object is associated with a unique task ID, application ID, and target commit ID.

[0049] Preferably, the CI task object also stores fields such as repository identifier, branch name, task creation time, and task status (initialized to "pending" or "PENDING" status).

[0050] Step 402: Persistently store the CI task object in the CI system's database to bind the CI build task to the target commit identifier. Through this binding mechanism, each CI build task corresponds one-to-one with a specific commitId, ensuring version management that "one commit corresponds to one reproducible record," providing a foundation for subsequent historical version backtracking builds.

[0051] For applications that do not match any application path prefix, no CI build tasks are created, thus achieving differential and accurate builds and avoiding the consumption of CI / CD resources by invalid builds.

[0052] Step 403: For each application in the valid change application set, trigger the corresponding application process pipeline to execute the build and release. The application process pipeline is an independent first-level pipeline for each application, defining the complete build and release process for that application.

[0053] Specifically, triggering the application pipeline to execute build and release includes the following sub-steps: Step 403-1: Execute code pull operation based on the target commit identifier (commitId). The application pipeline uses the commitId as input parameter and calls the git checkout or git clone command to pull the source code of the exact version corresponding to the commitId from the Git repository, ensuring the accuracy of the built version.

[0054] Step 403-2: Based on the pulled source code version, perform dependency installation operations (such as executing commands like npm install, mvn dependency:resolve, etc.) to install the dependency packages required for the application to run.

[0055] Step 403-3: Perform compilation and build operations (e.g., execute commands such as npm run build, mvn compile) to generate build artifacts (such as executable files, static resource packages, JAR packages, etc.).

[0056] Step 403-4: Perform automated testing operations (such as unit tests, integration tests, etc.) to verify the quality of the build artifacts and ensure that code changes do not introduce defects.

[0057] Step 403-5: Perform artifact packaging and push operations, package the build artifacts (such as building Docker images, generating release compressed packages, etc.) and push them to the artifact repository.

[0058] Step 403-6: Perform the deployment and release operation to deploy the artifact to the target environment (e.g., test environment, pre-release environment, or production environment) to complete the release.

[0059] Step 403-7: Write back the execution results (success or failure status) of each of the above operations to the CI build task record so that users can view the build history and status.

[0060] Step 105: When there is a demand for a multi-application combined release, the blueprint pipeline is triggered. The blueprint pipeline calls the application process pipeline corresponding to each application in sequence according to the pre-configured multi-application orchestration relationship, and passes the target commit identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

[0061] When a requirement involves multiple applications and these applications need to be released together, users can trigger the blueprint pipeline (i.e., the secondary pipeline) to achieve automated and orderly release of multiple applications without manual orchestration. Specifically, step 105 includes the following sub-steps: Step 501: Load the orchestration configuration associated with the blueprint pipeline. The orchestration configuration is configured and persistently stored by the user when pre-creating the blueprint pipeline in the CI system, defining the execution order and dependencies of multiple application process pipelines.

[0062] Specifically, when creating a blueprint pipeline, users can select multiple applications from existing applications, configure execution order number (serial) or parallel grouping for each application, and configure the relationship between preceding dependent applications. The execution order is numbered; for example, application A is executed first, and application B is executed second. Parallel grouping, for example, application A and application B belong to the same parallel group and can be executed simultaneously; Pre-dependent application relationships, for example, setting application B to depend on application A, meaning that application B's application process pipeline can only be triggered after application A's application process pipeline has been successfully executed.

[0063] Step 502: Start the first application pipeline in the execution order. The Blueprint Pipeline Engine passes the target commit ID (commitId) as a parameter to the currently started application pipeline to ensure that the pipeline pulls the correct source code version.

[0064] Step 503: Monitor the execution status of the current application process pipeline.

[0065] When the execution status is successful and the prerequisites for the next application pipeline are met, the next application pipeline is automatically triggered. For example, if application B depends on application A, when the application pipeline of application A executes successfully (status is SUCCESS), the Blueprint pipeline engine automatically starts the application pipeline of application B.

[0066] If the execution status is "execution failed" or "execution timed out", the execution of the blueprint pipeline will be interrupted and the entire blueprint pipeline task will be marked as "FAILED". At the same time, a notification message will be sent to the relevant development or operations personnel.

[0067] For applications configured with parallel grouping, the application process pipelines of multiple applications within the same group are triggered and executed in parallel to shorten the overall release time.

[0068] Step 504: The Blueprint Pipeline Engine summarizes the execution status of each application process pipeline in real time. If all sub-pipelines succeed, the entire Blueprint task is marked as successful (SUCCESS). If any fails, the subsequent process is interrupted and marked as failed (FAILED). The entire process does not require manual intervention.

[0069] In this embodiment, the blueprint pipeline can be triggered automatically (e.g., automatically after all application process pipelines in step 104 have been executed) or manually by the user (e.g., the user selects the application set to be combined and released on the CI system interface and then clicks to execute).

[0070] It should be noted that in the two-tier pipeline architecture of this application, the first-level pipeline (application process pipeline) can be executed independently, meeting the build and release requirements of a single application; the second-level pipeline (blueprint pipeline) is a secondary orchestration of multiple first-level pipelines, meeting the combined release requirements of multiple applications. Both pipelines use commitId as the version link, ensuring version consistency and traceability throughout the entire chain from Webhook triggering to final deployment.

[0071] This embodiment further includes a historical version backtracking build process, thereby realizing automated backtracking builds based on any historical version. Following step 105 in Embodiment 1, the method provided in this embodiment further includes the following steps: When the target historical submission identifier selected by the user is received, the target submission identifier extracted from the Webhook push event in step 101 is replaced with the target historical submission identifier: When users need to rebuild and release based on historical versions (for example, if they find that the latest version has defects and need to revert to a historical stable version, or if they need to release a patch for a historical version), users can select a specified historical commitId as the target historical commit identifier in the CI system's user interface.

[0072] Based on the target historical commit identifier and repository identifier, call the Git server's application programming interface to obtain the list of historical change file paths corresponding to the target historical commit identifier: The specific implementation of this step is the same as step 102, the only difference being that the input target commit identifier is the target historical commit identifier selected by the user, instead of the latest commit identifier parsed from the Webhook push event in step 101. The CI system uses this target historical commit identifier and the repository identifier as parameters to call the Git server's difference comparison interface to obtain the list of changed file paths corresponding to this historical commit.

[0073] Match the list of historical changed file paths with the application source code path prefix mapping table to determine the set of historically valid changed applications: The specific implementation method of this step is the same as that of step 103, that is, to execute the path prefix matching algorithm, match the list of historical changed file paths with the application source code path prefix mapping table, and determine the application scope affected by the historical version.

[0074] For each application in the set of historically valid change applications, create a historical CI build task bound to the target historical commit identifier, trigger the application process pipeline to execute the build and release, and realize automated backtracking build based on any historical version: The specific implementation method of this step is the same as that of step 104, the difference being that the CI build task created is bound to the target historical commit ID, rather than the latest commit ID. The application pipeline uses this historical commit ID as input parameter to pull the corresponding version of the source code and execute the complete build and release process, thereby realizing one-click automated backtracking build based on any historical version without the need to re-push the code.

[0075] Through the above steps, this application achieves true version management and backtracking capabilities of "one commit corresponds to one reproducible record", overcoming the shortcomings of existing technologies in terms of difficulty in backtracking historical versions.

[0076] In specific application scenarios, such as Figure 4 As shown, this application provides an exemplary description of the complete process of the application orchestration and construction method based on source code path.

[0077] Suppose a Monorepo repository contains three applications: Application A (backend service, source code path prefixed / service-a / ), Application B (frontend application, source code path prefixed / frontend / app-b / ), and Application C (data service, source code path prefixed / service-c / ). The application pipelines for all three applications are pre-configured, and the user has created a blueprint pipeline named "Full Deployment," orchestrated in the following order: Application A → Application B → Application C (executed sequentially, with Application B depending on Application A, and Application C depending on Application B).

[0078] When a developer pushes code to the repository (only modifying the / service-a / src / main.java file), the execution flow is as follows: The Git server generates a Webhook push event and sends it to the Webhook receiving module of the CI system. The CI system verifies the validity of the Webhook request, and after the verification is successful, it parses and extracts the commitId (e.g., "abc123..."), repository identifier, and branch name of this push.

[0079] The CI system calls the Git server's Diff API with the commitId as a parameter to obtain a list of changed file paths. This time, it only includes ["service-a / src / main.java"].

[0080] The CI system matches the list of changed file paths with the application source code path prefix mapping table. The changed file path `service-a / src / main.java` matches successfully with the application A's path prefix ` / service-a / `, thus determining the valid set of changed applications as {application A}. No changed files were matched with the source code path prefixes of applications B and C, therefore they are not added to the valid set of changed applications.

[0081] The CI system creates a CI build task for application A bound to commitId "abc123" and triggers application A's application pipeline. Application A's application pipeline uses commitId "abc123" as input parameter to pull the corresponding version of source code, and performs dependency installation, compilation and building, unit testing, artifact packaging, and deployment.

[0082] Since only application A has changed, there is no need to trigger the blueprint pipeline this time. Applications B and C will not be invalidated, thus saving CI / CD resources.

[0083] In another scenario, suppose a developer simultaneously modifies the code of Application A, Application B, and Application C. In this case, the set of valid modified applications identified in step 3 is {Application A, Application B, Application C}. Step 4 creates CI build tasks bound to commitIds for each of the three applications and triggers their respective application process pipelines. In step 5, the user triggers the "full release" blueprint pipeline. The blueprint pipeline engine sequentially calls the application process pipelines of each application according to the pre-configured orchestration: first, Application A is executed; after Application A completes successfully, Application B is executed; after Application B completes successfully, Application C is executed, achieving automated and orderly release of multiple applications.

[0084] Through the above process, this application achieves the following technical effects: first, version traceability is achieved through Webhook + commitId binding; second, precise on-demand building is achieved through path differential parsing; and third, automated combined deployment of multiple applications is achieved through a two-layer pipeline architecture.

[0085] In summary, the application orchestration and construction method based on source code paths provided in this application, compared with existing technologies, can receive Webhook push events sent by the Git server, perform legality verification on the Webhook push events, and after successful verification, parse and extract the target commit identifier, repository identifier, and branch name from the Webhook push events; based on the target commit identifier and repository identifier, call the application programming interface of the Git server to obtain the list of changed file paths corresponding to this commit; obtain the pre-configured application source code path prefix mapping table, and match each file path in the changed file path list with the application source code... The source code path prefixes in the path prefix mapping table are matched to determine the valid set of changed applications. A corresponding CI build task is created for each application in the valid set of changed applications, and the CI build task is bound to the target commit identifier to trigger the application process pipeline to execute the build and release. The application process pipeline is used to execute the build and release process of a single application. When there is a demand for a combined release of multiple applications, the blueprint pipeline is triggered. The blueprint pipeline calls the application process pipelines corresponding to each application in sequence according to the pre-configured multi-application orchestration relationship, and passes the target commit identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

[0086] Using the above technical solution, this application employs a pre-configured application source code path prefix mapping table. When code is committed, the system automatically retrieves a standard list of changed file paths from the Git server and directly matches it with the source code path prefixes in the mapping table. This automatically calculates the effective set of applied changes, simplifying complex rule writing into a simple prefix mapping table configuration. Regardless of project size or directory structure complexity, only the mapping table needs to be maintained. The system automatically calculates changes, completely avoiding the risk of missed testing due to manual configuration and preventing resource waste caused by misjudgments.

[0087] This application introduces the concept of a Blueprint Pipeline. When multiple applications need to be deployed together, there is no longer a need to manually create complex pipeline dependencies or sequential tasks; instead, the Blueprint Pipeline is triggered. Based on the pre-configured multi-application orchestration relationship, the Blueprint Pipeline automatically calls the corresponding application process pipelines for each application sequentially, passing down a unique target commit identifier, thus achieving complete automation and standardization of multi-application deployment. By passing down a unified target commit identifier, strong consistency between the versions of the deployed applications is ensured, completely eliminating the problems of tedious, error-prone manual orchestration, version inconsistencies, and deployment failures.

[0088] Based on the above Figure 1 The specific implementation of the method shown in this embodiment provides an application orchestration and building device based on source code paths, such as... Figure 5As shown, the device includes: a receiving module 31, an acquisition module 32, a matching module 33, a binding module 34, and a triggering module 35; The receiving module 31 is used to receive Webhook push events sent by the Git server, perform legality verification on the Webhook push events, and after the verification is passed, parse and extract the target commit identifier, repository identifier and branch name from the Webhook push events. The acquisition module 32 is used to call the application programming interface of the Git server based on the target commit identifier and the repository identifier to obtain the list of changed file paths corresponding to this commit; Matching module 33 is used to obtain a pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table, and determine the valid set of changed applications; Binding module 34 is used to create a corresponding CI build task for each application in the set of valid change applications, and bind the CI build task to the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application; Trigger module 35 is used to trigger the blueprint pipeline when there is a demand for multi-application combined release. The blueprint pipeline sequentially calls the application process pipeline corresponding to each application according to the pre-configured multi-application orchestration relationship, and passes the target submission identifier to each application process pipeline to realize the automated and orderly release of multiple applications.

[0089] In specific application scenarios, the receiving module 31 can be used to extract the signature field from the request header of the HTTP request of the Webhook push event; if the Git server is a first type platform, the signature field is compared with the key string preset in the CI system, and if they match, the verification is deemed successful; if the Git server is a second type platform, the request body of the HTTP request is hashed using the key string to obtain a local signature value, and the local signature value is compared with the signature field, and if they match, the verification is deemed successful.

[0090] In a specific application scenario, the acquisition module 32 can be used to call the Git server's difference comparison interface with the target commit identifier and the repository identifier as input parameters; receive the change information returned by the difference comparison interface, the change information including newly added file paths, modified file paths, and deleted file paths; perform normalization processing on the file paths in the change information, and summarize and generate a relative path list based on the repository root directory as the changed file path list.

[0091] In a specific application scenario, the matching module 33 can be used to traverse each changed file path in the changed file path list; search in the application source code path prefix mapping table for a source code path prefix with the changed file path as the prefix; if it exists, mark the application corresponding to the source code path prefix as the changed application, add the changed application to the set of valid changed applications, and continue to traverse the next application until the traversal ends, and finally output the set of valid changed applications after deduplication.

[0092] In specific application scenarios, the binding module 34 can be used to create CI task objects for each application in the set of valid change applications. The CI task objects are associated with a unique task identifier, an application identifier, and the target submission identifier. The CI task objects are persistently stored in the database of the CI system to bind the CI build task with the target submission identifier.

[0093] In specific application scenarios, the binding module 34 can be used to perform code retrieval operations based on the target submission identifier to obtain the source code version corresponding to the target submission identifier; based on the source code version, it can sequentially perform dependency installation, compilation and building, unit testing, artifact packaging and deployment operations; and write the operation execution results back to the CI build task.

[0094] In a specific application scenario, the trigger module 35 can be used to load the orchestration configuration associated with the blueprint pipeline. The orchestration configuration defines the execution order and dependencies of multiple application process pipelines. According to the execution order, the first application process pipeline is started. The execution status of the application process pipeline is monitored. When the execution status is successful and the prerequisite conditions of the next application process pipeline are met, the next application process pipeline is triggered. If the execution status is failed or timed out, the execution of the blueprint pipeline is interrupted and marked as failed.

[0095] It should be noted that other corresponding descriptions of the functional units involved in the application orchestration and construction device based on source code path provided in this embodiment can be found in [reference]. Figure 1 The corresponding descriptions in [the document] will not be repeated here.

[0096] Based on the above, Figure 1 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 The method shown.

[0097] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0098] Based on the above, Figure 1 The method shown, and Figure 5 To achieve the above objectives, the present application also provides an electronic device, comprising a storage medium and a processor; the storage medium for storing a computer program; and the processor for executing the computer program to implement the above-described virtual device embodiments. Figure 1 The method shown.

[0099] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0100] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0101] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the execution of application orchestration build programs based on source code paths, as well as other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, and to communicate with other hardware and software in the application orchestration build physical device based on source code paths.

[0102] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platform, or it can be implemented by hardware. By applying the solution of this embodiment, compared with the existing technology, this application can receive Webhook push events sent by the Git server, perform legality verification on the Webhook push events, and after the verification is successful, parse and extract the target commit identifier, repository identifier, and branch name from the Webhook push events; based on the target commit identifier and repository identifier, call the application programming interface of the Git server to obtain the list of changed file paths corresponding to this commit; obtain the pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table to determine the valid set of changed applications; create a corresponding CI build task for each application in the valid set of changed applications, and bind the CI build task with the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application; when there is a demand for multiple application combined release, the blueprint pipeline is triggered. The blueprint pipeline calls the application process pipelines corresponding to each application in sequence according to the pre-configured multi-application orchestration relationship, and passes the target commit identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

[0103] Using the above technical solution, this application employs a pre-configured application source code path prefix mapping table. When code is committed, the system automatically retrieves a standard list of changed file paths from the Git server and directly matches it with the source code path prefixes in the mapping table. This automatically calculates the effective set of applied changes, simplifying complex rule writing into a simple prefix mapping table configuration. Regardless of project size or directory structure complexity, only the mapping table needs to be maintained. The system automatically calculates changes, completely avoiding the risk of missed testing due to manual configuration and preventing resource waste caused by misjudgments.

[0104] This application introduces the concept of a Blueprint Pipeline. When multiple applications need to be deployed together, there is no longer a need to manually create complex pipeline dependencies or sequential tasks; instead, the Blueprint Pipeline is triggered. Based on the pre-configured multi-application orchestration relationship, the Blueprint Pipeline automatically calls the corresponding application process pipelines for each application sequentially, passing down a unique target commit identifier, thus achieving complete automation and standardization of multi-application deployment. By passing down a unified target commit identifier, strong consistency between the versions of the deployed applications is ensured, completely eliminating the problems of tedious, error-prone manual orchestration, version inconsistencies, and deployment failures.

[0105] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0106] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. An application orchestration and construction method based on source code paths, characterized in that, include: Receive webhook push events sent by the Git server, perform legality verification on the webhook push events, and after the verification is successful, parse and extract the target commit identifier, repository identifier and branch name from the webhook push events; Based on the target commit identifier and the repository identifier, the application programming interface of the Git server is called to obtain the list of changed file paths corresponding to this commit. Obtain a pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table, and determine the valid set of changed applications; For each application in the set of valid change applications, a corresponding CI build task is created, and the CI build task is bound to the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application; When there is a demand for a combined release of multiple applications, the blueprint pipeline is triggered. The blueprint pipeline sequentially calls the application process pipelines corresponding to each application according to the pre-configured multi-application orchestration relationship, and passes the target commit identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

2. The application orchestration and construction method based on source code path according to claim 1, characterized in that, The legality verification of the Webhook push event specifically includes: Extract the signature field from the request header of the HTTP request for the Webhook push event; If the Git server is a Type 1 platform, the signature field is compared with the key string pre-set in the CI system. If they match, the verification is deemed successful. If the Git server is a second type platform, the local signature value is obtained by performing HMAC-SHA256 hash calculation on the request body of the HTTP request using the key string. The local signature value is then compared with the signature field. If the comparison is consistent, the verification is deemed successful.

3. The application orchestration and construction method based on source code path according to claim 1, characterized in that, The step of calling the Git server's application programming interface based on the target commit identifier and the repository identifier to obtain the list of changed file paths corresponding to this commit specifically includes: Using the target commit identifier and the repository identifier as input parameters, the Git server's difference comparison interface is invoked; Receive change information returned by the difference comparison interface, the change information including added file path, modified file path, and deleted file path; The file paths in the change information are standardized, and a list of relative paths based on the repository root directory is generated as the list of changed file paths.

4. The application orchestration and construction method based on source code path according to claim 1, characterized in that, The step of matching each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table to determine the valid set of changed applications specifically includes: Iterate through each changed file path in the list of changed file paths; Check the application source code path prefix mapping table to see if there is a source code path prefix with the changed file path as the prefix; If it exists, mark the application corresponding to the source code path prefix as the changed application, add the changed application to the set of valid changed applications, and continue to traverse the next application until the traversal ends, and finally output the set of valid changed applications after deduplication.

5. The application orchestration and construction method based on source code path according to claim 2, characterized in that, The step of creating a corresponding CI build task for each application in the set of valid change applications and binding the CI build task to the target commit identifier specifically includes: For each application in the set of valid change applications, a CI task object is created. The CI task object is associated with and stored with a unique task identifier, an application identifier, and the target submission identifier. The CI task object is persistently stored in the database of the CI system to bind the CI build task with the target commit identifier.

6. The application orchestration and construction method based on source code path according to claim 1, characterized in that, The triggering of the application process pipeline for build and deployment specifically includes: Perform a code retrieval operation based on the target commit identifier to obtain the source code version corresponding to the target commit identifier; Based on the aforementioned source code version, perform the following operations sequentially: dependency installation, compilation and building, unit testing, artifact packaging, and deployment and release. The operation execution result is written back to the CI build task.

7. The application orchestration and construction method based on source code path according to claim 1, characterized in that, The blueprint pipeline sequentially calls the application process pipelines corresponding to each application according to a pre-configured multi-application orchestration relationship, specifically including: Load the orchestration configuration associated with the blueprint pipeline, the orchestration configuration defining the execution order and dependencies of multiple application process pipelines; Start the first application process pipeline according to the execution order described; Monitor the execution status of the application process pipeline. When the execution status is successful and the prerequisite conditions for the next application process pipeline are met, trigger the next application process pipeline. If the execution status is execution failure or execution timeout, the execution of the blueprint pipeline is interrupted and marked as failure.

8. An application orchestration and building device based on source code paths, characterized in that, include: The receiving module is used to receive Webhook push events sent by the Git server, perform legality verification on the Webhook push events, and after the verification is successful, parse and extract the target commit identifier, repository identifier and branch name from the Webhook push events. The acquisition module is used to call the application programming interface of the Git server based on the target commit identifier and the repository identifier to obtain a list of changed file paths corresponding to this commit; The matching module is used to obtain a pre-configured application source code path prefix mapping table, match each file path in the changed file path list with the source code path prefix in the application source code path prefix mapping table, and determine the valid set of changed applications. The binding module is used to create a corresponding CI build task for each application in the set of valid change applications, and bind the CI build task to the target commit identifier to trigger the application process pipeline to execute the build and release; wherein, the application process pipeline is used to execute the build and release process of a single application; The triggering module is used to trigger the blueprint pipeline when there is a demand for a combined release of multiple applications. The blueprint pipeline sequentially calls the application process pipelines corresponding to each application according to the pre-configured multi-application orchestration relationship, and passes the target submission identifier to each application process pipeline to achieve automated and orderly release of multiple applications.

9. An electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the application orchestration and construction method based on the source code path as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the application orchestration and construction method based on the source code path as described in any one of claims 1 to 7.

Images