Kernel automatic testing method and system based on Git community platform and medium

Abstract

The invention discloses an automatic kernel testing method and system based on a Git community platform and a medium. The method comprises the steps that a submission event of the Git community platform is monitored through a webpage hook, and a testing request is sent to a preset monitoring service; the monitoring service receives the test request, and triggers a corresponding test assembly line through an assembly line API; and the test assembly line judges whether the kernel automation test needs to be executed according to the test request, if the kernel automation test needs to be executed, compilation detection and test tasks suitable for the kernel under different architectures are scheduled, and results are fed back to the Git community platform to record execution results of the compilation detection and test tasks of the kernel under the different architectures. The invention aims to overcome the problems of manual triggering, test delay and result dispersion in the prior art, and trigger on the Git community platform to realize automatic test on a plurality of architectures and automatically return the test result, so as to ensure that the test process is efficient, transparent and unified.

Description

Technical Field

[0001] This invention belongs to the field of software testing and continuous integration technology, specifically relating to a kernel automated testing method, system and medium based on the Git community platform, used to realize automated compilation, verification and test execution of kernel code in multi-architecture environments. Background Technology

[0002] With the rapid development of open-source software and the Linux kernel, Git community platforms have become the mainstream version control and code collaboration platforms. In community-driven development, code commits are frequent and distributed. After developers submit patches or branch updates on different architectures (such as x86_64, aarch64, etc.), they typically need to verify whether the code can be compiled correctly and ensure that it functions properly on the target system. Traditional kernel verification processes mainly rely on manual or semi-automated methods, which have the following major problems: developers complete compilation and testing locally, resulting in a fragmented and inefficient verification process; a lack of a unified automated triggering mechanism and result feedback channel; complex configuration of test environments for different architectures, making it difficult to ensure consistency; and community members cannot receive real-time test feedback after patch submissions. These problems lead to: low verification efficiency and long testing cycles; delayed test result feedback, affecting development progress; insufficient transparency in community collaboration and poor communication; and a lack of a unified automated execution channel, increasing the complexity of development and maintenance. Therefore, how to achieve automated kernel testing based on the Git community platform has become a critical technical problem that urgently needs to be solved. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a kernel automated testing method, system and medium based on the Git community platform to address the above-mentioned problems in the prior art. This invention aims to overcome the problems of manual triggering, test delay and scattered results in the prior art, and to trigger and realize automatic testing on multiple architectures on the Git community platform and automatically return test results, so as to ensure that the testing process is efficient, transparent and consistent.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A kernel automation testing method based on the Git community platform includes the following steps: S101, monitor the commit events of the Git community platform by deploying web page hooks on the Git community platform developed in the kernel. The commit events include code commit, merge and update events. If a commit event of the Git community platform is detected, send a test request to the preset monitoring service. S102, the monitoring service receives test requests from the Git community platform, extracts the commit information contained in the test requests, and triggers the corresponding test pipeline through the pipeline API; S103, The test pipeline determines whether the type of the commit event in the test request is a type that needs to be executed for kernel automated testing based on the commit information contained in the test request and the preset configuration file. If it is a type that needs to be executed for kernel automated testing, it schedules compilation detection and testing tasks applicable to different kernel architectures, feeds the results back to the Git community platform, and jumps to step S104; otherwise, it ends and exits. S104 is a Git community platform that records the results of kernel compilation, testing, and execution tasks under different architectures.

[0005] Optionally, the monitoring service preset in step S101 is implemented through a monitoring service module, which is configured to start automatically upon system boot.

[0006] Optionally, when extracting the commit information contained in the test request in step S102, the commit information includes the PR proposer, PR number, commit branch, and build result, and the build result includes indicators of whether the build and compilation were successful under various architectures.

