Task filtering method, device, apparatus and storage medium

Abstract

The application discloses a task filtering method and device, equipment and a storage medium, and relates to the technical field of computers. The method comprises the following steps: for a GPU-driven CI pipeline task, if a code merging request of the CI pipeline task is received, a change file list corresponding to the code merging request is acquired, the code merging request is used for requesting to merge change files in a source branch of the CI pipeline task into a target branch; according to the change file list, a full task list of the target branch is filtered to obtain a filtered task list corresponding to the target branch, and the filtered task list comprises CI test tasks and CI build tasks to be executed in the target branch; and the filtered task list is subjected to hardware matching filtering to obtain a final task list, and the hardware matching filtering is used for filtering tasks that do not meet hardware matching conditions. The application filters CI build tasks and CI test tasks irrelevant to the current change, thereby effectively saving computing resources.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a task filtering method, apparatus, device, and storage medium. Background Technology

[0002] During the development of software programs, it is necessary to perform CI (Continuous Integration) testing on the code to ensure its functional characteristics.

[0003] In related technologies, a code repository typically contains code for multiple hardware platforms (different ASIC (Application Specific Integrated Circuit) chip series), multiple operating systems (Windows / Linux), and multiple functionalities (graphics / computing / media, etc.). Therefore, the CI pipeline task triggered by each code merge request includes a large number of CI build tasks and CI test tasks, covering different combinations of chip platforms, different operating systems, and different functionalities.

[0004] However, each code merge request submitted using the above method triggers a full CI build task and a full CI test task, consuming a large amount of computing resources and testing time. Summary of the Invention

[0005] This application provides a task filtering method, apparatus, device, and storage medium. The technical solutions provided by this application are as follows: According to one aspect of the embodiments of this application, a task filtering method is provided, the method comprising: For a continuous integration (CI) pipeline task driven by a graphics processing unit (GPU), upon receiving a code merge request for the CI pipeline task, a list of change files corresponding to the code merge request is obtained. The list of change files includes at least one change file. The code merge request is used to request the merging of change files in the source branch of the CI pipeline task into the target branch. The change file is a file in the source branch that has been modified relative to the target branch. Based on the list of changed files, the full task list of the target branch is filtered to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch. The filtered task list is subjected to hardware matching filtering to obtain the final task list. The hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions.

[0006] According to one aspect of the embodiments of this application, a task filtering device is provided, the device comprising: The file acquisition module is used for a continuous integration (CI) pipeline task for a graphics processor (GPU) driver. Upon receiving a code merge request for the CI pipeline task, the module acquires a list of changed files corresponding to the code merge request. The list of changed files includes at least one changed file. The code merge request is used to request the merging of changed files in the source branch of the CI pipeline task into the target branch. The changed files are files in the source branch that have been modified relative to the target branch. The task filtering module is used to filter the full task list of the target branch according to the change file list to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch. The matching and filtering module is used to perform hardware matching filtering on the filtering task list to obtain the final task list. The hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions.

[0007] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described task filtering method.

[0008] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described task filtering method.

[0009] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being loaded and executed by a processor to implement the above-described task filtering method.

[0010] The technical solution provided in this application can bring the following beneficial effects: For GPU-driven CI pipeline tasks, upon receiving a code merge request, the system retrieves a list of change files corresponding to the merge request. Based on this list, it filters the full task list for the target branch to obtain a filtered task list. Furthermore, it performs hardware matching filtering on this filtered task list to arrive at the final task list. Compared to related technologies where submitting a code merge request triggers full CI build and full CI test tasks, the solution provided in this application automatically and accurately filters out CI build and CI test tasks unrelated to the current change from the full task list based on the change files in the merge request. This reduces the number of tasks triggered by a single code merge request, lowers computational resource consumption while maintaining quality, effectively saves computing resources, and reduces test machine usage time. Developers only need to wait for change-related tasks to complete, shortening the task execution feedback cycle and improving task execution iteration efficiency. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of a computer system provided in one embodiment of this application; Figure 2 This is a flowchart of a task filtering method provided in one embodiment of this application; Figure 3 This is a schematic diagram illustrating the matching process between a list of changed files and a list of directories provided in one embodiment of this application; Figure 4 This is a schematic diagram of a task filtering process provided in one embodiment of this application; Figure 5 This is a block diagram of a task filtering device provided in one embodiment of this application; Figure 6 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0013] Please refer to Figure 1 This illustration shows a schematic diagram of a computer system provided in one embodiment of this application. The computer system may include: a terminal device 10 and a server 20.

[0014] There may be one or more terminal devices 10. Terminal devices 10 may be electronic devices such as mobile phones, tablets, laptops, desktop computers, game consoles, e-book readers, multimedia playback devices, wearable devices, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc.

[0015] The terminal device 10 may have a client application for the target application installed. This target application has the function of testing CI pipeline tasks for GPU (Graphics Processing Unit) drivers. Users can trigger the CI pipeline task testing process within the target application and optimize the software program's development and application based on the test results. Optionally, the target application can be an application that requires downloading and installation, or it can be an application that is ready to use immediately; this application does not impose any limitations on this.

[0016] Server 20 provides background services for clients of the target application installed and running on terminal device 10. For example, server 20 can be a background server for the aforementioned target application. Server 20 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but is not limited to these. Optionally, server 20 can simultaneously provide background services for target applications on multiple terminal devices 10. Terminal devices 10 and server 20 can communicate with each other via a network.

[0017] In this embodiment, since each test process in related technologies triggers a full CI build task and a full CI test task, consuming significant computing resources and testing time, it is necessary to automatically and accurately filter CI build tasks and CI test tasks unrelated to the current code change based on the file paths of the code changes. This significantly reduces the resource consumption of continuous integration and shortens the feedback cycle while ensuring quality. The specific method includes the following steps: 1. For GPU-driven CI pipeline tasks, upon receiving a code merge request, obtain the list of change files corresponding to the code merge request of the CI pipeline task. The list of change files includes at least one change file. The code merge request is used to request the merging of change files in the source branch of the CI pipeline task into the target branch. The change files are the files in the source branch that have been changed relative to the target branch.

[0018] 2. Based on the list of changed files, filter the full task list of the target branch to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch.

[0019] 3. Perform hardware matching filtering on the filtered task list to obtain the final task list. Hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions. The final task list is the list of tasks to be executed in the test process, meaning that the test process will be executed according to the final task list.

[0020] Please refer to Figure 2 The diagram illustrates a flowchart of a task filtering method provided in one embodiment of this application. The execution entity for each step of the method can be a computer device. The method may include at least one of the following steps 210-230: Step 210: For GPU-driven CI pipeline tasks, upon receiving a code merge request, obtain the list of change files corresponding to the code merge request of the CI pipeline task. The list of change files includes at least one change file. The code merge request is used to request the merging of change files in the source branch of the CI pipeline task into the target branch. The change files are files in the source branch that have been modified relative to the target branch.

