Task scheduling method, system, device and equipment of multiple Jenkins instances, medium and product

Abstract

The application relates to a multi-Jenkins-instance task scheduling method, system, device, equipment, medium and product, and relates to the technical field of operation and maintenance management. The method comprises the following steps: in response to a task request, obtaining multi-dimensional attribute information corresponding to each of multiple Jenkins instances from at least two different clusters; the task request carries a corresponding task type; determining an instance health score of each Jenkins instance according to the multi-dimensional attribute information; determining a target Jenkins instance from all Jenkins instances according to at least two of the instance health score, the task type of the task request and the multi-dimensional attribute information; and scheduling the task request to each target Jenkins instance. The method can realize unified management and control of multiple Jenkins instances across clusters.

Description

Technical Field

[0001] This application relates to the field of operation and maintenance management technology, and in particular to a task scheduling method, system, device, equipment, media and product for multiple Jenkins instances. Background Technology

[0002] In modern software development systems, Jenkins, as a mainstream continuous integration / continuous deployment (CI / CD) tool, is widely used to automate build, testing, and release processes. Jenkins typically adopts a multi-cluster, multi-instance deployment mode, where different versions of Jenkins master nodes running in different clusters or physical machine environments are managed in a decentralized manner. However, because each Jenkins instance has an independent management page and its application programming interface changes frequently with version iterations, the technology cannot achieve unified management and control of multiple Jenkins instances across clusters. Summary of the Invention

[0003] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for task scheduling of multiple Jenkins instances that can achieve unified management and control of multiple Jenkins instances across clusters, in order to address the above-mentioned technical problems.

[0004] Firstly, this application provides a task scheduling method for multiple Jenkins instances, including:

[0005] In response to a task request, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained; the task request carries the corresponding task type.

[0006] Based on the multi-dimensional attribute information, determine the instance health score of each Jenkins instance.

[0007] The target Jenkins instance is determined from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0008] The task requests are scheduled to the target Jenkins instances.

[0009] In one embodiment, determining the target Jenkins instance from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information includes:

[0010] Based on the task type of the task request and multiple preset task routing strategies, a target task routing strategy that matches the task type is determined; the task type and the task routing strategy have a pre-set matching relationship.

[0011] The target Jenkins instance is determined from all the Jenkins instances based on the target task routing strategy, the instance health score, and at least two of the multi-dimensional attribute information.

[0012] In this embodiment, by introducing a mapping between task types and routing policies, the task-differentiated adaptation of the scheduling logic is achieved, enabling the server to dynamically adjust the selection criteria according to the specific needs of the task, thus avoiding the adaptation problems caused by a one-size-fits-all scheduling approach. At the same time, the configurability of the policy provides maintenance personnel with flexible control methods, allowing them to adjust scheduling behavior according to business changes, thereby improving the flexibility of task scheduling.

[0013] In one embodiment, determining the target Jenkins instance from all the Jenkins instances based on at least two of the target task routing policy, the instance health score, and the multi-dimensional attribute information includes:

[0014] When the task routing strategy belongs to the first type of preset strategy, based on the multi-dimensional attribute information of each Jenkins instance, candidate Jenkins instances whose multi-dimensional attribute information matches the first type of preset strategy are determined from all the Jenkins instances; the multi-dimensional attribute information and the first type of preset strategy have a pre-set corresponding matching relationship;

[0015] If the number of candidate Jenkins instances is less than or equal to the number of Jenkins instances required by the task request, the candidate Jenkins instances will be determined as the target Jenkins instances.

[0016] If the number of candidate Jenkins instances exceeds the number of Jenkins instances required by the task request, the target Jenkins instance is determined from the candidate Jenkins instances based on the instance health score of each candidate Jenkins instance.

[0017] In this embodiment, the label priority strategy is accurately executed through a two-stage selection logic of filtering first and then selecting the best. First, it ensures that the task is scheduled to a Jenkins instance that meets the mandatory requirements such as hardware and environment, thus satisfying the rigid requirements of the task. On the basis of satisfying the rigid requirements, a flexible selection is performed through health score, which ensures that the target Jenkins instance with the best current state is selected when the conditions are met, thus achieving a balance between constraints and performance optimization.

[0018] In one embodiment, determining the target Jenkins instance from all the Jenkins instances based on at least two of the target task routing policy, the instance health score, and the multi-dimensional attribute information includes:

[0019] When the task routing strategy belongs to the second type of preset strategy, the target Jenkins instance is determined from all the Jenkins instances based on the instance health score of each Jenkins instance.

[0020] In this embodiment, a simplified selection logic is used to achieve efficient load balancing for routine tasks without special requirements. This avoids complex multiple filtering conditions, reduces computational overhead, and improves the response speed of scheduling decisions. At the same time, since the instance health score has a built-in load factor, the sorting based on the instance health score naturally guides task requests to the target Jenkins instance with a lower current load and better status, achieving cross-cluster load balancing and avoiding the problem of some instances being overloaded while other instances are idle.

[0021] In one embodiment, scheduling the task request to each of the target Jenkins instances includes:

[0022] Determine the target application interface type that the target Jenkins instance is compatible with;

[0023] Based on the target application interface type and the preset plugin compatibility matrix, the task request is scheduled to each of the target Jenkins instances.

[0024] In this embodiment, by introducing an API adaptation mechanism, the API compatibility issue in a heterogeneous environment with multiple versions of Jenkins instances is resolved. The upper-level scheduling system of the server does not need to maintain independent calling logic for each version of Jenkins instance, thus realizing a unified scheduling interface. The dynamic adaptation mechanism enables the server to smoothly support the introduction of new versions of Jenkins instances and the retirement of old versions without modifying the core scheduling code. The plugin compatibility matrix further refines the adaptation granularity to the plugin level, solving the problem of inconsistent task execution caused by differences in plugin versions and improving the reliability and success rate of task scheduling.

[0025] In one embodiment, the task scheduling of the multiple Jenkins instances further includes:

[0026] Convert the instance configuration information of each Jenkins instance into a custom resource definition;

[0027] Configure the custom resource definition to each of the Jenkins instances.

[0028] In this embodiment, the configuration information of Jenkins instances is transformed from difficult-to-track XML (Extensible Markup Language) files into versionable, reviewable, and rollbackable custom resource definitions, fundamentally solving the configuration drift problem. Through the unified abstraction of custom resource definitions, the configuration of all clusters and all Jenkins instances can be centrally managed, avoiding the inefficiency and error-proneness of manually reconfiguring through multiple web interfaces.

[0029] In one embodiment, configuring the custom resource definition to each of the Jenkins instances includes:

[0030] Store the custom resource definition in the pre-created instance version library;

[0031] The custom resource definition is extracted from the instance repository through the continuous delivery workflow and configured into each of the Jenkins instances.