[0007] Optionally, in step S103, when scheduling compilation detection and testing tasks applicable to different architectures, this includes allocating separate compilation detection and testing tasks for each architecture and recording the status information of each compilation detection and testing task. The kernel compilation detection and testing tasks under any given architecture include: S201, check the build result in the submission information contained in the test request, and determine whether the build and compilation success indicator under the current architecture is successful. If the build is successful, proceed to step S201; otherwise, proceed to step S207. S202, pulls the kernel binary package for the current architecture from the build server or a specified repository; S203, determine whether the test environment in the submission information contained in the test request can be connected. If the connection fails, report an error and exit, then proceed to step S207; otherwise, proceed to the next step. S204 loads the kernel binary package under the current architecture using a virtualization platform in a test environment; S205, Start the target virtual machine in the test environment, download the kernel binary package under the current architecture in the target virtual machine, and restart the target virtual machine to load the downloaded kernel binary package under the current architecture; S206: Perform functional verification and testing on the kernel binary package under the current architecture in the target virtual machine and collect logs, and obtain the test results based on the collected logs; S207, the results are fed back to the Git community platform.

[0008] Optionally, when performing functional verification and testing and collecting logs for the kernel binary package under the current architecture in the target virtual machine in step S206, it includes calling an automated testing toolset to perform functional verification and testing and collect logs for the kernel binary package under the current architecture in the target virtual machine. The functional verification and testing tools in the automated testing toolset include functional verification and testing tools for file systems, memory management, and hardware drivers.

[0009] Optionally, step S204 includes backing up the configuration and services in the virtual machine; step S206 includes restoring the configuration and services.

[0010] Optionally, when feeding the results back to the Git community platform in step S103, it also includes determining whether a push notification hook is filled in the specified configuration. If a push notification hook is filled in, a push notification is executed to push the results to the user using the push notification hook; otherwise, the notification is skipped.

[0011] The present invention also provides a kernel automated testing system based on the Git community platform, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the kernel automated testing method based on the Git community platform.

[0012] The present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the kernel automation testing method based on the Git community platform via a processor.

[0013] The present invention also provides a computer program product, including a computer program or instructions, which are programmed or configured to execute the kernel automation testing method based on the Git community platform via a processor.

[0014] Compared with existing technologies, the present invention can mainly achieve the following beneficial effects: (1) Automated triggering and execution: The present invention utilizes the Webhook mechanism of the Git platform to automatically trigger kernel automated testing after code submission, completely eliminating the need for manual intervention and ensuring the timeliness and efficiency of the testing process. Through automated triggering and execution, developers do not need to manually start the testing process, greatly reducing the delay and error caused by human operation. (2) Automated testing process and improved accuracy: The entire testing process is automated, from kernel package retrieval and installation to test execution and result feedback, all links are automatically completed by the system. This automated process effectively avoids errors or omissions in manual operation, greatly improves the accuracy and reliability of testing, and also improves test coverage, ensuring that each submission can undergo comprehensive and standardized verification. (3) Automatic configuration of the testing environment: The present invention quickly builds and deploys the testing environment by automatically pulling and installing the kernel binary package of the corresponding architecture, ensuring the efficiency and architecture consistency of the testing environment. Whether it is a virtual machine or a physical environment, the system can automatically configure the environment according to the required architecture, avoiding the version inconsistency and configuration error problems that may be caused by manual configuration. (4) Intelligent architecture selection mechanism: Based on the compilation results of different architectures, this invention dynamically determines the scope of the test architecture. For example, when the compilation of a certain architecture fails, the system will automatically skip the test of that architecture to avoid wasting test resources and report the problem. This intelligent architecture selection mechanism not only improves the utilization efficiency of test resources, but also reduces unnecessary test execution time and ensures that the test of critical architectures can be completed in a timely manner. (5) Result feedback and traceability: Test results are fed back to the Git repository or other designated platforms through an automated process to ensure that the test results of each submission can be fed back to the developers in real time and accurately. This mechanism not only realizes transparent collaboration at the community level, but also supports version traceability of test results. Developers can view the test feedback of historical submissions to ensure the gradual improvement and high-quality iteration of patches. Through these improvements, this invention can greatly improve the efficiency, accuracy and transparency of the kernel testing process, thereby promoting the automation and intelligentization of open source community and enterprise kernel development. At the same time, the automated feedback and real-time test report generation also significantly improve the response speed and quality of team collaboration. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0016] Figure 2 This is a detailed flowchart illustrating the method of an embodiment of the present invention. Detailed Implementation

[0017] This invention, based on the Git community platform, provides an automated kernel testing method aimed at improving the efficiency of kernel patch verification, ensuring cross-architecture consistency, and enabling real-time feedback of test results. To enable those skilled in the art to better understand the technical solution of this invention, the following will provide a more detailed description of the technical solution in conjunction with the accompanying drawings of the embodiments of this invention.