[0021] A merge request (MR) includes files from the source branch of the CI pipeline task. The source branch is a new branch that the merge request wants to merge into, while the target branch is an existing branch in the CI pipeline task, such as the master branch or release branch. The source branch includes at least one changed file, which is a file obtained by modifying files in the target branch; these are the files in the source branch that have been modified relative to the target branch. Therefore, upon receiving a merge request, a list of changed files corresponding to the merge request is obtained based on at least one changed file in the source branch.

[0022] For example, using a version control system (Git), changed files in the source branch that conform to the first naming rule are identified as CI configuration files, and other changed files in the source branch are identified as code files. The first naming rule is used to indicate the format of file names; for example, the first naming rule could be that the filename conforms to... The `.ciConfig.yaml` file contains rules. The CI configuration file specifies the execution rules for the target branch, such as the test content, test environment, and test rules within the CI pipeline. The code file specifies the functional code within the target branch, such as the driver code and test scripts within the CI pipeline. In simpler terms, the CI configuration file refers to the file that modifies the rules, and the code file refers to the file that modifies the code. Categorizing the CI configuration and code files in a code merge request allows for targeted determination of which tasks to execute later.

[0023] If the source branch does not contain a CI configuration file, the change file list will not include a CI configuration file, and at least one change file in the change file list will be a code file, meaning the change file list includes only at least one code file. If the source branch contains a CI configuration file, the change file list may include at least one CI configuration file and at least one code file, or it may include only at least one CI configuration file, meaning at least one change file in the change file list will be a CI configuration file.

[0024] Step 220: Based on the list of changed files, filter the full task list of the target branch to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch.

[0025] The full task list for the target branch includes all CI test tasks and all CI build tasks for the target branch. These tasks include CI test and build tasks relevant to the current code merge request, as well as CI test and build tasks unrelated to the current code merge request. Filtering the full task list for the target branch involves filtering tasks unrelated to the current code merge request from the change files in the change file list, resulting in the filtered task list for the target branch. This filtered task list includes the CI test and CI build tasks to be executed on the target branch. Optionally, the filtered task list may include only CI test tasks, only CI build tasks, or both.

[0026] In some embodiments, when the change file list includes a CI configuration file, the full task list of the target branch is filtered according to the CI configuration file to obtain a filtered task list corresponding to the target branch. The CI configuration file is used to indicate the task execution rules of the target branch.

[0027] If the list of changed files includes CI configuration files, it may or may not include code files. Based on at least one CI configuration file in the list of changed files, the impact of the CI configuration file modification on task execution is accurately identified. Tasks in the full task list of the target branch that are not affected by the CI configuration file modification are filtered to obtain the filtered task list corresponding to the target branch.

[0028] In some embodiments, if the change file list does not include CI configuration files, the full task list of the target branch is filtered based on at least one code file in the change file list to obtain a filtered task list corresponding to the target branch.

[0029] If the change file list does not include CI configuration files, but only includes at least one code file, then based on at least one code file in the change file list, the tasks that do not need to be executed in the full task list of the target branch are filtered to obtain the filtered task list corresponding to the target branch.

[0030] By performing different filtering steps in two cases—one with CI configuration files and one without—the test results of the CI pipeline tasks are not affected by missed tasks, and computing resources are not wasted by executing irrelevant tasks, thus effectively saving computing resources.

[0031] The specific filtering process for the full task list of the target branch can be found in the following example, and will not be described here.

[0032] Step 230: Perform hardware matching filtering on the filtered task list to obtain the final task list. Hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions.

[0033] Hardware matching is used to determine whether each CI test task in the filtering task list meets the hardware matching criteria. Hardware matching criteria refer to the condition that the chip series information and current operating system corresponding to the CI test task match at least one change file. Failure to meet hardware matching criteria means that the chip series information and current operating system corresponding to the CI test task do not match at least one change file. Hardware matching is performed on each CI test task and at least one change file in the filtering task list to determine whether each CI test task in the filtering task list meets the hardware matching criteria. CI test tasks in the filtering task list that do not meet the hardware matching criteria are then filtered to obtain the final task list.

[0034] The specific hardware matching filtering process for the filtering task list can be found in the following embodiments, and will not be described here.

[0035] The technical solution provided in this application, for GPU-driven CI pipeline tasks, upon receiving a code merge request for a CI pipeline task, obtains a list of change files corresponding to the code merge request, and filters the full task list of the target branch based on the change file list to obtain a filtered task list corresponding to the target branch. Furthermore, it performs hardware matching filtering on the filtered task list to obtain the final task list. Compared to related technologies where submitting a code merge request triggers full CI build and full CI test tasks, the technical solution provided in this application automatically and accurately filters out CI build and CI test tasks unrelated to the current change from the full task list based on the change files in the code merge request. This reduces the number of tasks to be executed in a single code merging request, reduces computational resource consumption while ensuring quality, effectively saves computational resources, and reduces test machine occupancy time. Developers only need to wait for tasks related to the change to complete, shortening the task execution feedback cycle and improving the iterative efficiency of task execution.

[0036] The filtering process in step 220 is described below, which is divided into two cases: the change file list includes CI configuration files and the change file list does not include CI configuration files.

[0037] In some embodiments, if the list of change files includes a CI configuration file, step 220 includes at least one of substeps 221 to 223.

[0038] Sub-step 221: Perform configuration difference detection on the CI configuration file to obtain the configuration difference detection result of the CI configuration file. The configuration difference detection result is used to indicate the types of fields that have changed in the CI configuration file.

[0039] The CI configuration file includes global configuration fields and test definition fields. Global configuration fields indicate the general execution rules for CI test tasks. For example, they can indicate the mapping relationship between the chip and the test machine, globally shared parameters for all CI test tasks, and global environment variables—the underlying configuration rules for general execution. Test definition fields indicate the specific execution rules for CI test tasks. For example, they can indicate which CI test tasks to execute and how each CI test task is executed. For instance, the test definition field can be the `test` field in the CI configuration file, and the global configuration fields can be non-`test` fields in the CI configuration file.

[0040] Configuration difference detection is used to detect the types of fields that have changed in the CI configuration file. The configuration difference detection result is used to indicate that the global configuration field in the CI configuration file has changed, or to indicate that the test definition field in the CI configuration file has changed, or to indicate that both the global configuration field and the test definition field in the CI configuration file have changed.

[0041] It is important to note that before performing configuration difference detection on the CI configuration file, it is necessary to read the original content of the CI configuration file in the source branch and the original content of the CI configuration file in the target branch respectively, without performing any template replacement, and directly perform raw YAML parsing without template replacement to ensure that the basis for comparison between the two sides is consistent and will not cause errors due to dynamically replaced content.