[0032] In this embodiment, declarative management of configuration is achieved through custom resource definitions and continuous delivery workflows. Custom resource definitions are stored in the instance version repository for unified management. Combined with GitOps continuous delivery workflows, configuration changes can be automatically and reliably synchronized to all target instances, realizing large-scale and automated distribution of configurations, significantly improving management efficiency. All configuration changes are recorded in the instance version repository, forming a complete audit trail, which meets the compliance audit requirements of industries such as finance and government.

[0033] In one embodiment, the task scheduling of the multiple Jenkins instances further includes:

[0034] If any of the target Jenkins instances is detected to have failed, the steps are returned to determine the target Jenkins instance from all the Jenkins instances based on at least two of the instance health score, the task type of the task request, and the multi-dimensional attribute information, so as to obtain the updated target Jenkins instance.

[0035] The task request of the target Jenkins instance is scheduled to the updated target Jenkins instance.

[0036] In this embodiment, a fault monitoring and automatic rescheduling mechanism is introduced to realize automatic task failover. When a Jenkins instance fails, the server can automatically detect it in a short time and switch the task to other healthy Jenkins instances for execution. This avoids long-term interruptions to the continuous integration / continuous deployment pipeline caused by single point of failure, and significantly improves the system's business continuity and fault tolerance. Compared with manual intervention recovery in related technologies, this embodiment significantly reduces fault recovery time and realizes automated operation and maintenance.

[0037] In one embodiment, determining the instance health score of each Jenkins instance based on the multi-dimensional attribute information includes:

[0038] Based on the health status data included in the multi-dimensional attribute information of each Jenkins instance, the penalty coefficient of each Jenkins instance is determined.

[0039] The instance health score of each Jenkins instance is determined based on the penalty coefficient, the multi-dimensional attribute information, and the preset weight value corresponding to the multi-dimensional attribute information of each Jenkins instance.

[0040] In this embodiment, by introducing a penalty coefficient, the health status of the Jenkins instance is used as a key factor in the scoring calculation, so that the instance health score can accurately reflect the true availability of the Jenkins instance. When the Jenkins instance fails or is in a degraded state, the penalty coefficient automatically reduces its instance health score to zero or significantly lowers it, thereby effectively excluding it during the scheduling process and avoiding scheduling tasks to Jenkins instances that are about to crash or have failed, further improving the success rate of task execution and the overall reliability of the system.

[0041] Secondly, this application also provides a task scheduling system for multiple Jenkins instances. The system includes a management layer and multiple cluster agent layers. The management layer is communicatively connected to each of the cluster agent layers. Each of the cluster agent layers is deployed in a different cluster. Each cluster agent layer is communicatively connected to each Jenkins instance in each of the clusters.

[0042] The management layer is used to respond to a task request by obtaining multi-dimensional attribute information corresponding to each of the multiple Jenkins instances from at least two different clusters from the cluster proxy layer; the task request carries a corresponding task type; based on the multi-dimensional attribute information of each Jenkins instance, the instance health score corresponding to each Jenkins instance is determined; based on at least two of the instance health score, the task type of the task request, and the multi-dimensional attribute information, the target Jenkins instance is determined from all the Jenkins instances, and the task request and the target Jenkins instance are sent to the cluster proxy layer corresponding to the target Jenkins instance.

[0043] The cluster proxy layer is used to collect the multi-dimensional attribute information of each Jenkins instance in the cluster it is in, and send the multi-dimensional attribute information to the management layer, and in response to the task request and the target Jenkins instance, schedule the task request to the target Jenkins instance.

[0044] Thirdly, this application also provides a task scheduling device for multiple Jenkins instances, including:

[0045] The task response module is used to respond to task requests and obtain multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters; the task request carries the corresponding task type.

[0046] The health scoring module is used to determine the instance health score of each Jenkins instance based on the multi-dimensional attribute information.

[0047] The instance filtering module is used to determine the target Jenkins instance from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0048] The task scheduling module is used to schedule the task requests to each of the target Jenkins instances.

[0049] Fourthly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0050] In response to a task request, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained; the task request carries the corresponding task type.

[0051] Based on the multi-dimensional attribute information, determine the instance health score of each Jenkins instance.

[0052] The target Jenkins instance is determined from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0053] The task requests are scheduled to the target Jenkins instances.

[0054] Fifthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0055] In response to a task request, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained; the task request carries the corresponding task type.

[0056] Based on the multi-dimensional attribute information, determine the instance health score of each Jenkins instance.

[0057] The target Jenkins instance is determined from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0058] The task requests are scheduled to the target Jenkins instances.

[0059] Sixthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0060] In response to a task request, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained; the task request carries the corresponding task type.

[0061] Based on the multi-dimensional attribute information, determine the instance health score of each Jenkins instance.

[0062] The target Jenkins instance is determined from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0063] The task requests are scheduled to the target Jenkins instances.

[0064] In the aforementioned multi-Jenkins instance task scheduling method, system, device, computer equipment, computer-readable storage medium, and computer program product, in response to a task request, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained. The task request carries a corresponding task type, serving as the data basis for subsequent task scheduling. Then, based on the multi-dimensional attribute information, the instance health score of each Jenkins instance is determined, quantifying the current overall health level and suitability for task execution of the Jenkins instance. Further, based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information, the target Jenkins instance is determined from all Jenkins instances, thereby scheduling the task request to the target Jenkins instance. By introducing a multi-dimensional attribute information collection and comprehensive scoring mechanism, dynamic evaluation and unified management of cross-cluster Jenkins instances are achieved, solving the problem of resource idleness and task backlog caused by the lack of a global view in related technologies. Scheduling based on factors such as real-time load and tag matching improves the overall utilization rate of cross-cluster resources. Simultaneously, by routing task requests to the most suitable target Jenkins instance, the risk of task failure due to version incompatibility or hardware mismatch is reduced. Attached Figure Description

[0065] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0066] Figure 1 This is a flowchart illustrating a task scheduling method for multiple Jenkins instances in one embodiment.

[0067] Figure 2 This is a flowchart illustrating the steps for determining the target Jenkins instance in one embodiment;

[0068] Figure 3This is a flowchart illustrating the steps for determining the target Jenkins instance in another embodiment;

[0069] Figure 4 This is a schematic diagram of the structure of a task scheduling system with multiple Jenkins instances in one embodiment;

[0070] Figure 5 This is a structural block diagram of a task scheduling device with multiple Jenkins instances in one embodiment;

