Method and device for realizing dynamic scheduling of test tasks

Abstract

The invention relates to a method and a device for realizing dynamic scheduling of test tasks. The method comprises the following steps: receiving a test task, wherein the test task declares a computing resource demand required by execution; acquiring a real-time state of heterogeneous computing resources of each node in a cluster consisting of a plurality of test execution nodes; determining one or more target execution nodes for the test task through a predefined scheduling strategy according to the resource demand and the real-time state; respectively configuring dynamic state labels reflecting current available resources for the determined one or more target execution nodes; the continuous integration platform schedules the test task to one or more target execution nodes according to the dynamic state label; and executing the test task on one or more target execution nodes.

Description

Technical Field

[0001] This application generally relates to the field of artificial intelligence, and more specifically, to a method and apparatus for implementing dynamic scheduling of test tasks. Background Technology

[0002] In AI-driven software testing, testing tasks (such as model inference testing, algorithm accuracy verification, and large-scale dataset processing) typically consume significant computing resources. Currently, the industry widely uses continuous integration platforms (such as Jenkins) to manage automated testing processes. Summary of the Invention

[0003] This application provides a method and apparatus for dynamically scheduling test tasks. The invention utilizes a continuous integration platform as the core of the workflow orchestration, combined with a custom intelligent agent and testing framework, to achieve dynamic resource awareness, intelligent task distribution, and high-concurrency parallel testing across multiple test servers.

[0004] According to one aspect of this application, a method for dynamically scheduling test tasks is provided, comprising: receiving a test task that declares a requirement for computing resources to be executed; obtaining the real-time status of heterogeneous computing resources of each node in a cluster consisting of multiple test execution nodes; determining one or more target execution nodes for the test task according to the resource requirements and the real-time status, using a predefined scheduling strategy; configuring dynamic status labels reflecting the currently available resources of each of the determined one or more target execution nodes; scheduling the test task to the one or more target execution nodes by a continuous integration platform according to the dynamic status labels; and executing the test task on the one or more target execution nodes.

[0005] According to another aspect of this application, an apparatus for dynamically scheduling test tasks is provided, comprising: one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method described above. Attached Figure Description

[0006] Figure 1 The figure shows a schematic diagram of the overall architecture of a dynamic scheduling system for test tasks according to an embodiment of this application.

[0007] Figure 2 The illustration shows a flowchart of a method for dynamically scheduling test tasks according to an embodiment of this application.

[0008] Figure 3 A schematic diagram of a test task dynamic scheduling device according to an embodiment of this application is shown. Detailed Implementation

[0009] The features and exemplary embodiments of various aspects of this application will now be described in detail. Numerous specific details are provided in the following detailed description to provide a thorough understanding of this application. However, it will be apparent to those skilled in the art that this application can be implemented without some of these specific details. The following description of embodiments is merely intended to provide a better understanding of this application by illustrating examples. This application is by no means limited to any specific configurations and algorithms described below, but rather covers any modifications, substitutions, and improvements to elements, components, and algorithms without departing from the spirit of this application. Well-known structures and techniques are not shown in the accompanying drawings and the following description in order to avoid unnecessarily obscuring this application.

[0010] In AI-driven software testing scenarios, testing tasks (such as model inference verification, algorithm accuracy evaluation, and large-scale dataset batch processing) typically have a high dependence on and consumption of computing resources, especially graphics processing units (GPUs). Currently, the commonly used test execution models in the industry face the following key bottlenecks: 1. Rigid resource allocation: Test tasks are often statically bound to specific physical servers or device groups, making it impossible to dynamically adjust based on the real-time load of cluster resources. This leads to unbalanced resource utilization, with some devices running at high loads continuously while others remain idle for extended periods.

[0011] 2. Weak resource status awareness: Traditional node tagging mechanisms based on platforms such as Jenkins can only achieve coarse-grained environment matching such as operating system and Java version, lacking the ability to perceive the specific and dynamically changing hardware resource status inside the server. For example, it cannot identify the specific model of the GPU, the real-time memory usage, and the exact number of available GPU devices, etc.