[0042] Sub-step 222: If the global configuration field in the CI configuration file changes, retain all CI test tasks in the full task list to obtain the filter task list corresponding to the target branch. The global configuration field is used to indicate the general execution rules of CI test tasks.

[0043] When the global configuration fields in the CI configuration file change, the test definition fields in the CI configuration file may or may not change. In this case, it can be assumed that the underlying configuration rules for task execution have changed, and the task execution is marked as "degraded mode." "Degraded mode" means that all CI test tasks in the full task list are retained. That is, regardless of what changes are made in the code merge request, all CI test tasks are executed as usual, avoiding the failure of tasks that should be executed due to changes in general execution rules, which would affect the task test results of the CI pipeline. Therefore, the filtered task list corresponding to the target branch is still the full task list of the target branch.

[0044] Sub-step 223: If only the test definition fields in the CI configuration file change, filter the full task list of the target branch based on the changed fields in the test definition fields to obtain the filtered task list corresponding to the target branch. The test definition fields are used to indicate the specific execution rules of the CI test tasks.

[0045] If only the test definition fields in the CI configuration file change, while the global configuration fields remain unchanged, it can be assumed that a specific execution rule for the task has changed. Therefore, the contents of the test definition fields in the source and target branches are compared one by one to identify the changed fields. These changed fields can be modified or newly added. The CI test tasks corresponding to these changed fields are marked as "Configuration Change Tests." "Configuration Change Tests" represent CI test tasks that are forcibly executed; other tasks unrelated to this configuration change do not need to be executed. Therefore, the full task list of the target branch, excluding the CI test tasks marked "Configuration Change Tests," is filtered to obtain a filtered task list for the target branch. This filtered task list includes all CI test tasks marked "Configuration Change Tests."

[0046] By performing configuration difference detection on CI configuration files, the types of fields that have changed in the CI configuration files can be identified. This allows for a precise assessment of the impact of CI configuration file modifications on task execution. When global configuration fields change, all CI test tasks are retained. When only test definition fields change, CI test tasks related to the configuration modification are retained. This avoids missing tasks that could affect the test results of the CI pipeline and also avoids executing irrelevant tasks that would consume additional computing resources.

[0047] In some embodiments, if the list of changed files does not include the CI configuration file, step 220 includes at least one of sub-steps 224-225.

[0048] Sub-step 224: Based on at least one code file, perform a disabled directory filter on the full task list to obtain a task list with the disabled directory filter. The disabled directory filter is used to determine whether all CI build tasks and CI test tasks in the full task list have been filtered.

[0049] In some embodiments, sub-step 224 includes at least one of sub-steps 2241 to 2243.

[0050] Sub-step 2241: Perform a disabled directory detection on at least one code file to obtain a disabled directory detection result for at least one code file. The disabled directory detection result is used to indicate whether at least one code file is located in a predefined disabled directory.

[0051] Disabled directories refer to directories containing files that should not be executed, including at least one directory containing files that should not be executed. Disabled directories include fully disabled directories and test disabled directories. Fully disabled directories contain files that should not be executed at all, including at least one directory containing files that should not be executed at all. Examples of fully disabled directories include documentation directories, CI configuration file template directories, and obsolete code directories. Test disabled directories contain files that only need to be compiled and not executed, including at least one directory containing files that only need to be compiled and not executed. Examples of test disabled directories include pure utility code and auxiliary script directories that do not affect functionality.

[0052] The disabled directory detection includes full disabled directory detection and test disabled directory detection. Full disabled directory detection determines whether at least one code file is located within a predefined full disabled directory. Specifically, it determines whether at least one code file belongs to a predefined full disabled directory based on its filename, yielding a full disabled directory detection result. This result indicates that at least one code file is located entirely within the predefined full disabled directory, partially within it, or outside of it. Test disabled directory detection determines whether at least one code file is located within a predefined test disabled directory. Similarly, it determines whether at least one code file belongs to a predefined test disabled directory based on its filename, yielding a test disabled directory detection result. This result indicates that at least one code file is located entirely within the predefined test disabled directory, partially within it, or outside of it.

[0053] Sub-step 2242: If at least one code file is located in a predefined fully disabled directory, perform full filtering on the entire task list to determine that the task list after disabling the filtering is empty.

[0054] If the disabled directory detection result indicates that at least one code file is located in a predefined fully disabled directory, then all changed files in the code merge request can be considered as files that do not need to be executed at all. In this case, all CI build tasks and CI test tasks can be skipped and no tasks need to be executed. That is, the entire task list is filtered, and the resulting task list after the disabled filtering is empty.

[0055] Sub-step 2243: If at least one code file is located in a predefined test-disabled directory, filter all CI test tasks in the full task list to obtain a task list with the filter disabled.

[0056] If the disabled directory detection result indicates that at least one code file is located in a predefined test disabled directory, it can be assumed that all the changed files in the code merge request are files that only need to be compiled and not executed. This means that only CI build tasks need to be executed, and all CI test tasks in the full task list can be skipped. CI test tasks do not need to be executed. That is, all CI test tasks in the full task list are filtered, and the resulting disabled filtered task list includes all CI build tasks in the full task list.

[0057] If the disabled directory detection result indicates that at least one code file is partially located within a predefined fully disabled directory, or indicates that at least one code file is located outside a predefined fully disabled directory, or indicates that at least one code file is partially located within a predefined test disabled directory, or indicates that at least one code file is located outside a predefined test disabled directory, then the disabled directory filtering step is not required, and the task list after disabling the filtering is the full task list.

[0058] By performing disabled directory detection on at least one code file, it can be determined whether at least one code file is located in a predefined fully disabled directory, thus avoiding the execution of unnecessary CI build and CI test tasks. It can also be determined whether at least one code file is located in a predefined disabled test directory, thus avoiding the execution of additional CI test tasks. This significantly reduces the number of tasks to be executed in a single code synthesis request, effectively saving computing resources and shortening the task execution feedback cycle.

[0059] It is important to note that if the list of changed files includes CI configuration files, the corresponding tasks will still be retained even if at least one code file in the changed file list is located in a predefined disabled directory, and will not be suspended due to the disabled directory filtering.

[0060] Sub-step 225: Based on at least one code file, perform gated filtering on the task list after disabling filtering to obtain the filtered task list corresponding to the target branch. The gated filtering is used to retain CI test tasks that have intersections with the functional characteristics of the code file.

[0061] In some embodiments, sub-step 225 includes at least one of sub-steps 2251 to 2253.

[0062] Sub-step 2251: Based on at least one code file and the predefined mapping relationship between code directories and functional features, obtain the feature set corresponding to at least one code file.