[0018] like Figure 1 As shown, the kernel automated testing method based on the Git community platform in this embodiment includes the following steps: S101, monitor the commit (push operation) events of the Git community platform by deploying a web hook on the Git community platform developed in the kernel. The commit events include code commit, merge and update events. If a commit event of the Git community platform is detected, send a test request (POST request) to the preset monitoring service. S102, the monitoring service receives the test request from the Git community platform, extracts the commit information contained in the test request, and triggers the corresponding test pipeline through the pipeline API (the Jenkins pipeline is used in this embodiment). S103, The test pipeline determines whether the type of the commit event in the test request is a type that needs to be executed for kernel automated testing based on the commit information contained in the test request and the preset configuration file. If it is a type that needs to be executed for kernel automated testing, it schedules compilation detection and testing tasks applicable to different kernel architectures, feeds the results back to the Git community platform, and jumps to step S104; otherwise, it ends and exits. S104 is a Git community platform that records the results of kernel compilation, inspection, and testing tasks under different architectures, so that kernel developers can read and refer to it for kernel source code and function implementation and modification.

[0019] As an optional implementation, the kernel is the Linux kernel. However, the kernel in this embodiment does not depend on the Linux kernel, but rather is the kernel of any operating system developed using the Git community platform as a version management tool.

[0020] In step S101, the Git community platform's commit (push operation) events are monitored by deploying web hooks on the kernel-developed Git community platform (such as Gitee or GitHub). By parsing the commit (push operation) events, key information such as the PR proposer, PR number, commit branch, and build result can be automatically identified, ensuring the accurate execution of subsequent processes.

[0021] The monitoring service module is used to listen for push events from the Git platform in real time. In this embodiment, it is implemented using Python and the Flask framework. The monitoring service module is responsible for receiving POST requests from the Git platform and extracting the commit information contained therein (such as PR number, branch information, etc.) to provide a basis for triggering subsequent tests. The monitoring service preset in step S101 is implemented through the monitoring service module, which is configured to start automatically on boot to ensure that the system can automatically start and remain running under any circumstances. In addition, a daemon process can be added to ensure automatic startup after a crash. When the monitoring service module receives a POST request, it triggers the corresponding test pipeline through the Jenkins API.

[0022] When extracting the commit information from the test request in step S102, the commit information includes the PR proposer, PR number, commit branch, and build result. The build result includes indicators of whether the build and compilation were successful for various architectures (such as x86_64, aarch64, etc.). After receiving the POST request, the monitoring service's agent module automatically triggers the corresponding test pipeline by calling the Jenkins API. This pipeline schedules compilation detection and testing tasks suitable for different architectures based on the committed information and configuration files, ensuring that kernel patches for each platform can be verified. If the build and compilation result for the corresponding architecture is successful, the kernel binary package is automatically downloaded.

[0023] In step S103, the test pipeline determines whether the type of the submission event in the test request is a type that needs to be executed for kernel automated testing based on the submission information contained in the test request and the preset configuration file. The judgment rules here can be set according to actual needs. For example, the specified priority of a specific submission type (such as patch or update) can be set as the type that needs to be executed for kernel automated testing, while the rest are non-critical updates or a certain architecture has not been modified, so the automated test is skipped to avoid unnecessary resource consumption.