[0012] 3. Low efficiency of parallel execution: Although Jenkins itself supports multi-node parallelism and pipeline parallelism, when faced with a large number of heterogeneous test cases, there is still a lack of system-level solutions for how to achieve automated and intelligent task splitting and optimal distribution based on the different resource requirements of each test case (e.g., "requiring two GPU cards") and the current actual idle status of the cluster, which results in the parallel potential not being fully realized.

[0013] 4. Disjointed Test Environment Preparation Process: Artificial intelligence testing often relies on specific datasets, model versions, or software dependencies. In existing processes, environment preparation typically requires manual intervention or is performed independently of the task scheduling system. This not only increases operational complexity but also significantly prolongs the overall delay from test task submission to execution.

[0014] In view of this, this application provides a solution for dynamically scheduling and parallel testing of test tasks across multiple servers based on a continuous integration platform. This solution uses, for example, Jenkins as the core of process orchestration and task scheduling, combined with intelligent decision-making agents and resource-aware testing frameworks to construct an automated test resource scheduling and management system. By real-time sensing of the status of various heterogeneous computing resources in the test server cluster and intelligently distributing tasks according to task requirements and resource status, high-concurrency and high-efficiency parallel test execution is achieved. This systematically solves problems such as uneven resource utilization, unintelligent scheduling, and slow environment delivery, significantly improving the overall utilization rate of test resources and task execution efficiency.

[0015] The present application will now be described in further detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the application to these specific forms.

[0016] Figure 1 The diagram illustrates the overall architecture of a test task dynamic scheduling system 100 according to an embodiment of this application. Figure 1 As shown, the system 100 may include the following logical functional layers: a resource awareness layer 110, a scheduling decision layer 120, a task execution layer 130, and an intelligent analysis layer 140. It should be understood that in actual deployment, depending on specific needs, the system of this application may also include or integrate other functional layers or modules.

[0017] In the embodiments of this application, the resource awareness layer 110 is used to collect real-time status information of each test execution node (server). The data collection function of the resource awareness layer 110 can be jointly implemented by a monitoring agent deployed on each physical test execution node and a central data service responsible for aggregating and storing data. The monitoring agent can directly interact with the local hardware and operating system, while the central data service maintains a global resource view. The implementation of the resource awareness layer 110 can be flexibly designed and combined according to the requirements of real-time performance, system overhead, and reliability, and can adopt different modes according to the system operation phase. During the normal operation phase of the system, basic background monitoring can be maintained. For example, periodic data collection can be performed through active polling, that is, the monitoring agent deployed on the node actively queries the local system interface at a preset time interval (such as once per second). An event-driven collection mode can also be adopted to monitor specific system events to achieve instantaneous perception and reporting of key status changes (such as GPU memory threshold breakthrough). In addition, the agent can periodically send a survival signal containing a resource summary to the central data service in the form of regular heartbeats to maintain a basic health view of the cluster.

[0018] In one embodiment, the resource-aware layer 110 supports a precise acquisition mode triggered by test tasks. When the continuous integration platform receives a new test task, or the scheduling decision layer begins processing a scheduling request, it can immediately trigger a targeted, high-priority acquisition instruction based on the specific resource requirements of the task. For example, for a task that declares the need for "2 A100 GPUs," the scheduling decision layer 120 can immediately request the resource-aware layer 110 to obtain the latest, detailed status of all nodes with A100 GPUs (such as the real-time memory usage and computational utilization of each card). The central data service then issues instructions to the relevant node agents, which immediately perform a quick scan and prioritize reporting the target data. This task-triggered instruction-based acquisition ensures that the resource view on which the scheduling decision is based is the latest and most accurate snapshot at the time of task submission, greatly improving the real-time performance and accuracy of resource matching. Under normal circumstances, the central data service can also proactively issue such immediate acquisition instructions to specific agents. The aforementioned combination of "routine monitoring" and "task-triggered precise data collection" not only ensures the system's comprehensive resource perception capabilities but also optimizes the resource overhead of data collection actions, making data collection more purposeful and efficient. It should be understood that this application may employ any other applicable data collection method.