[0063] The mapping between code directories and functional characteristics indicates the relationship between code file names and functional characteristics. For example, the code directory `src / graphics / ` corresponds to graphics characteristics, `src / media / ` corresponds to media characteristics, and `src / compute / ` corresponds to computational characteristics. If a code file is named `src / graphics / xxxx`, then that code file corresponds to a graphics characteristic. The functional characteristic corresponding to a code file indicates the functional module controlled by the code file. For example, if the functional characteristic corresponding to a code file is a graphics characteristic, then the code file is used to control the graphics functional module.

[0064] Based on the filename of at least one code file, determine the code directory to which at least one code file belongs. Then, based on the code directory to which at least one code file belongs, find the corresponding functional characteristic for each code file from a predefined mapping relationship between code directories and functional characteristics, thus obtaining a characteristic set corresponding to at least one code file. The characteristic set corresponding to at least one code file includes the functional characteristics corresponding to each of the at least one code file.

[0065] Sub-step 2252: If at least one code file is located in a predefined feature directory, obtain the feature characteristics of each CI test task in the task list after disabling filtering.

[0066] If at least one code file is located within a predefined feature directory, enable gating filtering and retrieve the functional features of each CI test task in the task list after filtering is disabled. If at least one code file is not located within a predefined feature directory (i.e., at least one code file is partially located within a predefined feature directory, or at least one code file is located outside a predefined feature directory), and gating filtering is not required, then the relevant gating filtering steps are not executed. The number of predefined feature directories can be one or more.

[0067] Each CI test task predeclares its functional characteristics. For example, a graphics test task predeclares its functional characteristics as graphics characteristics, and a computation test task predeclares its functional characteristics as computation characteristics. Therefore, the functional characteristics of each test task in the task list after disabling filtering can be directly obtained. Each CI test task can have one or more functional characteristics; for example, a CI test task can include both graphics and computation characteristics.

[0068] Sub-step 2253: Based on the functional characteristics of each CI test task in the task list after disabling filtering, retain the CI test tasks that intersect with the feature set to obtain the filtering task list corresponding to the target branch.

[0069] For each CI test task in the task list after disabling filtering, determine whether the functional characteristic of the CI test task intersects with the feature set corresponding to at least one code file. If the CI test task has one functional characteristic, then if the functional characteristic of the CI test task is within the feature set corresponding to at least one code file, it can be considered that the functional characteristic of the CI test task intersects with the feature set corresponding to at least one code file. If the CI test task has multiple functional characteristics, then if any of the multiple functional characteristics of the CI test task is within the feature set corresponding to at least one code file, it can be considered that the functional characteristic of the CI test task intersects with the feature set corresponding to at least one code file.

[0070] The CI test tasks that intersect with the feature set in the task list after disabling filtering are retained, while the CI test tasks that do not intersect with the feature set in the task list after disabling filtering are filtered to obtain the filtered task list corresponding to the target branch.

[0071] If the above-mentioned disabled directory detection result indicates that at least one code file is located within a predefined fully disabled directory, and the task list after disabling filtering is empty, then the gated filtering step is not required, and it can be determined that the filtered task list corresponding to the target branch is empty. If the above-mentioned disabled directory detection result indicates that at least one code file is located within a predefined test disabled directory, the task list after disabling filtering includes all CI build tasks from the full task list. Since there are no CI test tasks, the gated filtering step is also not required, and it can be determined that the filtered task list corresponding to the target branch is the task list after disabling filtering. If the above-mentioned disabled directory filtering step is not performed, the task list after disabling filtering is still the full task list. If at least one code file is located within a predefined feature directory, and gated filtering is enabled, the resulting filtered task list corresponding to the target branch includes all CI build tasks and CI test tasks that intersect with the feature set. If at least one code file is partially located within a predefined feature directory, or if at least one code file is located outside a predefined feature directory, then the gated filtering step is not performed, and the filtered task list corresponding to the target branch remains the full task list.

[0072] By enabling gating filtering when at least one code file is located in a predefined feature directory, CI test tasks that do not intersect with the feature set in the task list after filtering is disabled are filtered out, thus avoiding the execution of irrelevant CI test tasks. This helps save computing resources and shorten the task execution feedback cycle.

[0073] In some embodiments, for each CI test task in the task list after disabling filtering, if the functional characteristics of the CI test task are not obtained, the CI test task is filtered to obtain the filtered task list corresponding to the target branch.

[0074] If a CI test task does not predeclare functional characteristics, then the CI test task may not have any functional characteristics. For example, the CI test task may be a globally common basic verification test task. Therefore, the functional characteristics of the CI test task cannot be obtained in the above sub-step 2252. In the case that the functional characteristics of the CI test task cannot be determined, the CI test task is directly filtered to obtain the filtered task list corresponding to the target branch.

[0075] By filtering out CI test tasks that lack functional features, the accurate execution of each task is ensured, and irrelevant CI test tasks are avoided from wasting computing resources.

[0076] It is important to note that when the list of changed files includes CI configuration files, even if at least one code file in the list is located in a predefined feature directory, the corresponding task must still be retained and will not be prevented from being executed due to gating filtering.

[0077] By performing the steps described above to disable directory filtering, unnecessary tasks in the full task list are avoided from being executed. By performing the steps described above to perform gating filtering, CI test tasks that do not overlap with the functional characteristics of the code files are avoided from being executed. This reduces the number of tasks to be executed in a single code synthesis request, reduces the consumption of computing resources, effectively saves computing resources, shortens the feedback cycle of task execution, and improves the iterative efficiency of task execution.

[0078] The filtering process in step 230 will be described below.

[0079] In some embodiments, step 230 includes at least one of sub-steps 231 to 234.

[0080] Sub-step 231: Obtain the chip series set corresponding to the full task list. The chip series set includes the chip series information of each CI test task in the full task list.

[0081] The chip series set corresponding to the full task list indicates the chip matching conditions that each CI test task in the full task list must meet to execute. This chip series set is pre-built and can be obtained directly.

[0082] In some embodiments, the test environment identifier of each CI test task in the full task list is parsed according to the predefined mapping relationship between chip model and chip series to obtain the chip series information of each CI test task in the full task list; if the test environment identifier of the CI test task cannot be parsed, the execution node label of the CI test task is parsed according to the predefined mapping relationship between chip model and chip series to obtain the chip series information of the CI test task; and a chip series set is obtained based on the chip series information of each CI test task in the full task list.

[0083] A chip series is a cluster of chip products with similar functions and architectures under the same brand, while a chip model is a unique identifier for specific specifications and characteristics within a chip series. A single chip series can derive multiple different chip models. Therefore, based on the chip model and the mapping relationship between chip models and chip series, the chip series to which a chip model belongs can be determined.

[0084] The system retrieves the test environment identifier for each CI test task in the full task list and parses it to obtain the chip model information contained within. Then, based on the chip model information and the mapping relationship between chip models and chip series, the chip series information for each CI test task is determined. For example, if the test environment identifier for a CI test task is S80_Ubuntu22.04, the chip model information contained in the test environment identifier is S80. Based on the mapping relationship between chip models and chip series, the chip series information corresponding to S80 is determined to be sudi, thus the chip series information for the CI test task can be determined to be sudi.