[0071] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0073] As described in the background section, the Jenkins instance management methods of related technologies have the problem of not being able to achieve unified management and control of multiple Jenkins instances across clusters. The inventors have found that the reason for this problem is that in modern software development systems, Jenkins, as a mainstream continuous integration / continuous deployment (CI / CD) tool, is widely used in automated build, testing and release processes. With the popularization of enterprise digital transformation and cloud-native architecture, the deployment mode of Jenkins is showing the following trends: multi-cluster deployment: to isolate development, testing and production environments, or to meet the data compliance requirements of different business departments and different regions, enterprises usually deploy dozens or even hundreds of Jenkins Master instances independently in multiple Kubernetes (container orchestration system) clusters or virtual machine clusters; version heterogeneity: due to historical reasons or upgrade window limitations, the version differences of Jenkins instances in different clusters are significant (e.g., some instances are running on 2.401.1 LTS, while some have been upgraded to 2.414.2 or higher), resulting in significant differences in the API (Application Programming Interface) interfaces and plugin compatibility of Jenkins instances in different clusters; and a surge in management complexity: each Jenkins instance has an independent configuration interface, permission system, plugin management, and node management, requiring operations and maintenance personnel to frequently switch between multiple Web UIs (World Wide Web User Interface) and manually repeat configurations, which is inefficient and prone to errors. Therefore, the traditional single Jenkins management model can no longer meet the needs of large-scale distributed R&D scenarios. There is an urgent need for a centralized management system that can manage across clusters and versions in a unified manner, so as to realize a global resource view, intelligent task scheduling, unified configuration governance and fine-grained monitoring.

[0074] Among the related technologies, the Jenkins instance management methods adopted include: using Jenkins OperationsCenter, a commercial plugin provided by CloudBees, to connect multiple Jenkins Masters (Jenkins master servers) through a master-slave architecture, providing a unified dashboard and cross-instance job replication functionality; however, this plugin only supports versions 2.401 and above, and cannot manage earlier versions of Jenkins instances, the routing strategy is simple, only supporting round-robin, but not supporting intelligent scheduling based on load and tags, configuration synchronization depends on plugin push, lacks declarative configuration and GitOps (development and operation practices that use the Git codebase as the sole source of fact to achieve continuous delivery and continuous deployment) capabilities, and is costly. Furthermore, existing technologies also manage multiple Jenkins instances using custom scripts and the Jenkins CLI (the command-line tool provided by Jenkins). Some enterprises encapsulate jenkins-cli.jar with scripts to batch execute tasks such as creating jobs and installing plugins by traversing the network protocol list. However, this method cannot detect real-time changes in instance status (such as offline nodes or queue backlogs), making it a "blind operation." Each instance is independently authenticated, requiring the maintenance of a large number of API tokens and CSRFcrumbs (a mechanism for protecting against CSRF attacks). Key management is complex, lacks transactional guarantees, and is difficult to rollback in cases of partial success or partial failure. Scripts are fragmented, lack a unified API gateway, and are difficult to integrate into enterprise-level automated operations and maintenance platforms. Jishuhai has previously managed multiple Jenkins instances using a centralized scheduler based on the Jenkins REST API, developing a central service that periodically polls the / api / json endpoints of each Jenkins instance to collect status information and provides a simple web interface. However, this polling mechanism results in a status synchronization delay of 30-60 seconds, making it unsuitable for real-time event-driven scenarios. The issue of API version differences remains unresolved, requiring the development of multiple sets of parsing logic for different versions. There is no configuration abstraction layer, necessitating manual configuration within the Jenkins UI. Configuration-as-code functionality is not implemented, routing is missing, only status display is supported, and build tasks cannot be distributed across clusters.

[0075] Based on the above reasons, this application provides a task scheduling method for multiple Jenkins instances. In response to a task request, it acquires multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters. The task request carries a corresponding task type to understand the working status of Jenkins instances in different clusters. Based on the multi-dimensional attribute information, it determines the instance health score of each Jenkins instance. Then, by combining the instance health score, the task type of the task request, and the multi-dimensional attribute information, it identifies the target Jenkins instance from all the Jenkins instances, thereby scheduling the task request to the target Jenkins instance. By introducing a multi-dimensional attribute information collection and comprehensive scoring mechanism, it achieves dynamic evaluation and unified management of multiple Jenkins instances across clusters.

[0076] In one embodiment, such as Figure 1 As shown, a task scheduling method for multiple Jenkins instances is provided. This embodiment illustrates the method by applying it to a server. It is understood that this method can also be applied to terminals, and to systems including terminals and servers, and is implemented through interaction between the terminals and servers. The terminals can be, but are not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In this embodiment, the method includes the following steps:

[0077] Step S102: In response to the task request, obtain multi-dimensional attribute information corresponding to each of the multiple Jenkins instances from at least two different clusters.

[0078] The task request carries the corresponding task type, such as code compilation, unit testing, image building, deployment and release, etc.; the task request can refer to the operation instruction that triggers the Jenkins instance to execute the automated build, test or release process.

[0079] Here, "cluster" can refer to the underlying computing environment on which Jenkins instances are deployed, including Kubernetes clusters or physical machine clusters.

[0080] Here, a Jenkins instance can refer to an independently deployed Jenkins master server, which has its own configuration, job definitions, plugin collections, and build queues.

[0081] Among them, multi-dimensional attribute information can refer to various characteristic data used to evaluate and select Jenkins instances, including load balancing status, tag matching information, version compatibility, geographical location, affinity strategy, build metrics, queue length, and executor utilization.

[0082] Optionally, the server responds to a task request, which may be initiated by a user or an automated pipeline. The server obtains multi-dimensional attribute information from multiple Jenkins instances from at least two different clusters in real time as the data basis for subsequent task scheduling.

[0083] Step S104: Determine the instance health score of each Jenkins instance based on the multi-dimensional attribute information.

[0084] The instance health score refers to a quantitative score calculated using a weighted scoring algorithm, combined with multi-dimensional attribute information of the Jenkins instance (such as load, status, etc.), which is used to characterize the optimal performance of the instance in executing tasks.

[0085] Optionally, the server system performs a comprehensive score on each Jenkins instance based on the multi-dimensional attribute information of each Jenkins instance obtained. The scoring algorithm can adopt multi-factor weighted scoring, combined with a preset weight allocation, to calculate the health score of each Jenkins instance. The health score is used to quantify the current overall health level of the Jenkins instance and its suitability for performing tasks.

[0086] Step S106: Determine the target Jenkins instance from all Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0087] The target Jenkins instance can refer to the optimal Jenkins instance that has been selected by the server or scheduling method to execute the current task request.

[0088] Optionally, the server considers multiple factors to select a target Jenkins instance. Based on at least two of the following: instance health score, task type of the task request, and multi-dimensional attribute information, the server filters one or more qualified target Jenkins instances from all available Jenkins instances. The specific selection strategy can be flexibly configured according to the task type and actual needs. For example, if the task type of the task request has certain requirements for the Jenkins instance, the target Jenkins instance is determined based at least on the task type and multi-dimensional attribute information. If the task type of the task request is a routine task without requirements for the Jenkins instance, the target Jenkins instance can be determined based on the task type and the instance health score of each Jenkins instance. If the task type of the task request has certain requirements for the Jenkins instance, and there are multiple Jenkins instances that meet the requirements, the target Jenkins instance is determined jointly based on the instance health score, task type, and multi-dimensional attribute information. In some cases, the target Jenkins instance can also be determined based on the instance health score and multi-dimensional attribute information.