[0024] The Jenkins pipeline automatically schedules build, test, and evaluation tasks for different architectures (such as x86_64, aarch64, etc.) based on the commit configuration file and information provided by the Git platform. If the commit involves changes to multiple architectures, the pipeline will assign separate build and test tasks to each architecture. The pipeline records the status information of each task, such as build results. Figure 2 As shown, in step S103 of this embodiment, when scheduling compilation detection and testing tasks applicable to different architectures, it includes allocating separate compilation detection and testing tasks for each architecture and recording the status information of each compilation detection and testing task. Furthermore, the kernel compilation detection and testing tasks under any given architecture include: S201, check the build result in the submission information contained in the test request, and determine whether the build and compilation success indicator under the current architecture is successful. If the build is successful, jump to step S201; otherwise, jump to step S207. For example, the compilation status of the kernel binary package of each architecture (such as x86_64, aarch64, etc.) in the Git community platform can be detected according to the test configuration information. The compilation status of each architecture can be obtained in real time by calling the API of the CI system (such as Jenkins). It has the following advantages: (1) Cross-architecture support: It can monitor the kernel compilation status of multiple architectures in parallel to ensure the verification coverage of each architecture. (2) Compilation status query: Based on the API of the CI system, the compilation status is automatically obtained, avoiding manual intervention; S202, pull the kernel binary package under the current architecture from the build server or the specified repository; if the compilation status is detected as success, the kernel binary package of the corresponding architecture is automatically pulled. The pulling process is connected to the software repository through the Git platform to ensure that the latest and correct kernel binary package is obtained. Its technical mechanism includes: (1) Automatic pulling mechanism: automatically pull the kernel binary package that meets the conditions through the pre-configured repository source to avoid manual download. (2) Version control: ensure that the kernel package obtained is consistent with the version of the submitted code during the pulling process to avoid version mismatch; as an optional implementation method, this embodiment includes binary package status detection after pulling the kernel binary package, and uses the keywords in the kernel binary package to determine its corresponding architecture, thereby obtaining the kernel binary package under the current architecture; S203: Determine if a connection can be established with the test environment specified in the submission information of the test request. If the connection fails, exit with an error and proceed to step S207; otherwise, proceed to the next step. If the compilation status is detected as "failed," skip the corresponding architecture package and do not install or test it. This mechanism avoids invalid test results due to compilation failure. Through the above automatic ignore mechanism, the real-time compilation status can be used to determine the failure, avoiding unnecessary testing processes. Logs can be generated upon failure to quickly locate and record the problem. S204, in a test environment, loads the kernel binary package under the current architecture using a virtualization platform (such as KVM, QEMU); S205: In the test environment, start the target virtual machine, download the kernel binary package for the current architecture within the target virtual machine, and restart the target virtual machine to load the downloaded kernel binary package for the current architecture. This ensures that the virtual machine boots into an environment with the new kernel installed for actual functional verification and testing. The successfully pulled kernel binary package is then installed into the test environment (e.g., a virtual machine), and a system restart is performed to ensure that the virtual machine boots into the latest kernel environment. This allows for automated environment setup without manual intervention, automatically deploying the kernel and ensuring that the virtual machine enters the updated kernel environment. S206: Perform functional verification and testing on the kernel binary package under the current architecture in the target virtual machine and collect logs, and obtain the test results based on the collected logs; S207, the results are fed back to the Git community platform.

[0025] In step S206, when performing functional verification and testing and collecting logs for the kernel binary package under the current architecture in the target virtual machine, this includes calling an automated testing toolset (such as xfstests, kselftest, and custom scripts) to perform functional verification and testing and collect logs for the kernel binary package under the current architecture in the target virtual machine. The automated testing toolset includes functional verification and testing tools for file systems, memory management, and hardware drivers. The automated testing toolset supports flexible testing tools (such as xfstests, kselftest, and custom scripts). By supporting multiple kernel testing tools, it can cover key modules such as file systems, memory management, and hardware drivers. The entire process is automated, requiring no manual intervention, ensuring high efficiency and consistency in the testing process.

[0026] like Figure 2 As shown, as an optional implementation, step S204 includes backing up the configuration and services in the virtual machine; step S206 includes restoring the configuration and services to prevent kernel testing from affecting the test environment of the virtual machine.

[0027] like Figure 2 As shown, in step S103 of this embodiment, when the results are fed back to the Git community platform, the results are packaged and automatically pushed back to the Git community platform (Git community repository or designated result distribution server) through the REST interface, so as to realize the real-time visibility of test results and version traceability. Its technical features include: (1) Real-time feedback mechanism: The test results can be pushed to the Git community repository or other designated platforms in real time, ensuring that developers can know the test results in time after submission. (2) Version traceability: Supports querying the results of historical versions, ensuring that each test can be traced back to the corresponding submission. Specifically, in this embodiment, the test results will be automatically pushed to the designated branch of the Git repository (such as result / report.json) through the REST interface, ensuring that developers can view the test results in real time. In addition, the Jenkins Dashboard or Web front-end will display the status of the test results in real time, including information such as success, failure or skip, so that developers can get feedback and respond in time.