[0085] When the test environment identifier of the CI test task cannot be parsed, the execution node label of the CI test task is obtained and parsed to obtain at least one field. Then, this field is used to match the chip model and chip series in the mapping relationship to determine if each field belongs to chip model information. Based on the chip model information in the execution node label and the mapping relationship between chip model and chip series, the chip series information of the CI test task is obtained. For example, if the execution node label is (S80||X300)&&Ubuntu22.04, the execution node label is split into several fields: S80, X300, and Ubuntu22.04. Each field is matched against the mapping relationship between chip model and chip series. If the mapping relationship between chip model and chip series shows that chip series information corresponding to S80 exists, then the chip series information corresponding to S80 is identified as sudi and determined as the chip series information of the CI test task.

[0086] Based on the chip model information obtained from the parsing results of the test environment identifier and the chip model information obtained from the parsing results of the execution node label, a chip series set is obtained. The chip series set includes the chip series information of each CI test task in the full task list.

[0087] By parsing the chip series information from the test environment identifier and execution node label of the CI test task, the chip corresponding to each CI test task can be determined. This facilitates subsequent hardware matching and filtering based on the chip series information, filtering out tasks that do not meet the chip matching conditions, ensuring that each task in the final task list has the chip execution conditions, and avoiding tasks that do not meet the chip execution conditions from affecting the task execution process.

[0088] Sub-step 232: For each CI test task in the filtered task list, construct a directory list corresponding to the CI test task based on the CI test task.

[0089] The directory list corresponding to a CI test task is a hardware directory list used to match at least one change file, including both blacklist and whitelist directory lists.

[0090] In some embodiments, a blacklist directory list is constructed based on chip directories that do not match the chip family information of the CI test task and system directories that do not match the current operating system.

[0091] The chip family information for CI test tasks is retrieved from the chip family set. Based on this information, a directory of chips that do not match the chip family information of the CI test tasks is obtained, along with a directory of systems that do not match the current operating system. A blacklist is then constructed based on these two directories. This blacklist is used to exclude CI test tasks that match the chip family information and the current operating system.

[0092] For example, if the chip series information for the CI test task is sudi and the current operating system is Linux, then a blacklist directory list will be built based on the chip directories other than sudi chips and the system directories other than Linux.

[0093] In some embodiments, a whitelist directory list is constructed based on a chip directory that matches the chip family information of the CI test task and a system directory that matches the current operating system.

[0094] The chip family information for CI test tasks is retrieved from the chip family set. Based on this information, a chip directory matching the chip family information of the CI test tasks is obtained, along with a system directory matching the current operating system. A whitelist directory list is then constructed based on the chip directories matching the chip family information of the CI test tasks and the system directories matching the current operating system. This whitelist directory list, derived from the chip family information and the current operating system, is used to match CI test tasks that match the blacklist directory.

[0095] By providing the two methods for constructing the catalog, different filtering methods are offered for hardware matching, allowing different methods to be used for hardware matching based on the test scenario, thus improving the efficiency of hardware matching.

[0096] Sub-step 233: Match the list of changed files with the directory list corresponding to the CI test task to obtain the matching result of the CI test task. The matching result is used to indicate whether the CI test task meets the hardware matching conditions.

[0097] The directory list corresponding to a CI test task can be either a blacklist directory list or a whitelist directory list.

[0098] In some embodiments, the directory list corresponding to the CI test task is converted into a hash table, and at least one changed file is matched with the hash table to obtain the matching result of the CI test task.

[0099] Each changed file is searched against a hash table to determine if it matches exactly. This matching result indicates whether the changed file matches the hash table, or in other words, whether it matches the directory list corresponding to the CI test task. If the changed file matches exactly in the hash table, the matching result indicates a match between the changed file and the directory list corresponding to the CI test task. If the changed file does not match exactly in the hash table, the matching result indicates a mismatch. Based on the matching result of at least one changed file, the matching result of the CI test task is obtained.

[0100] The matching results of a CI test task are used to indicate that at least one changed file matches the directory list corresponding to the CI test task, or to indicate that at least one changed file does not match the directory list corresponding to the CI test task, or to indicate that at least one changed file contains some changed files that match the directory list corresponding to the CI test task.

[0101] In some embodiments, the directory list corresponding to the CI test task is sorted in descending order according to the length of the directory name, and path prefix matching is performed on at least one modified file and the directory list corresponding to the CI test task in descending order to obtain the matching result of the CI test task.

[0102] Sort the directory list corresponding to the CI test task in descending order of directory name length. Check each changed file's file name (file path) to see if it is prefixed with a directory name. Obtain the matching result for each changed file. If the changed file's file name is prefixed with a directory name in the directory list, the matching result indicates that the changed file matches the directory list corresponding to the CI test task. If the changed file's file name is not prefixed with a directory name in the directory list, the matching result indicates that the changed file does not match the directory list corresponding to the CI test task.

[0103] By providing the two matching schemes mentioned above, the feasibility of hardware matching filtering schemes is expanded, allowing different matching methods to be used for hardware matching filtering according to the test scenario, thereby improving the efficiency of hardware matching filtering.

[0104] In some embodiments, the directory list corresponding to the CI test task can first be converted into a hash table, and at least one changed file can be matched against the hash table. If a hash match is found, the matching result of the CI test task is obtained based on the hash match result. If no hash match is found, the directory list corresponding to the CI test task is sorted in descending order of task name length to obtain a descending-ordered directory list, and path prefix matching is performed on at least one changed file against the descending-ordered directory list to obtain the matching result of the CI test task. A hash match is considered a hit if at least one changed file has a partial match in the hash table, and a hash match is considered a miss if at least one changed file has no exact match in the hash table.

[0105] You can refer to this. Figure 3 As shown, the directory list includes "src / drivers / qy1" and "src / os / windows", and at least one modified file includes "src / drivers / sudi / init.c", "src / drivers / qy1 / power.c" and "src / common / utils.h". First, an exact match is performed between the at least one modified file and the hash table. If no exact match is found, a path prefix match is performed between the at least one modified file and the directory list in descending order. Among them, "src / drivers / sudi / init.c" does not match the directory list, "src / drivers / qy1 / power.c" matches the directory list, and "src / common / utils.h" does not match the directory list. The matching result of the CI test task is obtained.

[0106] In some embodiments, if the directory list is a blacklisted directory list, then if at least one modified file matches the blacklisted directory list, the CI test task is determined to not meet the hardware matching conditions; conversely, if at least one modified file does not match the blacklisted directory list, the CI test task is determined to meet the hardware matching conditions. If the directory list is a whitelisted directory list, then if at least one modified file matches the whitelisted directory list, the CI test task is determined to meet the hardware matching conditions; conversely, if at least one modified file does not match the whitelisted directory list, the CI test task is determined to not meet the hardware matching conditions.