[0019] The resource awareness layer 110 collects real-time status information of each test execution node (server) in the manner described above. This information may include: detailed indicators of graphics processing unit (GPU) resources, such as the unique identifier (ID), model, driver version, computing utilization (GPU-Util), total video memory capacity, current video memory usage and free space, temperature, power consumption, and GPU resource usage of a specific process; load indicators of central processing unit (CPU) resources, such as overall load, utilization of each logical core, context switching frequency, and number of interrupts; usage of memory (RAM) resources, such as total capacity, used amount, cache size, available memory, and swap space usage; performance and capacity indicators of storage resources, such as total space of each disk or partition, used space, read / write input / output (IO) rate, and number of input / output operations (IOPS); and network interface status information, such as bandwidth usage, packet transmission and reception rate, and error count. In addition, the monitoring agent can also collect operating system-level information, such as the list of currently running processes, system startup time, and container instance status and resource quotas for container runtimes (such as Docker or containerd), etc.

[0020] In the embodiments of this application, the scheduling decision layer 120 is used to intelligently match the resource requirements of test tasks with the cluster's shared resource pool. The scheduling decision layer 120 can receive test tasks with attached resource requirement declarations and query the real-time status provided by the resource awareness layer. In the embodiments of this application, the scheduling decision layer is used to intelligently match the resource requirements of test tasks with the cluster's shared resource pool. This layer receives test tasks with attached resource requirement declarations and queries the real-time cluster status provided by the resource awareness layer as the basis for decision-making.

[0021] The scheduling decision layer 120 may include an intelligent agent (or scheduling decision service) and a dynamic tag manager that works in conjunction with it. The intelligent agent may include a scheduling decision module that runs predefined or learnable scheduling strategy algorithms (such as those aimed at minimizing resource fragmentation or maximizing throughput) to calculate and determine the optimal task-node matching scheme. The dynamic tag manager serves as a key execution interface between the intelligent agent and the continuous integration platform, translating scheduling decision results into platform-recognizable control commands. Specifically, based on the target node information output by the decision module, it can perform full lifecycle management operations such as creating, updating, and removing dynamic status tags on the corresponding nodes by calling the application programming interface (API) of the continuous integration platform (such as Jenkins). This mechanism enables the platform to accurately understand and execute the abstract intelligent matching results, thereby driving the precise distribution of tasks to nodes with reserved resources.

[0022] In one embodiment, the scheduling decision layer 120 can execute the following dynamic decision-making process: when it is determined that there are sufficient resources in the current cluster to meet the task requirements, task distribution is performed, one or more target execution nodes are selected for the task, and resource conflicts are prevented by logically "reserving resources" for these nodes; conversely, when resources are temporarily insufficient, the test task is placed in a waiting queue until enough resources are released in the cluster. During this process, for example, a dynamic tag manager can generate temporary dynamic tags bound to the task based on the scheduling results to identify the reserved or allocated node resources.

[0023] In one embodiment, a typical dynamic tag can take the format RESERVE_ResourceType_Quantity_TaskID_UniqueSuffix, such as RESERVE_GPU_A100_2_JOB_12345_ABC12. This tag explicitly encodes the resource type (A100 GPU), the reserved quantity (2), the associated unique task identifier (JOB_12345), and a suffix that ensures global uniqueness. This design allows the tag to accurately reflect the reservation status calculated based on real-time resource conditions, rather than simply a static attribute.

[0024] The dynamic tag manager can perform strict full lifecycle management of these temporary tags. During the creation phase, upon receiving a scheduling decision instruction, the manager adds the generated specific dynamic tag to the target node by calling the application programming interface of the continuous integration platform (such as Jenkins), and marks the node as "reserved". At the same time, the manager firmly establishes a mapping relationship between "task ID-node-dynamic tag" internally or in the associated database, ensuring that the binding relationship is traceable.

[0025] During the cleanup and release phase, the dynamic tag manager ensures the temporary nature of tags through various mechanisms. For example, a trigger signal can come from the task execution completion event, typically sent proactively by a custom test framework running on the node after execution, indicating a "resource release." Upon receiving this signal, the manager immediately calls the platform API to remove the corresponding dynamic tag. Furthermore, the manager has safeguards: it periodically polls the platform to check the status of associated tasks; more importantly, it presets a time-to-live (TTL) for each dynamic tag. Even if the proactive notification fails to arrive for any reason, the TTL expiration will trigger forced cleanup, thus completely avoiding resource lock-up or "zombie reservations" due to unexpected situations, ensuring the long-term availability of cluster resources. In highly concurrent scenarios, the manager can also implement anti-conflict mechanisms, such as serializing tag operations on specific nodes to prevent multiple tasks from competing for resources and causing duplicate allocation. All its operations are designed to be idempotent and include error recovery logic, ensuring eventual consistency of the system state even under abnormal conditions such as network fluctuations.