[0028] As an optional implementation, to further improve team collaboration efficiency, step S103 of this embodiment, when feeding the results back to the Git community platform, also includes determining whether a push notification webpage hook is filled in the specified configuration. If a push notification webpage hook (such as a WeChat Work or DingTalk push notification webpage hook) is filled in, a push notification is executed to push the results to the user using the push notification webpage hook; otherwise, the notification is skipped. This allows for the integration of enterprise-level collaboration tools, ensuring that testers can receive test results in their commonly used work environments. It also enables automatic report uploading, with test report files automatically generated and uploaded, ensuring the shareability and archiving of results. Test results and generated Excel format test reports can be automatically pushed through the push notification webpage hook. The report will include information such as test name, test time, test results, and pipeline address, facilitating team members to quickly view, analyze, and process test results. Through seamless integration with collaboration tools, team members can receive test feedback promptly in their commonly used work platforms, thereby accelerating the response time for fixes and iterations.

[0029] In summary, the kernel automated testing method based on the Git community platform in this embodiment automatically triggers the test pipeline by monitoring the commit events of the Git repository in real time, and completes the kernel binary package pull, installation, automatic testing and result feedback. It can overcome the problems of manual triggering, test delay and result dispersion in the existing technology, thereby improving the efficiency of kernel community patch verification, ensuring cross-architecture consistency verification, and establishing a closed loop of the whole link from "code submission → automatic testing → result feedback". It solves the problems of low efficiency, delayed feedback and poor cross-architecture consistency in the traditional kernel verification process. Through the kernel automated testing method based on the Git community platform in this embodiment, the automation level of kernel testing can be effectively improved, the verification cycle can be shortened, cross-platform test consistency can be ensured, and the transparency and efficiency of community assistance can be improved. The characteristics of the kernel automated testing method based on the Git community platform in this embodiment are mainly reflected in the following aspects: (1) Event-driven kernel test triggering mechanism: This invention binds the push event of the Git community platform with the Jenkins pipeline for the first time, realizing an automated and real-time test triggering mechanism. Compared with traditional manual triggering or timed polling methods, this invention can greatly improve the response speed and efficiency of testing, ensuring that the test process can be triggered quickly after each code submission. This mechanism not only reduces the delay of manual operation, but also reduces human error through automated processing, significantly improving the collaborative efficiency of the development and testing process. (2) Cross-architecture kernel package automatic distribution and verification mechanism: This invention designs a unified binary package status detection module that can automatically identify and process compilation products from multiple architectures (such as x86_64, aarch64, etc.). This module supports dynamically pulling successfully compiled binary packages and can automatically deploy them to multiple virtual machine environments for testing. By supporting parallel deployment and multi-platform verification, this invention greatly improves the cross-architecture testing efficiency and coverage, ensuring the compatibility of kernel patches on different platforms. (3) Automatic feedback mechanism for writing test results back to the Git repository: This invention realizes the automatic synchronization of test results through the Git API, and automatically writes the test results back to the specified branch of the Git repository. In this way, developers can view the test status and results in real time without leaving the code repository, thus opening up the entire closed loop of "code submission → automatic testing → result feedback". This mechanism not only improves the transparency of collaboration, but also accelerates the patch repair and verification process, and improves development efficiency. (4) Modular and scalable design: The present invention adopts a loosely coupled modular structure in the system architecture design, ensuring that each functional module (such as monitoring agent, pipeline triggering, test execution, result write-back, etc.) can run independently and is easy to expand and replace. Through this design, the system can be easily integrated with other community platforms (such as Gitee, GitLab, etc.), has high portability and adaptability, and meets the needs of different open source projects and enterprise environments.(5) Higher overall system intelligence: This invention introduces an intelligent rule judgment mechanism, making test triggering more precise. For example, the system can determine whether a test needs to be executed based on the submitted content, triggering the test only when key kernel modules or configuration files are modified, thereby avoiding repeated testing of irrelevant code changes and reducing unnecessary consumption of computing resources. Through intelligent rule judgment, this invention not only optimizes resource utilization but also improves the accuracy and effectiveness of testing.