[0107] If the directory list corresponding to the CI test task is a blacklisted directory, then if the matching result of the CI test task indicates that at least one changed file matches the directory list corresponding to the CI test task, it is determined that at least one changed file matches the blacklisted directory list. Therefore, the CI test task does not meet the hardware matching conditions and needs to be filtered. Conversely, if the matching result of the CI test task indicates that at least one changed file does not match the directory list corresponding to the CI test task, or indicates that some changed files in at least one changed file match the directory list corresponding to the CI test task, it is determined that at least one changed file does not match the blacklisted directory list. Therefore, the CI test task meets the hardware matching conditions and needs to be retained.

[0108] If the directory list corresponding to the CI test task is a whitelisted directory, then if the CI test task's matching result indicates that at least one changed file matches the directory list corresponding to the CI test task, or indicates that some changed files in at least one changed file match the directory list corresponding to the CI test task, it is determined that at least one changed file matches the whitelisted directory list. Therefore, the CI test task meets the hardware matching conditions and needs to be retained. Conversely, if the CI test task's matching result indicates that at least one changed file does not match the directory list corresponding to the CI test task, it is determined that at least one changed file does not match the whitelisted directory list. Therefore, the CI test task does not meet the hardware matching conditions and needs to be filtered.

[0109] By defining filtering methods for blacklisted and whitelisted directory lists respectively—filtering only when all changed files are matched in the case of a blacklisted directory list, and retaining only when all changed files are matched in the case of a whitelisted directory list—the accuracy of hardware matching and filtering is ensured.

[0110] Sub-step 234: Based on the matching results of each CI test task in the filtering task list, filter out CI test tasks that do not meet the hardware matching conditions to obtain the final task list.

[0111] Based on the matching results of each CI test task, a hardware matching filter result is obtained for each CI test task. If a CI test task meets the hardware matching conditions, the hardware matching filter result indicates that the CI test task is retained; if a CI test task does not meet the hardware matching conditions, the hardware matching filter result indicates that the CI test task is filtered. Therefore, based on the matching results of each CI test task, it can be determined whether each CI test task is filtered. After filtering out CI test tasks that do not meet the hardware matching conditions, the final task list is obtained.

[0112] By performing the hardware matching filtering steps described above, it is determined whether each CI test task in the filtering task list meets the hardware matching conditions. CI test tasks that do not meet the hardware matching conditions in the filtering task list are filtered out, so that each task in the final task list meets the hardware matching conditions. This avoids retaining tasks that do not meet the hardware matching conditions, which would increase the consumption of computing resources and affect the efficiency of task execution.

[0113] In some embodiments, when the directory list is a whitelisted directory list, at least one modified file is detected to detect whether a shared file exists, and the detection result of at least one modified file is obtained. The shared file is a file that does not belong to any chip, operating system, or code directory. If the detection result indicates that a shared file exists, all tasks in the filtered task list are retained to obtain the final task list.

[0114] Shared files can be public files, general tool code files, or other files containing common code. If a shared file exists in at least one changed file, all CI test tasks will be executed regardless of the filtering rules. This prevents changes to common code from causing tasks on that basis to be missed and affecting the test results of the CI pipeline, thus ensuring the integrity of task execution and the accuracy of test results.

[0115] In some embodiments, the system specifically records all filtered tasks and their reasons for filtering. A structured summary can be generated, clearly recording the reason for filtering each task and a list of filtered tasks. For CI pipeline tasks triggered by code merge requests, a filtering summary can be automatically published in the comments section of the code merge request, supporting deduplication based on the code merge request submission. This helps developers and reviewers understand which tasks were skipped and why, without needing to search through logs. Tags can also be set for code merge requests to identify whether the current CI pipeline task triggered filtering logic, distinguishing it from pipeline tasks that are executed in full. Distributed locks can also be used to ensure that comments are not duplicated in concurrent scenarios.

[0116] Figure 4The diagram illustrates the task filtering process. After code submission triggers the task testing process, a list of change files corresponding to the code merge request is obtained based on the code merge request. This list includes at least one change file. The process checks if the change file list contains a CI configuration file. If it does, configuration difference detection is performed on the CI configuration file. Based on the detection results, it's determined whether to mark the task test as "degradation mode" or precisely identify the changed test definition fields in the CI configuration file. The CI test tasks corresponding to these changed fields are then marked as "configuration change tests," resulting in a filtered task list. If the change file list does not contain a CI configuration file, the entire task list is first filtered for disabled directories, and then the disabled-filtered task list is gated, resulting in a filtered task list. Each CI test task in the filtered task list undergoes hardware matching filtering sequentially. Either a blacklist or whitelist directory list can be used for path matching and result aggregation, resulting in the matching results for each CI test task in the filtered task list. CI test tasks that do not meet the hardware matching conditions are filtered out, resulting in the final task list.

[0117] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0118] Please refer to Figure 5 This diagram illustrates a block diagram of a task filtering apparatus according to an embodiment of this application. The apparatus has the function of implementing the task filtering method described above; this function can be implemented in hardware or by hardware executing corresponding software. The apparatus can be the computer device described above, or it can be installed within a computer device. For example... Figure 5 As shown, the device 500 may include: a file acquisition module 510, a task filtering module 520, and a matching filtering module 530.

[0119] The file acquisition module 510 is used for a continuous integration (CI) pipeline task for a graphics processor (GPU) driver. Upon receiving a code merge request for the CI pipeline task, the module acquires a list of changed files corresponding to the code merge request. The list of changed files includes at least one changed file. The code merge request is used to request the merging of changed files in the source branch of the CI pipeline task into the target branch. The changed files are files in the source branch that have been modified relative to the target branch.

[0120] The task filtering module 520 is used to filter the full task list of the target branch according to the change file list to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch.

[0121] The matching and filtering module 530 is used to perform hardware matching filtering on the filtering task list to obtain the final task list. The hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions.

[0122] In some embodiments, the task filtering module 520 is configured to: If the list of changed files includes a CI configuration file, the full task list of the target branch is filtered according to the CI configuration file to obtain a filtered task list corresponding to the target branch. The CI configuration file is used to indicate the task execution rules of the target branch. If the CI configuration file is not included in the list of changed files, the full task list of the target branch is filtered based on at least one code file in the list of changed files to obtain the filtered task list corresponding to the target branch.

[0123] In some embodiments, the task filtering module 520 is configured to: The CI configuration file is subjected to configuration difference detection to obtain the configuration difference detection result of the CI configuration file. The configuration difference detection result is used to indicate the types of fields that have changed in the CI configuration file. If the global configuration field in the CI configuration file changes, all CI test tasks in the full task list are retained to obtain the filter task list corresponding to the target branch. The global configuration field is used to indicate the general execution rules of the CI test tasks. If only the test definition field changes in the CI configuration file, the full task list of the target branch is filtered based on the changed field in the test definition field to obtain the filtered task list corresponding to the target branch. The test definition field is used to indicate the specific execution rules of the CI test task.