[0089] Step S108: Schedule the task request to each target Jenkins instance.

[0090] Optionally, the server sends the task request to the selected target Jenkins instance, triggering the actual task build or operation process. It can be understood that if multiple target Jenkins instances are selected, for example, for tasks that need to be executed in parallel, the task request is sent to each target Jenkins instance separately.

[0091] In the aforementioned task scheduling method for multiple Jenkins instances, in response to task requests, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained. The task request carries the corresponding task type, serving as the data basis for subsequent task scheduling. Then, based on the multi-dimensional attribute information, the instance health score of each Jenkins instance is determined, quantifying the current overall health level and suitability for task execution of the Jenkins instance. Further, based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information, the target Jenkins instance is determined from all Jenkins instances, thereby scheduling the task request to the target Jenkins instance. By introducing a multi-dimensional attribute information collection and comprehensive scoring mechanism, dynamic evaluation and unified management of cross-cluster Jenkins instances are achieved, solving the problem of resource idleness and task backlog caused by the lack of a global view in related technologies. By scheduling based on factors such as real-time load and tag matching, the overall utilization rate of cross-cluster resources is improved. At the same time, by routing task requests to the most suitable target Jenkins instance, the risk of task failure due to version incompatibility or hardware incompatibility is reduced.

[0092] In one exemplary embodiment, such as Figure 2 As shown, the target Jenkins instance is determined from all Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information, including:

[0093] Step S202: Based on the task type of the task request and various preset task routing strategies, determine the target task routing strategy that matches the task type.

[0094] The task type and task routing strategy are pre-configured with corresponding matching relationships.

[0095] Among them, task routing strategy can refer to the set of rules that the server follows when scheduling tasks, including strategies such as load balancing, tag matching, and version compatibility.

[0096] Optionally, the server pre-configures various task routing strategies, such as load balancing, tag-priority, and version-strict strategies. Each routing strategy corresponds to different selection logic and applicable scenarios. The server then establishes a mapping relationship between task types and routing strategies. For example, regular code compilation tasks are mapped to a load balancing strategy; task types that require matching the necessary tag and otherwise reject routing are mapped to a tag-priority strategy, such as GPU (Graphics Processing Unit) build tasks; and task types that require the Jenkins instance version to be completely consistent with the API version requested by the task and are used for compatibility testing scenarios are mapped to a version-strict strategy. When the server receives a task request, it looks up the target task routing strategy corresponding to the task type from the mapping relationship based on the task type it carries.

[0097] Step S204: Determine the target Jenkins instance from all Jenkins instances based on the target task routing policy, instance health score, and at least two of the multi-dimensional attribute information.

[0098] Optionally, the server uses the target task routing strategy as the framework for selection logic, combining instance health scores and multi-dimensional attribute information to perform specific Jenkins instance screening. For example, if the target task routing strategy is a load balancing strategy, the server may primarily sort based on instance health scores and select one or more Jenkins instances with the highest scores; if the target task routing strategy is a tag priority strategy, the server may first filter Jenkins instances based on tag attributes, and then select the best from the filtered candidate set based on instance health scores.

[0099] In this embodiment, by introducing a mapping between task types and routing policies, the task-differentiated adaptation of the scheduling logic is achieved, enabling the server to dynamically adjust the selection criteria according to the specific needs of the task, thus avoiding the adaptation problems caused by a one-size-fits-all scheduling approach. At the same time, the configurability of the policy provides maintenance personnel with flexible control methods, allowing them to adjust scheduling behavior according to business changes, thereby improving the flexibility of task scheduling.

[0100] In one exemplary embodiment, such as Figure 3 As shown, step S204 determines the target Jenkins instance from all Jenkins instances based on the target task routing policy, instance health score, and at least two of the multi-dimensional attribute information, including:

[0101] Step S302: If the task routing strategy belongs to the first type of preset strategy, based on the multi-dimensional attribute information of each Jenkins instance, determine the candidate Jenkins instance whose multi-dimensional attribute information matches the first type of preset strategy from all Jenkins instances.

[0102] Among them, the multi-dimensional attribute information and the first type of preset strategy have corresponding matching relationships.

[0103] The first type of preset strategy can refer to a routing strategy that focuses on matching specific attributes of an instance, such as a tag matching strategy and a version compatibility strategy. Under this type of strategy, candidate Jenkins instances that match multi-dimensional attribute information (such as tags and versions) with preset conditions need to be selected.

[0104] Optionally, when the task routing strategy belongs to the first type of preset strategy, the server determines the candidate Jenkins instances whose multi-dimensional attribute information matches the first type of preset strategy from all Jenkins instances based on the multi-dimensional attribute information of each Jenkins instance. For example, when the target task routing strategy is the tag priority strategy, the server first filters all Jenkins instances according to the tag requirements carried in the task request, such as "gpu=true" and "environment=production". Only Jenkins instances whose tag fields in the multi-dimensional attribute information completely match the requirements will be included in the candidate set as candidate Jenkins instances.

[0105] Step S304: If the number of candidate Jenkins instances is less than or equal to the number of Jenkins instances required by the task request, the candidate Jenkins instances are determined as the target Jenkins instances.

[0106] Optionally, the task request may specify the number of Jenkins instances to be scheduled. If the number of candidate Jenkins instances is less than or equal to the number of Jenkins instances required by the task request, the server will directly determine the candidate Jenkins instances as the target Jenkins instances. For example, if one Jenkins instance is required to execute the task or three Jenkins instances are required to execute in parallel, and if the number of candidate Jenkins instances does not exceed the number of instances required, then all candidate instances will be directly determined as the target instances.

[0107] Step S306: If the number of candidate Jenkins instances is greater than the number of Jenkins instances required by the task request, the target Jenkins instance is determined from the candidate Jenkins instances based on the instance health score of each candidate Jenkins instance.

[0108] Optionally, if the number of candidate Jenkins instances exceeds the number of Jenkins instances required by the task request, the server sorts the candidate Jenkins instances according to their instance health scores, and determines the target Jenkins instance from among the candidate Jenkins instances in order of their instance health scores, such as selecting the top N instances with the highest scores (N equals the number of instances required) as the target Jenkins instance.

[0109] In this embodiment, the label priority strategy is accurately executed through a two-stage selection logic of filtering first and then selecting the best. First, it ensures that the task is scheduled to a Jenkins instance that meets the mandatory requirements such as hardware and environment, thus satisfying the rigid requirements of the task. On the basis of satisfying the rigid requirements, a flexible selection is performed through health score, which ensures that the target Jenkins instance with the best current state is selected when the conditions are met, thus achieving a balance between constraints and performance optimization.

[0110] In an exemplary embodiment, step S204 determines the target Jenkins instance from all Jenkins instances based on at least two of the target task routing policy, instance health score, and multi-dimensional attribute information, including:

[0111] When the task routing strategy belongs to the second type of preset strategy, the target Jenkins instance is determined from all Jenkins instances based on the instance health score of each Jenkins instance.