[0026] In the embodiments of this application, the task execution layer 130 is responsible for the specific implementation and result management of test tasks. This layer receives task distribution instructions from the scheduling decision layer and, relying on the scheduling capabilities of a continuous integration / continuous deployment platform (such as Jenkins), routes tasks to target nodes that have been configured with corresponding dynamic tags. On the nodes, the system uses containerization technology to create isolated execution environments for each task and supports the parallel execution of multiple test tasks. During task execution, this layer is responsible for coordinating and managing the testing process; after the task is completed, it automatically collects the execution logs, output data, and status codes of each task, integrates them to generate a structured test report, and feeds it back to the user or upstream system.

[0027] In embodiments of this application, the task execution layer 130 may include a continuous integration platform agent (e.g., Jenkins), which acts as the platform's execution endpoint on the compute node and is responsible for receiving and starting tasks. Furthermore, the task execution layer may also include: a container runtime (e.g., a Docker engine), responsible for quickly building and destroying isolated, environment-consistent container instances based on the task description; a resource locking and execution driver module, which, within the container or during the startup phase, is responsible for executing specific hardware resource allocation (e.g., specifying GPU devices via environment variables), driving test script execution, and monitoring the task execution status; and / or a result collector, responsible for automatically aggregating logs, artifacts, and exit status after the task is completed and formatting them into a report.

[0028] In the embodiments of this application, the intelligent analysis layer 140 provides the system with data-driven optimization capabilities. This layer continuously collects and stores historical data from the task execution layer, including task execution time, actual resource consumption, success rate, queuing time, etc. Through in-depth analysis of this data (such as trend analysis, bottleneck identification, and pattern mining), the intelligent analysis layer can evaluate the effectiveness of the current scheduling strategy and resource usage, and automatically generate specific optimization suggestions. These suggestions may involve adjusting scheduling algorithm parameters, setting resource warning thresholds, optimizing task priority rules, etc., and are provided to the scheduling decision layer in the form of feedback signals, thereby driving the entire system to continuously evolve towards a more efficient and intelligent direction. The intelligent analysis layer 140 may include the following functional modules: a data collection and storage module, responsible for collecting, cleaning, and storing time-series operational data from various layers (especially the task execution layer and resource awareness layer); an analysis engine, which, based on stored historical data, uses statistical analysis, machine learning models, and other methods to perform performance profiling, anomaly detection, and root cause analysis; a strategy optimizer, which automatically calculates or recommends optimization schemes for scheduling strategies and resource allocation rules based on the insights from the analysis engine; and a feedback executor, responsible for safely and controllably applying optimization suggestions to the scheduling decision layer or system configuration, completing the closed loop from analysis to optimization.

[0029] Each layer communicates with the others through clear interfaces, forming an enhanced closed loop of "collection-decision-execution-analysis-optimization". This architecture not only realizes the transformation of resources from static allocation to dynamic scheduling, but also systematically improves resource utilization, test throughput, and the overall adaptability of the system by introducing intelligent queuing mechanisms, parallel execution support, and data feedback optimization.

[0030] Figure 2 The illustration shows a flowchart of a method 200 for dynamically scheduling test tasks according to an embodiment of this application. This method 200 can be implemented collaboratively by a continuous integration platform, a dynamic scheduling system, and execution frameworks on each node. Figure 2As shown, method 200 may include the following steps S201-S206.

[0031] In step S201, a test task is received, which declares that it has the required computing resources to execute.

[0032] In embodiments of this application, this step can be performed by an intelligent agent of a dynamic scheduling system. The intelligent agent receives test tasks submitted from a continuous integration platform (such as Jenkins) or an external system and parses the detailed resource requirements declared in the task configuration. In embodiments of this application, the computing resource requirements may include at least the type, quantity, or performance requirements for heterogeneous resources such as graphics processing units (GPUs), memory, storage, or the number of central processing unit (CPU) cores. In embodiments of this application, the test task may be an application scenario with explicit and high-intensity computing resource requirements, such as inference testing of artificial intelligence models, training tasks, algorithm accuracy verification, and batch processing tasks of large-scale datasets. For such tasks, the resource requirement declaration typically needs to explicitly specify key indicators such as the required GPU model, quantity, and video memory size.