[0124] In some embodiments, the task filtering module 520 is configured to: Based on the at least one code file, the full task list is filtered for disabled directories to obtain a task list after disabled filtering. The disabled directory filtering is used to determine whether all CI build tasks and CI test tasks in the full task list are filtered. Based on the at least one code file, the task list after disabling filtering is gated to obtain the filtered task list corresponding to the target branch. The gating filter is used to retain CI test tasks that have intersections with the functional characteristics of the code file.

[0125] In some embodiments, the task filtering module 520 is configured to: Perform a disabled directory detection on the at least one code file to obtain a disabled directory detection result for the at least one code file. The disabled directory detection result is used to indicate whether the at least one code file is located in a predefined disabled directory. If at least one code file is located in a predefined fully disabled directory, the entire task list is filtered to determine that the task list after the filtering is empty. If at least one code file is located in a predefined test-disabled directory, all CI test tasks in the full task list are filtered to obtain the task list after disabling and filtering.

[0126] In some embodiments, the task filtering module 520 is configured to: Based on the at least one code file and the predefined mapping relationship between code directories and functional features, a feature set corresponding to the at least one code file is obtained; If at least one code file is located in a predefined feature directory, obtain the functional features of each CI test task in the task list after disabling filtering; Based on the functional characteristics of each CI test task in the task list after disabling filtering, retain the CI test tasks that intersect with the characteristic set to obtain the filtering task list corresponding to the target branch.

[0127] In some embodiments, the task filtering module 520 is configured to: For each CI test task in the task list after disabling filtering, if the functional characteristics of the CI test task are not obtained, the CI test task is filtered to obtain the filtered task list corresponding to the target branch.

[0128] In some embodiments, the matching filtering module 530 is configured to: Obtain the chip series set corresponding to the full task list, wherein the chip series set includes chip series information for each CI test task in the full task list; For each CI test task in the filtering task list, construct a directory list corresponding to the CI test task based on the CI test task; The list of changed files and the directory list corresponding to the CI test task are matched to obtain the matching result of the CI test task. The matching result is used to indicate whether the CI test task meets the hardware matching conditions. Based on the matching results of each CI test task in the filtering task list, CI test tasks that do not meet the hardware matching conditions are filtered to obtain the final task list.

[0129] In some embodiments, the matching filtering module 530 is configured to: Based on the predefined mapping relationship between chip models and chip series, the test environment identifier of each CI test task in the full task list is parsed to obtain the chip series information of each CI test task in the full task list. If the test environment identifier of the CI test task cannot be parsed, the execution node label of the CI test task is parsed according to the predefined mapping relationship between chip model and chip series to obtain the chip series information of the CI test task. The chip series set is obtained based on the chip series information of each CI test task in the full task list.

[0130] In some embodiments, the matching filtering module 530 is configured to: A blacklist directory is constructed based on the chip catalog that does not match the chip series information of the CI test task and the system catalog that does not match the current operating system. or, A whitelist directory is constructed based on the chip series information matching the CI test task and the system directory matching the current operating system.

[0131] In some embodiments, the matching filtering module 530 is configured to: The directory list corresponding to the CI test task is converted into a hash table, and the at least one modified file is matched with the hash table to obtain the matching result of the CI test task; or, The directory list corresponding to the CI test task is sorted in descending order according to the length of the directory name, and path prefix matching is performed on the at least one modified file and the directory list corresponding to the CI test task in descending order to obtain the matching result of the CI test task.

[0132] In some embodiments, the matching filtering module 530 is configured to: If the directory list is a blacklist directory list, then if at least one changed file matches the blacklist directory list, it is determined that the CI test task does not meet the hardware matching condition; and if at least one changed file does not match the blacklist directory list, it is determined that the CI test task meets the hardware matching condition. If the directory list is a whitelist directory list, then if at least one of the changed files matches the whitelist directory list, the CI test task is determined to meet the hardware matching conditions; if at least one changed file does not match the whitelist directory list, the CI test task is determined not to meet the hardware matching conditions.

[0133] In some embodiments, the matching filtering module 530 is configured to: If the directory list is a whitelist directory list, detect whether there is a shared file in the at least one changed file, and obtain the detection result of the at least one changed file. The shared file is a file that does not belong to any chip, operating system and code directory. If the detection result indicates the existence of the shared file, all tasks in the filtered task list are retained to obtain the final task list.

[0134] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0135] Please refer to Figure 6 This diagram illustrates a structural block diagram of a computer device 600 provided in one embodiment of this application. The computer device 600 can be any electronic device capable of data computation, processing, and storage. The computer device 600 can be used to implement the task filtering method provided in the above embodiments.

[0136] Typically, computer device 600 includes a processor 601 and a memory 602.

[0137] Processor 601 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 601 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 601 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 601 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 601 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0138] The memory 602 may include one or more computer-readable storage media, which may be non-transitory. The memory 602 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 602 are used to store a computer program configured to be executed by one or more processors to implement the task filtering method described above.

[0139] Those skilled in the art will understand that Figure 6 The structure shown does not constitute a limitation on the computer device 600, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0140] In an illustrative embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program implements the above-described task filtering method when executed by a processor of a computer device. Optionally, the above-described computer-readable storage medium may be ROM (Read-Only Memory), RAM (Random Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage device, etc.

[0141] In an exemplary embodiment, a computer program product is also provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the task filtering method described above.

[0142] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform users that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected by this application is processed strictly in accordance with the requirements of relevant national laws and regulations. The informed consent or separate consent of the data subject is obtained only with the user's consent and authorization. Subsequent data use and processing are conducted within the scope of laws, regulations, and the data subject's authorization, and the collection, use, and processing of relevant user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0143] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0144] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A task filtering method, characterized in that, The method includes: For a continuous integration (CI) pipeline task driven by a graphics processing unit (GPU), upon receiving a code merge request for the CI pipeline task, a list of change files corresponding to the code merge request is obtained. The list of change files includes at least one change file. The code merge request is used to request the merging of change files in the source branch of the CI pipeline task into the target branch. The change file is a file in the source branch that has been modified relative to the target branch. Based on the list of changed files, the full task list of the target branch is filtered to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch. The filtered task list is subjected to hardware matching filtering to obtain the final task list. The hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions.

2. The method according to claim 1, characterized in that, The step of filtering the full task list of the target branch based on the list of changed files to obtain the filtered task list corresponding to the target branch includes: If the list of changed files includes a CI configuration file, the full task list of the target branch is filtered according to the CI configuration file to obtain a filtered task list corresponding to the target branch. The CI configuration file is used to indicate the task execution rules of the target branch. If the CI configuration file is not included in the list of changed files, the full task list of the target branch is filtered based on at least one code file in the list of changed files to obtain the filtered task list corresponding to the target branch.