[0112] The second type of preset strategy can refer to a routing strategy that focuses on the instance's running load status, such as a load balancing strategy. Under this type of strategy, the target Jenkins instance is determined directly based on the instance health score (based on load, queue, etc.).

[0113] Optionally, if the task routing strategy falls under the second type of preset strategy, such as a load balancing strategy, the server directly determines the target Jenkins instance from all Jenkins instances based on the instance health score of each Jenkins instance. Specifically, the server sorts all available Jenkins instances from highest to lowest according to their instance health scores and selects one or more instances with the highest scores (based on the number of tasks required) as the target Jenkins instances. Instance health scores play a core role in this type of strategy, and the score itself already integrates multiple indicators such as load information and response latency. Therefore, selecting target Jenkins instances based on score sorting is equivalent to achieving load balancing based on comprehensive health.

[0114] In this embodiment, a simplified selection logic is used to achieve efficient load balancing for routine tasks without special requirements. This avoids complex multiple filtering conditions, reduces computational overhead, and improves the response speed of scheduling decisions. At the same time, since the instance health score has a built-in load factor, the sorting based on the instance health score naturally guides task requests to the target Jenkins instance with a lower current load and better status, achieving cross-cluster load balancing and avoiding the problem of some instances being overloaded while other instances are idle.

[0115] In one exemplary embodiment, scheduling task requests to target Jenkins instances includes:

[0116] Determine the target application interface type that the target Jenkins instance is compatible with; based on the target application interface type and the preset plugin compatibility matrix, schedule task requests to each target Jenkins instance.

[0117] The plugin compatibility matrix refers to mapping data that describes the compatibility relationship between Jenkins instance version, API type and plugin set, and is used to ensure that the API of the target Jenkins instance can correctly handle plugin-related calls during task scheduling.

[0118] Understandably, different versions of Jenkins instances have different APIs. For example, when creating a task, Jenkins instance version 2.401 requires the Jenkins-Crumb header to prevent Cross-Site Request Forgery (CSRF), while Jenkins instance version 2.414 requires authentication using a Bearer Token, and version 2.426 may require a specific version header. Furthermore, different plugin versions may also have API differences. The system needs to identify the version information of the target Jenkins instance and determine its specific compatible API call format.

[0119] Optionally, the server maintains a plugin compatibility matrix, which records the API differences and handling rules for different versions of Jenkins instances and their plugins. For example, for the git-plugin plugin, versions 4.12 and above support the includeUserMetadata parameter, while older versions do not support this parameter and must be ignored. For the kubernetes-plugin plugin, versions 3937 and above support dynamic Pod (container group) templates, while older versions only support static XML configuration.

[0120] Optionally, when scheduling task requests, the server queries the plugin compatibility matrix based on the version information of the target Jenkins instance to obtain the API calling rules corresponding to the target Jenkins instance. Then, it dynamically converts the unified and standardized task request format of the upper layer into an API calling format compatible with the target version before actually sending it to the target Jenkins instance. The conversion process includes, but is not limited to, adding or modifying HTTP (Hypertext Transfer Protocol) headers, adjusting the name, format, or position of request parameters, modifying the structure or content of the request body, and selecting different API endpoint paths.

[0121] In this embodiment, by introducing an API adaptation mechanism, the API compatibility issue in a heterogeneous environment with multiple versions of Jenkins instances is resolved. The upper-level scheduling system of the server does not need to maintain independent calling logic for each version of Jenkins instance, thus realizing a unified scheduling interface. The dynamic adaptation mechanism enables the server to smoothly support the introduction of new versions of Jenkins instances and the retirement of old versions without modifying the core scheduling code. The plugin compatibility matrix further refines the adaptation granularity to the plugin level, solving the problem of inconsistent task execution caused by differences in plugin versions and improving the reliability and success rate of task scheduling.

[0122] In one exemplary embodiment, the task scheduling method for multiple Jenkins instances described above further includes:

[0123] Convert the instance configuration information of each Jenkins instance into a custom resource definition; then configure the custom resource definition to each Jenkins instance.

[0124] The instance configuration information can refer to various configuration data required for the Jenkins instance to run, including Job configuration, Node configuration, Plugin configuration, etc.

[0125] Here, Custom Resource Definition (CRD) can refer to a custom resource definition object in Kubernetes. In this embodiment, it is used to abstract the configurations of Jenkins Job, Node, Plugin, etc., into declarative Kubernetes resource objects.

[0126] Optionally, Jenkins configuration information includes, but is not limited to, task configuration, node configuration, plugin configuration, security configuration, and system settings. The server abstracts this configuration information into Kubernetes custom resource definitions. For example, the following custom resource definition types can be defined: JenkinsJob describes the configuration of a Jenkins task, including source code address, build trigger, build steps, etc.; JenkinsNode describes the configuration of a Jenkins agent node, including tags, startup method, runtime environment, etc.; JenkinsPlugin describes the plugins to be installed and their versions. Through custom resource definitions, the configuration originally stored in the Jenkins master node's local file system as XML files is transformed into structured, declarative YAML (a data serialization format) files. The specific YAML configuration file is applied to the target Jenkins instance. The server continuously monitors changes to the custom resource definition objects and automatically synchronizes the configuration to the corresponding Jenkins instance, realizing the distribution and effectiveness of the configuration.

[0127] In this embodiment, the configuration information of Jenkins instances is transformed from difficult-to-track XML files into versionable, reviewable, and rollbackable custom resource definitions, fundamentally solving the configuration drift problem. Through the unified abstraction of custom resource definitions, the configuration of all clusters and all Jenkins instances can be centrally managed, avoiding the inefficiency and error-proneness of manually reconfiguring through multiple web interfaces.

[0128] In one exemplary embodiment, the steps of the above embodiments to configure custom resource definitions to each Jenkins instance include:

[0129] Store custom resource definitions in a pre-created instance repository; retrieve the stored custom resource definitions from the instance repository using a continuous delivery workflow and configure them on each Jenkins instance.

[0130] In this context, the instance repository can refer to a versioned storage repository used to store custom resource definitions (CRDs) and configuration information for Jenkins instances, such as a Git repository.

[0131] Continuous delivery workflow can refer to a configuration management process based on the GitOps concept, which uses tools (such as ArgoCD or Flux) to automatically synchronize the configuration in the repository to the Kubernetes cluster, thereby achieving versioned, auditable, and rollback-enabled configuration management.

[0132] Optionally, the server stores all custom resource definitions in a Git repository, forming an instance repository. All configuration changes are completed via Git commits, with each commit recording the author, time, and content of the change. The server integrates with continuous delivery tools (such as ArgoCD and Flux). When a custom resource definition in the instance repository changes, the continuous delivery tool automatically detects the change and synchronizes the latest configuration to the Kubernetes cluster, forming a continuous delivery workflow. After the controllers deployed on each cluster detect changes to the custom resource definition objects, they call the Jenkins API to apply the configuration to the corresponding Jenkins instance, completing the configuration distribution.