[0033] In step S202, the real-time status of the heterogeneous computing resources of each node in the cluster consisting of multiple test execution nodes is obtained. In the embodiments of this application, step S202 can be executed by the resource awareness layer 110. The resource awareness layer 110 may include a monitoring agent and a central data service deployed on each physical test server. The monitoring agent collects detailed local resource status in real time, such as: the ID, model, utilization rate, temperature, and video memory usage of each GPU card; CPU core load, memory usage, disk I / O, and remaining space, etc. This data is continuously reported to the central data service, which aggregates and forms a real-time, unified view of global resources for decision-making.

[0034] In step S203, based on the resource requirements of the test task (S201) and the real-time resource status of the cluster (S202), one or more target execution nodes are determined for the test task using a predefined scheduling strategy. In embodiments of this application, this step can be performed by the intelligent agent of the scheduling decision layer 120. The intelligent agent can query the global resource view obtained by the resource awareness layer and perform analysis and decision-making in conjunction with its built-in scheduling strategy algorithm. The scheduling strategy can set various optimization objectives, such as prioritizing the distribution of tasks to nodes that meet their resource requirements and have the most concentrated remaining resources after allocation, with the objective of "minimizing resource fragmentation"; or performing global optimization with the objective of "maximizing task throughput". After the decision is completed, the intelligent agent outputs a list of one or more optimal target execution nodes.

[0035] In the embodiments of this application, the scheduling strategy may include a variety of optimization objectives, such as prioritizing the distribution of tasks to nodes that meet their resource requirements and have the lowest current resource fragmentation, so as to improve the overall resource utilization of the cluster.

[0036] In step S204, dynamic status tags reflecting the resources currently reserved or available for that specific test task are configured for one or more identified target execution nodes. In embodiments of this application, this step can be performed by the dynamic tag manager of the scheduling decision layer 120. This manager receives scheduling decision results from the intelligent agent and issues control commands to the platform by calling the application programming interface (API, such as a REST API) provided by the continuous integration platform (such as Jenkins), adding or modifying tags for each target node. The dynamic status tags are temporary, their content generated based on real-time status and task requirements (e.g., dynamic-gpu-a100-2), and strictly associated with the execution lifecycle of the current test task. The tag indicates that the corresponding resource has been reserved, and the tag is automatically removed or updated after the task ends. This step is crucial for connecting intelligent decision-making and platform scheduling, and is typically implemented by calling the application programming interface (API) provided by the continuous integration platform (such as Jenkins).

[0037] In the embodiments of this application, the dynamic status label is a temporary label generated based on the real-time status and is associated with the execution lifecycle of the current test task. The dynamic status label can be removed or updated after the task ends.

[0038] In step S205, the continuous integration platform (e.g., Jenkins) automatically schedules test tasks to one or more target execution nodes that match the node's requirements based on the dynamic status tags configured on the node. In embodiments of this application, step S205 can be automatically completed by the continuous integration platform (e.g., Jenkins) as a process orchestration and execution engine. The platform manages all registered execution nodes and their tags. After receiving instructions from the intelligent agent and completing the dynamic tag configuration, the platform's built-in scheduler immediately distributes test tasks in the waiting queue whose requirements (declaring the need for a specific tag) match the newly configured dynamic tags on the node to the corresponding target nodes based on the native tag matching mechanism. This achieves seamless transformation of intelligent scheduling decisions into direct scheduling actions by the platform.

[0039] This step utilizes the label matching and scheduling mechanism of the CI platform, but the labels driving its decisions are dynamic, temporary, and precise, thus achieving accurate matching of intelligent scheduling results.

[0040] In step S206, the test task is executed on one or more target execution nodes. In embodiments of this application, this step can be performed by a custom test framework running on each node. Specifically, each custom test framework can be used for: 1. Environment Preparation: Based on the task description, use container technologies such as Docker to pull or build images containing specific test dependencies on the nodes, and start an isolated container execution environment to ensure dependency consistency and environment purity.