[0030] Furthermore, this embodiment also provides a kernel automated testing system based on the Git community platform, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to execute the kernel automated testing method based on the Git community platform. This embodiment also provides a computer-readable storage medium storing a computer program or instructions programmed or configured to execute the kernel automated testing method based on the Git community platform via a processor. This embodiment also provides a computer program product, including a computer program or instructions programmed or configured to execute the kernel automated testing method based on the Git community platform via a processor.

[0031] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0032] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A kernel automated testing method based on the Git community platform, characterized in that, Includes the following steps: S101, monitor the commit events of the Git community platform by deploying web page hooks on the Git community platform developed in the kernel. The commit events include code commit, merge and update events. If a commit event of the Git community platform is detected, send a test request to the preset monitoring service. S102, the monitoring service receives test requests from the Git community platform, extracts the commit information contained in the test requests, and triggers the corresponding test pipeline through the pipeline API; S103, The test pipeline determines whether the type of the commit event in the test request is a type that needs to be executed for kernel automated testing based on the commit information contained in the test request and the preset configuration file. If it is a type that needs to be executed for kernel automated testing, it schedules compilation detection and testing tasks applicable to different kernel architectures, feeds the results back to the Git community platform, and jumps to step S104; otherwise, it ends and exits. S104 is a Git community platform that records the results of kernel compilation, testing, and inspection tasks under different architectures.

2. The kernel automated testing method based on the Git community platform according to claim 1, characterized in that, The monitoring service preset in step S101 is implemented through a monitoring service module, which is configured to start automatically upon system boot.

3. The kernel automated testing method based on the Git community platform according to claim 1, characterized in that, When extracting the commit information contained in the test request in step S102, the commit information includes the PR proposer, PR number, commit branch and build result, and the build result includes indicators of whether the build and compilation were successful under various architectures.

4. The kernel automated testing method based on the Git community platform according to claim 3, characterized in that, In step S103, scheduling compilation detection and testing tasks applicable to different architectures includes allocating separate compilation detection and testing tasks for each architecture and recording the status information of each compilation detection and testing task. The kernel compilation detection and testing tasks for any given architecture include: S201, check the build result in the submission information contained in the test request, and determine whether the build and compilation success indicator under the current architecture is successful. If the build is successful, proceed to step S201; otherwise, proceed to step S207. S202, pulls the kernel binary package for the current architecture from the build server or a specified repository; S203, determine whether the test environment in the submission information contained in the test request can be connected. If the connection fails, report an error and exit, then proceed to step S207; otherwise, proceed to the next step. S204 loads the kernel binary package under the current architecture using a virtualization platform in a test environment; S205, Start the target virtual machine in the test environment, download the kernel binary package under the current architecture in the target virtual machine, and restart the target virtual machine to load the downloaded kernel binary package under the current architecture; S206: Perform functional verification and testing on the kernel binary package under the current architecture in the target virtual machine and collect logs, and obtain the test results based on the collected logs; S207 will feed the results back to the Git community platform.

5. The kernel automated testing method based on the Git community platform according to claim 4, characterized in that, In step S206, when performing functional verification and testing and collecting logs for the kernel binary package under the current architecture in the target virtual machine, it includes calling an automated testing toolset to perform functional verification and testing and collect logs for the kernel binary package under the current architecture in the target virtual machine. The functional verification and testing tools in the automated testing toolset include functional verification and testing tools for file systems, memory management, and hardware drivers.

6. The kernel automated testing method based on the Git community platform according to claim 4, characterized in that, Step S204 includes backing up the configuration and services in the virtual machine; step S206 includes restoring the configuration and services.

7. The kernel automated testing method based on the Git community platform according to claim 1, characterized in that, In step S103, when the result is fed back to the Git community platform, it also includes determining whether a push notification hook is filled in the specified configuration. If a push notification hook is filled in, a push notification is executed to push the result to the user using the push notification hook; otherwise, the notification is skipped.

8. A kernel automated testing system based on the Git community platform, comprising interconnected microprocessors and memory, characterized in that, The microprocessor is programmed or configured to execute the kernel automated testing method based on the Git community platform as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the kernel automated testing method based on the Git community platform as described in any one of claims 1 to 7 via a processor.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute the kernel automated testing method based on the Git community platform as described in any one of claims 1 to 7 via a processor.

Images