[0133] In this embodiment, declarative management of configuration is achieved through custom resource definitions and continuous delivery workflows. Custom resource definitions are stored in the instance version repository for unified management. Combined with GitOps continuous delivery workflows, configuration changes can be automatically and reliably synchronized to all target instances, realizing large-scale and automated distribution of configurations, significantly improving management efficiency. All configuration changes are recorded in the instance version repository, forming a complete audit trail, which meets the compliance audit requirements of industries such as finance and government.

[0134] In one exemplary embodiment, the task scheduling method for multiple Jenkins instances described in any of the above embodiments further includes:

[0135] If a failure is detected in any target Jenkins instance, the steps are returned to determine the target Jenkins instance from all Jenkins instances based on at least two of the instance health score, task type of the task request, and multi-dimensional attribute information, so as to obtain the updated target Jenkins instance; and the task requests of the target Jenkins instance are scheduled to the updated target Jenkins instance.

[0136] Optionally, the server continuously monitors the health status of all Jenkins instances. When a failure is detected in a target Jenkins instance that is executing a task or has been assigned a task, such as instance crash, network partition, response timeout, or memory overflow, the server automatically triggers a rescheduling process. This process returns to the step of determining the target Jenkins instance from all Jenkins instances based on at least two of the instance health score, task type of the task request, and multi-dimensional attribute information. The server then reschedules task requests that were originally planned to be sent to the failed Jenkins instance, or those that were sent but not completed, to the newly selected target Jenkins instance for execution. Understandably, for tasks that have already been partially executed, the server can choose to restart or attempt to resume from the breakpoint, if the task itself supports this.

[0137] In this embodiment, a fault monitoring and automatic rescheduling mechanism is introduced to realize automatic task failover. When a Jenkins instance fails, the server can automatically detect it in a short time and switch the task to other healthy Jenkins instances for execution. This avoids long-term interruptions to the continuous integration / continuous deployment pipeline caused by single point of failure, and significantly improves the system's business continuity and fault tolerance. Compared with manual intervention recovery in related technologies, this embodiment significantly reduces fault recovery time and realizes automated operation and maintenance.

[0138] In an exemplary embodiment, step S104 determines the instance health score of each Jenkins instance based on the multi-dimensional attribute information, including:

[0139] Based on the health status data included in the multi-dimensional attribute information of each Jenkins instance, the penalty coefficient of each Jenkins instance is determined; based on the penalty coefficient of each Jenkins instance, the multi-dimensional attribute information, and the preset weight values ​​corresponding to the multi-dimensional attribute information, the instance health score of each Jenkins instance is determined.

[0140] Among them, health status data can refer to real-time data reflecting the health status of the Jenkins instance, including build metrics, queue length, executor utilization, node status, etc.

[0141] The penalty coefficient can be a deduction factor set based on health status data (such as negative states like failure, offline, and high load) when calculating the health score of a Jenkins instance, used to reduce the score of instances with risks.

[0142] The preset weight value refers to the importance value pre-assigned to different multi-dimensional attribute information (such as load, tag, version, etc.) in the weight scoring algorithm of the intelligent routing engine.

[0143] Optionally, health status data includes whether the instance is online, whether it is faulty, and whether it is in a degraded state. The server determines a penalty coefficient for each instance based on this data. For example, if the instance is in a fully healthy state (online, fault-free), the penalty coefficient is 1.0; if the instance is in a degraded state (e.g., insufficient disk space, increased response latency), the penalty coefficient is 0.5 or 0.7; if the instance is in an unhealthy state (offline, downtime), the penalty coefficient is 0. The penalty coefficient acts as a multiplier factor to discount or reset the instance's overall score. The server first calculates a base score by weighting and summing various indicators (such as load, tag matching, version compatibility, and geographical location) in the multi-dimensional attribute information of each Jenkins instance, as well as the preset weight values ​​corresponding to the attribute information of each dimension. Then, the base score is multiplied by the penalty coefficient to obtain the final instance health score. In an exemplary embodiment, the weight allocation can be: load weight 40%, tag matching weight 30%, version compatibility weight 20%, geographical location weight 10%, and a total score of 0-100. The penalty coefficient is used to reflect the health status of the instance, and the total score is the product of the base score and the penalty coefficient.

[0144] This embodiment introduces a penalty coefficient, using the health status of the Jenkins instance as a key factor in the scoring calculation. This allows the instance health score to accurately reflect the true availability of the Jenkins instance. When a Jenkins instance fails or is in a degraded state, the penalty coefficient automatically reduces its instance health score to zero or significantly lowers it, thus effectively excluding it from the scheduling process. This avoids scheduling tasks to Jenkins instances that are about to crash or have already failed, further improving the success rate of task execution and the overall reliability of the system.

[0145] In one exemplary embodiment, such as Figure 4 As shown, a task scheduling system for multiple Jenkins instances is provided. The system includes a management layer and multiple cluster agent layers (such as...). Figure 4 In the cluster agent layer (1-n, where n is a positive integer), the management layer communicates with each cluster agent layer, and each cluster agent layer is deployed on a different cluster (e.g., ...). Figure 4 In the cluster (1-n), the cluster agent layer communicates and connects with each Jenkins instance in each cluster;

[0146] The management layer responds to task requests by obtaining multi-dimensional attribute information for each of the multiple Jenkins instances from at least two different clusters from the cluster proxy layer; the task request carries the corresponding task type; based on the multi-dimensional attribute information of each Jenkins instance, the instance health score corresponding to each Jenkins instance is determined; based on at least two of the instance health score, the task type of the task request, and the multi-dimensional attribute information, the target Jenkins instance is determined from all Jenkins instances, and the task request and the target Jenkins instance are sent to the cluster proxy layer corresponding to the target Jenkins instance.

[0147] The cluster proxy layer is used to collect multi-dimensional attribute information of each Jenkins instance in its cluster and send the multi-dimensional attribute information to the management layer, as well as to respond to task requests and target Jenkins instances by scheduling task requests to the target Jenkins instance.

[0148] For example, the management layer includes a unified API gateway, a configuration center, and an intelligent routing engine.

[0149] The unified API gateway provides a single entry point, shielding the complexity of underlying multi-cluster architectures. It supports both RESTful (Representational State Transfer, a software architecture style) and gRPC (Google Remote Procedure Call) protocols. The unified API gateway's interface design specifications include RESTful APIs adhering to the OpenAPI 3.0 standard, and gRPC using Protocol Buffers to define service contracts. It supports OAuth 2.0 (Open Authorization 2.0) Client Credentials Grant and Authorization Code Grant processes, and JWT (JSON Web Token) tokens containing a clusters field to limit access scope. Based on the token bucket algorithm, each enterprise tenant has a default of 1000 QPS (Queries Per Second), which can be dynamically adjusted. All API calls are recorded in Elasticsearch (a distributed search and analytics engine) and retained for 180 days, supporting traceability.