[0041] 2. Resource locking: After the container starts but before the test is executed, the specific physical resources (such as a specific GPU card) declared by the task are exclusively allocated and locked to the container through mechanisms provided by the operating system or hardware driver (for example, setting the NVIDIA_VISIBLE_DEVICES environment variable for the container).

[0042] 3. Task Execution and Feedback: Execute the test script within the prepared container and collect logs and results. Upon task completion (whether successful or not), the framework handles resource release, container cleanup, and sends a "resources released" signal to the resource awareness layer to update the global resource view promptly.

[0043] In the embodiments of this application, before or during this step, an isolated execution environment that matches the task requirements can be built based on container technology (such as Docker) to ensure dependency consistency and environment purity.

[0044] In the embodiments of this application, for large test suites, the test task can be divided into multiple test subtasks that can be executed independently, and these subtasks can be dynamically scheduled to multiple nodes and controlled to execute simultaneously, so as to achieve high-concurrency parallel testing and significantly shorten the overall test time.

[0045] In embodiments of this application, method 200 may further include an intelligent analysis step: collecting historical task execution data (such as execution time, actual resource consumption, failure records, etc.), and using this data to continuously optimize the scheduling strategy through machine learning algorithms, forming a closed-loop feedback, and continuously improving scheduling efficiency and resource utilization.

[0046] The technical solution provided in this application, through the implementation of a systematic dynamic scheduling and intelligent execution method, brings significant benefits: At the resource management level, it achieves fine-grained real-time monitoring and dynamic allocation of heterogeneous resources such as GPUs, fundamentally solving the problem of uneven utilization caused by static resource binding, and significantly improving the utilization efficiency and return on investment of expensive computing hardware. At the task execution level, through intelligent demand matching and automatic task decomposition parallel mechanisms, the execution time of large-scale test tasks is significantly reduced from the traditional several days to several hours, greatly improving test throughput and delivery speed. At the quality and reliability level, containerization technology provides an isolated, consistent, and customized runtime environment for each task, completely eliminating the impact of dependency conflicts and environmental differences on test results, ensuring high reliability of the testing process and reproducibility of results. At the system evolution level, it constructs a fully automated closed loop from resource awareness, intelligent decision-making, dynamic distribution, environment construction to execution feedback, and introduces data-driven continuous optimization capabilities, enabling the system to have intelligent characteristics of self-learning and self-optimization, and continuously improving overall scheduling efficiency and resource utilization.

[0047] Figure 3 A schematic diagram of a test task dynamic scheduling apparatus according to an embodiment of this application is shown. This test task dynamic scheduling apparatus is shown as a computing device 300, which can be used to execute the above-described test task dynamic scheduling method 200. Figure 3 As shown, computing device 300 may include bus 302 or other communication mechanism for transmitting information, and one or more hardware processors 304 coupled to bus 302 for processing information. The one or more hardware processors 304 may include, for example, one or more general-purpose microprocessors.

[0048] like Figure 3As shown, in some embodiments, computing device 300 may further include main memory 306 coupled to bus 302. Main memory 306 is used to store information and instructions executed by one or more processors 304, such as random access memory (RAM), cache, and / or other dynamic storage devices. Main memory 306 may also be used to store temporary variables or other intermediate information during the execution of instructions executed by one or more processors 304. When these instructions are stored in storage media accessible to one or more processors 304, they can cause computing device 300 to become a dedicated machine customized to perform the operations specified in the instructions. Storage device 308 may include non-volatile and / or volatile storage media. Non-volatile storage media may include, for example, optical discs or magnetic disks. Volatile storage media may include dynamic memory. Common forms of storage media may include, for example, floppy disks, hard disks, solid-state drives, magnetic tape, or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, DRAM, PROM, and EPROM, FLASH-EPROM, NVRAM, any other memory chip or cartridge, or their networking versions.

[0049] like Figure 3 As shown, in some embodiments, computing device 300 may further include one or more communication interfaces or network interfaces 310 coupled to bus 302. Network interface 310 may provide bidirectional data communication coupling to one or more network links connected to one or more networks. As another example, network interface 310 may be a local area network (LAN) card to provide data communication connectivity to a LAN-compatible (or WAN component communicating with a WAN) network. Wireless links may also be implemented.