3. The method according to claim 2, characterized in that, The step of filtering the full task list of the target branch according to the CI configuration file to obtain the filtered task list corresponding to the target branch includes: The CI configuration file is subjected to configuration difference detection to obtain the configuration difference detection result of the CI configuration file. The configuration difference detection result is used to indicate the types of fields that have changed in the CI configuration file. If the global configuration field in the CI configuration file changes, all CI test tasks in the full task list are retained to obtain the filter task list corresponding to the target branch. The global configuration field is used to indicate the general execution rules of the CI test tasks. If only the test definition field changes in the CI configuration file, the full task list of the target branch is filtered according to the changed field in the test definition field to obtain the filtered task list corresponding to the target branch. The test definition field is used to indicate the specific execution rules of the CI test task.

4. The method according to claim 2, characterized in that, The step of filtering the full task list of the target branch based on at least one code file in the changed file list to obtain the filtered task list corresponding to the target branch includes: Based on the at least one code file, the full task list is filtered for disabled directories to obtain a task list after disabled filtering. The disabled directory filtering is used to determine whether all CI build tasks and CI test tasks in the full task list are filtered. Based on the at least one code file, the task list after disabling filtering is gated to obtain the filtered task list corresponding to the target branch. The gating filter is used to retain CI test tasks that have intersections with the functional characteristics of the code file.

5. The method according to claim 4, characterized in that, The step of filtering the full task list by disabling directories based on the at least one code file to obtain a task list after disabling the filtering includes: Perform a disabled directory detection on the at least one code file to obtain a disabled directory detection result for the at least one code file. The disabled directory detection result is used to indicate whether the at least one code file is located in a predefined disabled directory. If at least one code file is located in a predefined fully disabled directory, the entire task list is filtered to determine that the task list after the filtering is empty. If at least one code file is located in a predefined test-disabled directory, all CI test tasks in the full task list are filtered to obtain the task list after disabling and filtering.

6. The method according to claim 4, characterized in that, The step of gating and filtering the task list after disabling filtering based on the at least one code file to obtain the filtered task list corresponding to the target branch includes: Based on the at least one code file and the predefined mapping relationship between code directories and functional features, a feature set corresponding to the at least one code file is obtained; If at least one code file is located in a predefined feature directory, obtain the functional features of each CI test task in the task list after disabling filtering; Based on the functional characteristics of each CI test task in the task list after disabling filtering, retain the CI test tasks that intersect with the characteristic set to obtain the filtering task list corresponding to the target branch.

7. The method according to claim 6, characterized in that, The method further includes: For each CI test task in the task list after disabling filtering, if the functional characteristics of the CI test task are not obtained, the CI test task is filtered to obtain the filtered task list corresponding to the target branch.

8. The method according to any one of claims 1 to 7, characterized in that, The step of performing hardware matching filtering on the filtering task list to obtain the final task list includes: Obtain the chip series set corresponding to the full task list, wherein the chip series set includes chip series information for each CI test task in the full task list; For each CI test task in the filtering task list, construct a directory list corresponding to the CI test task based on the CI test task; The list of changed files and the directory list corresponding to the CI test task are matched to obtain the matching result of the CI test task. The matching result is used to indicate whether the CI test task meets the hardware matching conditions. Based on the matching results of each CI test task in the filtering task list, CI test tasks that do not meet the hardware matching conditions are filtered to obtain the final task list.

9. The method according to claim 8, characterized in that, The step of obtaining the chip series set corresponding to the full task list includes: Based on the predefined mapping relationship between chip models and chip series, the test environment identifier of each CI test task in the full task list is parsed to obtain the chip series information of each CI test task in the full task list. If the test environment identifier of the CI test task cannot be parsed, the execution node label of the CI test task is parsed according to the predefined mapping relationship between chip model and chip series to obtain the chip series information of the CI test task. The chip series set is obtained based on the chip series information of each CI test task in the full task list.

10. The method according to claim 8, characterized in that, The step of constructing a directory list corresponding to the CI test task based on the CI test task includes: A blacklist directory is constructed based on the chip catalog that does not match the chip series information of the CI test task and the system catalog that does not match the current operating system. or, A whitelist directory is constructed based on the chip series information matching the CI test task and the system directory matching the current operating system.

11. The method according to claim 8, characterized in that, The process of matching the list of changed files with the directory list corresponding to the CI test task to obtain the matching result of the CI test task includes: The directory list corresponding to the CI test task is converted into a hash table, and the at least one modified file is matched with the hash table to obtain the matching result of the CI test task; or, The directory list corresponding to the CI test task is sorted in descending order according to the length of the directory name, and path prefix matching is performed on the at least one modified file and the directory list corresponding to the CI test task in descending order to obtain the matching result of the CI test task.

12. The method according to claim 8, characterized in that, The method further includes: If the directory list is a blacklist directory list, then if at least one changed file matches the blacklist directory list, it is determined that the CI test task does not meet the hardware matching condition; and if at least one changed file does not match the blacklist directory list, it is determined that the CI test task meets the hardware matching condition. If the directory list is a whitelist directory list, then if at least one of the changed files matches the whitelist directory list, the CI test task is determined to meet the hardware matching conditions; if at least one changed file does not match the whitelist directory list, the CI test task is determined not to meet the hardware matching conditions.

13. The method according to claim 8, characterized in that, The method further includes: If the directory list is a whitelist directory list, detect whether there is a shared file in the at least one changed file, and obtain the detection result of the at least one changed file. The shared file is a file that does not belong to any chip, operating system and code directory. If the detection result indicates the existence of the shared file, all tasks in the filtered task list are retained to obtain the final task list.

14. A task filtering device, characterized in that, The device includes: The file acquisition module is used for a continuous integration (CI) pipeline task for a graphics processor (GPU) driver. Upon receiving a code merge request for the CI pipeline task, the module acquires a list of changed files corresponding to the code merge request. The list of changed files includes at least one changed file. The code merge request is used to request the merging of changed files in the source branch of the CI pipeline task into the target branch. The changed files are files in the source branch that have been modified relative to the target branch. The task filtering module is used to filter the full task list of the target branch according to the change file list to obtain the filtered task list corresponding to the target branch. The filtered task list includes the CI test tasks and CI build tasks to be executed in the target branch. The matching and filtering module is used to perform hardware matching filtering on the filtering task list to obtain the final task list. The hardware matching filtering is used to filter tasks that do not meet the hardware matching conditions.

15. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the task filtering method as described in any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the task filtering method as described in any one of claims 1 to 13.

17. A computer program product, characterized in that, The computer program product includes a computer program that is loaded and executed by a processor to implement the task filtering method as described in any one of claims 1 to 13.

Images