[0150] The configuration center uses ETCD 3.x (a distributed key-value storage system) as its storage backend, leveraging its Watch mechanism and transaction guarantees to achieve real-time distribution and atomic updates of configurations. The configuration center is deeply integrated with ArgoCD. When the CRD YAML file of the Git repository is updated, ArgoCD automatically synchronizes to ETCD, triggering the reconciliation loop of the Controller to achieve versioning, auditability, and automatic rollback of configurations.

[0151] The intelligent routing engine is a decision-making component that selects the optimal Jenkins instance to execute tasks based on multiple factors such as load balancing, tag matching, version compatibility, geographical location, and affinity policies, using a weighted scoring algorithm. It employs a multi-factor weighted scoring algorithm, recalculating the instance health score every 5 seconds. Routing policy types include load-balanced (selecting the instance with the highest score for daily tasks), tag-preferred (forcing matching of required tags, otherwise rejecting routing, used for GPU builds and security compliance builds), and version-strict (requiring the instance version to be completely consistent with the API version requested by the Job, used for compatibility testing scenarios).

[0152] The cluster proxy layer can be deployed as a middleware component within each Kubernetes cluster. It shields the details of multiple Jenkins instances within the cluster, providing a unified gRPC / REST interface upwards and managing instance lifecycles and API calls downwards. The management layer and the cluster proxy layer are connected via a gRPC / HTTPS (Hypertext Transfer Protocol Secure) communication channel, a high-performance, bidirectional streaming, TLS (Transport Layer Security) encrypted communication link used for API calls, event push notifications, and heartbeat detection. It supports connection pooling and automatic reconnection mechanisms. The cluster proxy layer includes an API adapter and an event collector.

[0153] The API adapter dynamically identifies the Jenkins instance version number, automatically converting API requests in a unified upper-layer format into a call format compatible with the target version. This handles version compatibility issues such as CSRF crumbs, authentication tokens, and endpoint differences, while also reducing API call latency. Specifically, its version identification mechanism involves obtaining the version number via GET / api / json?tree=version upon initial connection, caching it in local memory (the cache or data is valid for 1 hour), and Jenkins proactively notifying the user of version changes via Webhook (an event-triggered callback mechanism). For API differences between different plugin versions, the adapter incorporates a plugin compatibility matrix. For example, git-plugin v4.12+ supports the includeUserMetadata parameter, while older versions ignore this parameter. kubernetes-plugin v3937.vd_0a_e82e091b_b_1 supports dynamic Pod templates, while older versions only support static XML configuration.

[0154] The event collector connects to the Jenkins instance via WebSocket, reducing state synchronization latency.

[0155] Specifically, a bidirectional communication channel based on gRPC / HTTPS is established between the management layer and multiple Jenkins clusters. The channel supports mTLS (Mutual Transport Layer Security) bidirectional authentication and connection pool reuse. API adapters deployed in each cluster automatically identify the version information of Jenkins instances and dynamically convert unified format API requests from the upper layer into a version-compatible calling format based on a version mapping table. Instances are ranked in real-time using a weighted scoring algorithm based on multi-dimensional factors such as load, tags, version compatibility, and geographical location, and the optimal instance is selected to execute tasks. Jenkins configuration is abstracted as a Kubernetes Custom Resource Definition (CRD), and versioned management and automatic synchronization of configurations are achieved through declarative APIs and GitOps workflows. Millisecond-level bidirectional state synchronization between the management layer and the instance layer is achieved through WebSocket (WebSocket Protocol) long connections and an event bus.

[0156] In this embodiment, the management layer provides a unified dashboard (visual monitoring interface) that allows real-time viewing of cross-cluster build queues, executor usage, and node health. It supports multi-dimensional filtering by cluster, department, and project, resolving the information silo problem. When a Jenkins Master fails due to OOM (Out Of Memory) or network partitioning, the health checker marks it as unhealthy within 15 seconds, and the routing engine automatically routes new tasks to a standby instance. This has been verified in a production environment to tolerate N-1 Master failures. All configuration changes are approved through a Git PR (Pull Request) process, automatically synchronized after merging, and configuration history is traceable back to code commits. It supports `kubectl rollout undo` (command-line tool release / update / rollback) to roll back to any historical version, improving the success rate of plugin upgrades. Tenant isolation is achieved through Kubernetes Namespaces and RBAC (Role-Based Access Control). Each tenant can only manage its authorized clusters and jobs. API tokens are issued per tenant, supporting the principle of least privilege. It integrates with ClusterAutoscaler to automatically scale up Slave nodes when the build queue continuously exceeds the threshold, and automatically scales down when the queue is empty, saving cloud resource costs.

[0157] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0158] Based on the same inventive concept, this application also provides a multi-Jenkins instance task scheduling apparatus for implementing the multi-Jenkins instance task scheduling method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more multi-Jenkins instance task scheduling apparatus embodiments provided below can be found in the limitations of the multi-Jenkins instance task scheduling method described above, and will not be repeated here.

[0159] In one exemplary embodiment, such as Figure 5 As shown, a task scheduling device 500 for multiple Jenkins instances is provided, including: a task response module 501, a health scoring module 502, an instance filtering module 503, and a task scheduling module 504, wherein:

[0160] The task response module 501 is used to respond to task requests and obtain multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters; the task request carries the corresponding task type.

[0161] The health score module 502 is used to determine the instance health score of each Jenkins instance based on various multi-dimensional attribute information.

[0162] The instance filtering module 503 is used to determine the target Jenkins instance from all Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information.

[0163] The task scheduling module 504 is used to schedule task requests to each target Jenkins instance.

[0164] Furthermore, in one embodiment, the instance filtering module 503 is also used to determine a target task routing strategy that matches the task type based on the task type of the task request and multiple preset task routing strategies; the task type and the task routing strategy have a pre-set corresponding matching relationship; and the target Jenkins instance is determined from all Jenkins instances based on the target task routing strategy, instance health score, and at least two of the multi-dimensional attribute information.

[0165] Furthermore, in one embodiment, the instance filtering module 503 is further configured to, when the task routing strategy belongs to the first type of preset strategy, determine, from all Jenkins instances, candidate Jenkins instances whose multi-dimensional attribute information matches the first type of preset strategy based on the multi-dimensional attribute information of each Jenkins instance; the multi-dimensional attribute information and the first type of preset strategy have a pre-set corresponding matching relationship; when the number of candidate Jenkins instances is less than or equal to the number of Jenkins instances required by the task request, the candidate Jenkins instances are determined as target Jenkins instances; when the number of candidate Jenkins instances is greater than the number of Jenkins instances required by the task request, the target Jenkins instance is determined from each candidate Jenkins instance based on the instance health score of each candidate Jenkins instance.

[0166] Furthermore, in one embodiment, the instance filtering module 503 is also used to determine the target Jenkins instance from all Jenkins instances based on the instance health score of each Jenkins instance when the task routing strategy belongs to the second type of preset strategy.