[0050] The execution of certain operations can be distributed across processors rather than residing within a single machine, but rather deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0051] Each of the processes, methods, and algorithms described above may be embodied in code modules executed by one or more computer systems or computer processors including computer hardware, and may be fully or partially automated by these code modules. The processes and algorithms may be implemented partially or fully in dedicated circuit systems.

[0052] When the functions disclosed herein are implemented as software functional units and sold or used as stand-alone products, they may be stored in a processor-executable, non-volatile, computer-readable storage medium. Specific technical solutions (all or part) disclosed herein, or aspects contributing to the prior art, may be embodied in the form of a software product. The software product may be stored in a storage medium and includes several instructions that cause a computing device (which may be a personal computer, server, network device, etc.) to perform all or some steps of the methods of the embodiments of this application. The storage medium may include a flash drive, portable hard disk drive, ROM, RAM, magnetic disk, optical disk, other media operable to store program code, or any combination thereof.

[0053] Specific embodiments further provide an apparatus including a processor and a non-transitory computer-readable storage medium storing instructions executable by the processor to cause the apparatus to perform operations corresponding to steps in any method of the embodiments disclosed above. Specific embodiments further provide a non-transitory computer-readable storage medium storing instructions executable by one or more processors to cause the one or more processors to perform operations corresponding to steps in any method of the embodiments disclosed above.

[0054] The embodiments disclosed herein can be implemented via a cloud platform, server, or server cluster (collectively referred to below as the "Service System") that interacts with a client. The client can be a terminal device or a client registered by a user at the platform, wherein the terminal device can be a mobile terminal, a personal computer (PC), or any device that can have the platform application installed.

[0055] The various features and processes described above can be used independently of each other or combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this application. Additionally, certain method or process blocks may be omitted in some embodiments. The methods and processes described herein are not limited to any particular order, and their associated blocks or states may be executed in other suitable orders. For example, described blocks or states may be executed in an order other than that specifically disclosed, or multiple blocks or states may be combined into a single block or state. Example blocks or states may be executed sequentially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The exemplary systems and components described herein may be configured differently than described. For example, components may be added to, removed from, or rearranged compared to the disclosed example embodiments.

[0056] The various operations of the exemplary methods described herein can be performed at least in part by an algorithm. The algorithm may be included in program code or instructions stored in memory (e.g., the aforementioned non-transitory computer-readable storage medium). This algorithm may include a machine learning algorithm. In some embodiments, the machine learning algorithm may not explicitly refer to the computer as performing the function but may learn from training data to generate a predictive model of the function.

[0057] The various operations of the exemplary methods described herein can be performed, at least in part, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, these processors can constitute an engine of processor implementation that operates to perform one or more of the operations or functions described herein.

[0058] Similarly, the methods described herein may be implemented at least in part by a processor, wherein one or more specific processors are instances of hardware. For example, at least some operations of the methods may be performed by one or more processors or an engine implemented by a processor. Furthermore, one or more processors may also be operable to support the execution of relevant operations in a “cloud computing” environment or as the execution of relevant operations in a “Software as a Service” (SaaS) context. For example, at least some operations may be performed by a group of computers (as an example of a machine containing processors), wherein these operations are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., application programming interfaces (APIs)).

[0059] The execution of certain operations can be distributed across processors rather than residing within a single machine, and can be deployed across multiple machines. In some example embodiments, the processor or processor-implemented engine may reside in a single geographic location (e.g., in a home environment, office environment, or server farm). In other example embodiments, the processor or processor-implemented engine may be distributed across multiple geographic locations.

[0060] Throughout this specification, multiple instances may be implemented as components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of these individual operations may be performed simultaneously, and not necessarily in the order illustrated. Structures and functions presented as separate components in the example configuration may be implemented as composite structures or components. Similarly, structures and functions presented as single components may be implemented as single components. These and other variations, modifications, additions, and improvements fall within the scope of this document.