[0167] Furthermore, in one embodiment, the instance filtering module 503 is also used to determine the target application interface type adapted to the target Jenkins instance; and to schedule task requests to each target Jenkins instance according to the target application interface type and a preset plugin compatibility matrix.

[0168] Furthermore, in one embodiment, the task scheduling device 500 for multiple Jenkins instances further includes an instance configuration module, used to convert the instance configuration information of each Jenkins instance into a custom resource definition; and to configure the custom resource definition to each Jenkins instance.

[0169] Furthermore, in one embodiment, the instance configuration module is also used to store custom resource definitions in a pre-created instance repository; extract the stored custom resource definitions from the instance repository through a continuous delivery workflow, and configure them to each Jenkins instance.

[0170] Furthermore, in one embodiment, the task scheduling module 504 is also configured to, upon detecting a failure in any target Jenkins instance, return the step of determining the target Jenkins instance from all Jenkins instances based on at least two of the instance health score, the task type of the task request, and multi-dimensional attribute information, to obtain the updated target Jenkins instance; and schedule the task requests of the target Jenkins instance to the updated target Jenkins instance.

[0171] Furthermore, in one embodiment, the health scoring module 502 is also used to determine the penalty coefficient of each Jenkins instance based on the health status data included in the multi-dimensional attribute information of each Jenkins instance; and to determine the instance health score of each Jenkins instance based on the penalty coefficient of each Jenkins instance, the multi-dimensional attribute information, and the preset weight value corresponding to the multi-dimensional attribute information.

[0172] The modules in the multi-Jenkins instance task scheduling device 500 described above can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can invoke and execute the operations corresponding to each module.

[0173] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores multi-dimensional attribute information, instance health scores, task types, and other data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When executed by the processor, the computer program implements a task scheduling method for multiple Jenkins instances.

[0174] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0175] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0176] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0177] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0178] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0179] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0180] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A task scheduling method for multiple Jenkins instances, characterized in that, The method includes: In response to a task request, multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters is obtained; the task request carries the corresponding task type. Based on the multi-dimensional attribute information, determine the instance health score of each Jenkins instance. The target Jenkins instance is determined from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information. The task requests are scheduled to the target Jenkins instances.

2. The method according to claim 1, characterized in that, The step of determining the target Jenkins instance from all Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information includes: Based on the task type of the task request and multiple preset task routing strategies, a target task routing strategy that matches the task type is determined; the task type and the task routing strategy have a pre-set matching relationship. The target Jenkins instance is determined from all the Jenkins instances based on the target task routing strategy, the instance health score, and at least two of the multi-dimensional attribute information.

3. The method according to claim 2, characterized in that, The step of determining the target Jenkins instance from all Jenkins instances based on at least two of the target task routing policy, the instance health score, and the multi-dimensional attribute information includes: When the task routing strategy belongs to the first type of preset strategy, based on the multi-dimensional attribute information of each Jenkins instance, candidate Jenkins instances whose multi-dimensional attribute information matches the first type of preset strategy are determined from all the Jenkins instances; the multi-dimensional attribute information and the first type of preset strategy have a pre-set corresponding matching relationship; If the number of candidate Jenkins instances is less than or equal to the number of Jenkins instances required by the task request, the candidate Jenkins instances will be determined as the target Jenkins instances. If the number of candidate Jenkins instances exceeds the number of Jenkins instances required by the task request, the target Jenkins instance is determined from the candidate Jenkins instances based on the instance health score of each candidate Jenkins instance.

4. The method according to claim 2, characterized in that, The step of determining the target Jenkins instance from all Jenkins instances based on at least two of the target task routing policy, the instance health score, and the multi-dimensional attribute information includes: When the task routing strategy belongs to the second type of preset strategy, the target Jenkins instance is determined from all the Jenkins instances based on the instance health score of each Jenkins instance.

5. The method according to claim 1, characterized in that, The step of scheduling the task request to each of the target Jenkins instances includes: Determine the target application interface type that the target Jenkins instance is compatible with; Based on the target application interface type and the preset plugin compatibility matrix, the task request is scheduled to each of the target Jenkins instances.

6. The method according to claim 1, characterized in that, The method further includes: Convert the instance configuration information of each Jenkins instance into a custom resource definition; Configure the custom resource definition to each of the Jenkins instances.

7. The method according to claim 6, characterized in that, The step of configuring the custom resource definition to each Jenkins instance includes: Store the custom resource definition in the pre-created instance version library; The custom resource definition is extracted from the instance repository through the continuous delivery workflow and configured into each of the Jenkins instances.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: If any of the target Jenkins instances is detected to have failed, the steps are returned to determine the target Jenkins instance from all the Jenkins instances based on at least two of the instance health score, the task type of the task request, and the multi-dimensional attribute information, so as to obtain the updated target Jenkins instance. The task request of the target Jenkins instance is scheduled to the updated target Jenkins instance.

9. The method according to any one of claims 1 to 7, characterized in that, The step of determining the instance health score of each Jenkins instance based on the multi-dimensional attribute information includes: Based on the health status data included in the multi-dimensional attribute information of each Jenkins instance, the penalty coefficient of each Jenkins instance is determined. The instance health score of each Jenkins instance is determined based on the penalty coefficient, the multi-dimensional attribute information, and the preset weight value corresponding to the multi-dimensional attribute information of each Jenkins instance.

10. A task scheduling system for multiple Jenkins instances, characterized in that, The system includes a management layer and multiple cluster agent layers. The management layer communicates with each of the cluster agent layers. Each cluster agent layer is deployed in a different cluster. Each cluster agent layer communicates with each Jenkins instance in each cluster. The management layer is used to respond to a task request by obtaining multi-dimensional attribute information corresponding to each of the multiple Jenkins instances from at least two different clusters from the cluster proxy layer; the task request carries a corresponding task type; based on the multi-dimensional attribute information of each Jenkins instance, an instance health score corresponding to each Jenkins instance is determined; based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information, a target Jenkins instance is determined from all the Jenkins instances, and the task request and the target Jenkins instance are sent to the cluster proxy layer corresponding to the target Jenkins instance. The cluster proxy layer is used to collect the multi-dimensional attribute information of each Jenkins instance in the cluster it is in, and send the multi-dimensional attribute information to the management layer, and in response to the task request and the target Jenkins instance, schedule the task request to the target Jenkins instance.

11. A management device for multiple Jenkins instances, characterized in that, The device includes: The task response module is used to respond to task requests and obtain multi-dimensional attribute information corresponding to multiple Jenkins instances from at least two different clusters; the task request carries the corresponding task type. The health scoring module is used to determine the instance health score of each Jenkins instance based on the multi-dimensional attribute information. The instance filtering module is used to determine the target Jenkins instance from all the Jenkins instances based on the instance health score, the task type of the task request, and at least two of the multi-dimensional attribute information. The task scheduling module is used to schedule the task requests to each of the target Jenkins instances.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images