[0061] As used herein, "or" is inclusive rather than exclusive unless explicitly indicated by the context. Therefore, in this document, "A, B, or C" means "A, B, A and B, A and C, B and C, or A, B, and C" unless explicitly indicated by the context. Furthermore, "and" is combined and separate unless explicitly indicated by the context. Therefore, in this document, "A and B" means "A and B, combined or separate" unless explicitly indicated by the context. Additionally, multiple instances of resources, operations, or structures described herein may be provided as a single instance. Furthermore, the boundaries between various resources, operations, engines, and data storage devices are somewhat arbitrary and specific operations are illustrated within the context of a particular illustrative configuration. Other functional assignments are foreseeable and fall within the scope of various embodiments of this application. Generally, structures and functions presented as individual resources in example configurations may be implemented as combined structures or resources. Similarly, structures and functions presented as single resources may be implemented as single resources. These and other changes, modifications, additions, and improvements fall within the scope of the embodiments of this application as defined by the appended claims. Therefore, this specification and drawings should be considered illustrative rather than restrictive.

[0062] The terms “comprising” or “including” are used to indicate the presence of a subsequently claimed feature, but do not preclude the addition of other features. Unless otherwise specifically stated or otherwise understood in the context in which they are used, conditional language such as “may,” “can,” “may,” and “can” is generally intended to convey that certain embodiments include certain features, components, and / or steps that are not included in other embodiments. Therefore, this conditional language is generally not intended to imply that one or more embodiments require features, components, and / or steps in any way, or that one or more embodiments must include logic for determining whether such features, components, and / or steps are included in or performed in any particular embodiment, with or without user input or prompts.

[0063] Although the general outline of the subject matter has been described with reference to specific exemplary embodiments, various modifications and changes can be made to these embodiments without departing from the broad scope of embodiments of this application. Where more than one embodiment is disclosed, these embodiments of the subject matter may be referred to individually or collectively herein as the term "invention," this is for convenience only and is not intended to automatically limit the scope of this application to any single disclosure or concept.

[0064] The embodiments illustrated herein are described in detail to enable those skilled in the art to practice the disclosed teachings. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this application. Therefore, "implementation" is not intended to be limiting, and the scope of the various embodiments is defined only by the appended claims and their equivalents in their full scope.

Claims

1. A method for dynamically scheduling test tasks, characterized in that, The method includes: Receive a test task that declares its computational resource requirements for execution; Obtain the real-time status of heterogeneous computing resources of each node in a cluster consisting of multiple test execution nodes; Based on the computing resource requirements and the acquired real-time status, one or more target execution nodes are determined for the test task using a predefined scheduling strategy; Configure dynamic status labels reflecting the currently available resources for one or more target execution nodes; The continuous integration platform schedules the test tasks to the one or more target execution nodes based on the dynamic status tags; and The test task is executed on one or more target execution nodes.

2. The method according to claim 1, characterized in that, The continuous integration platform is the Jenkins platform.

3. The method according to claim 1 or 2, characterized in that, The testing tasks include artificial intelligence model inference testing, model training tasks, or algorithm verification tasks.

4. The method according to claim 1 or 2, characterized in that, The dynamic status label is a temporary label generated based on the real-time status and is associated with the execution lifecycle of the test task.

5. The method according to claim 1 or 2, characterized in that, The method further includes: The test task is broken down into multiple test sub-tasks that can be executed independently; Dynamically schedule the multiple test subtasks to one or more target execution nodes; Control the simultaneous execution of the multiple test subtasks on one or more target execution nodes.

6. The method according to claim 1 or 2, characterized in that, The computing resource requirements include the type, quantity, or performance requirements for at least one of the following resources: graphics processor, memory, storage, or number of central processing unit cores.

7. The method according to claim 1 or 2, characterized in that, The scheduling strategy includes distributing the test tasks to the test execution nodes that meet the computing resource requirements and have the lowest current resource fragmentation.

8. The method according to claim 1 or 2, characterized in that, The configuration of dynamic status labels is achieved by calling the application programming interface provided by the continuous integration platform.

9. The method according to claim 1 or 2, further comprising: Before executing the test task on one or more target execution nodes, an isolated execution environment matching the test task is constructed based on container technology.

10. The method according to claim 1 or 2, characterized in that, The method further includes: Collect historical task execution data and use the collected data to optimize scheduling strategies.

11. An apparatus for dynamically scheduling test tasks, characterized in that, The device includes: One or more processors; and A memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the method according to any one of claims 1-10.

Images