Code repository configuration method, code task processing method and code test method

Abstract

Provided in the embodiments of the present disclosure are a code repository configuration method, a code task processing method and a code test method. The code repository configuration method comprises: acquiring a configuration file of a target code repository and a test file; on the basis of the configuration file, performing environment configuration on the target code repository to obtain an initial configuration environment; testing the initial configuration environment by using a target test framework and the test file, and if the test has not passed, determining a missing dependency in the initial configuration environment; and installing the missing dependency in the initial configuration environment to obtain a target configuration environment of the target code repository. Performing automated environment configuration and testing on the basis of the configuration file and the test file reduces errors and uncertainties caused by manual operation, and a missing dependency in an initial configuration environment is detected and determined during a testing process and is installed in a timely manner, so as to reduce the time for manual debugging and error correction, thus improving the efficiency and reliability of code repository configuration.

Description

Code repository configuration methods, code task handling methods, and code testing methods

[0001] This disclosure claims priority to Chinese Patent Application No. 202510325543.9, filed with the China Patent Office on March 18, 2025, entitled “Code Repository Configuration Method, Code Task Processing Method and Code Testing Method”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the fields of computer technology and artificial intelligence technology, and in particular to code repository configuration methods, code task processing methods, and code testing methods. Background Technology

[0003] In software development, repository configuration is a fundamental step to ensure that code and related resources can be effectively managed, shared, and deployed. Proper repository configuration can optimize team collaboration, reduce problems caused by environmental differences, and accelerate the iteration and release process of software products.

[0004] Currently, code repository configuration typically relies on manual intervention. Developers step-by-step configure various parameters according to project documentation and troubleshoot errors through repeated trials. However, manual code repository configuration is extremely time-consuming and error-prone. Therefore, finding a more efficient and reliable automated configuration solution is crucial. Summary of the Invention

[0005] In view of the above, embodiments of this disclosure provide a code repository configuration method. One or more embodiments of this disclosure also relate to a code task processing method, a code testing method, a code repository configuration device, a code task processing device, a code testing device, a computing device, an electronic device, a computer-readable storage medium, and a computer program product, to address the technical deficiencies existing in the prior art.

[0006] According to a first aspect of the present disclosure, a code repository configuration method is provided, including:

[0007] Obtain the configuration files and test files of the target code repository;

[0008] Based on the configuration file, the target code repository is configured to obtain the initial configuration environment;

[0009] Using the target testing framework and test files, the initial configuration environment is tested. If the test fails, the missing dependencies of the initial configuration environment are identified.

[0010] In the initial configuration environment, missing dependencies are installed to obtain the target configuration environment for the target code repository.

[0011] According to a second aspect of the present disclosure, a code task processing method is provided, comprising:

[0012] Obtain task data for the target code task;

[0013] In the target configuration environment, the task data is processed to obtain the task processing results of the target code task. The target configuration environment is configured based on the code repository configuration method.

[0014] According to a third aspect of the present disclosure, a code testing method is provided, comprising:

[0015] Obtain the source code files for the code testing task;

[0016] In the target configuration environment, the source code files are tested to obtain the test results. The target configuration environment is configured based on the code repository configuration method.

[0017] According to a fourth aspect of the present disclosure, a code repository configuration apparatus is provided, comprising:

[0018] The first acquisition module is configured to acquire the configuration files and test files of the target code repository;

[0019] The configuration module is configured to configure the target code repository environment based on configuration files to obtain the initial configuration environment;

[0020] The first test module is configured to test the initial configuration environment using the target test framework and test files, and to identify the missing dependencies of the initial configuration environment if the test fails.

[0021] The installation module is configured to install missing dependencies in the initial configuration environment and obtain the target configuration environment of the target code repository.

[0022] According to a fifth aspect of the present disclosure, a code task processing apparatus is provided, comprising:

[0023] The second acquisition module is configured to acquire task data for the target code task.

[0024] The processing module is configured to process task data in a target configuration environment to obtain the task processing result of the target code task. The target configuration environment is configured based on the code repository configuration method.

[0025] According to a sixth aspect of the present disclosure, a code testing apparatus is provided, comprising:

[0026] The third acquisition module is configured to acquire the source code files of the code test task;

[0027] The second test module is configured to test the source code files in the target configuration environment and obtain the test results of the source code files. The target configuration environment is configured based on the code repository configuration method.

[0028] According to a seventh aspect of the present disclosure, a computing device is provided, comprising:

[0029] Memory and processor;

[0030] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the methods provided in the first, second, or third aspects described above.

[0031] According to an eighth aspect of the present disclosure, an electronic device is provided, comprising:

[0032] The memory and processor are connected via a bus;

[0033] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the methods provided in the first, second, or third aspects described above.

[0034] According to a ninth aspect of the present disclosure, a computer-readable storage medium is provided that stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in the first, second, or third aspects described above.

[0035] According to a tenth aspect of the present disclosure, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in the first, second, or third aspects described above.

[0036] This disclosure provides a code repository configuration method according to one embodiment, comprising: obtaining a configuration file and test files for a target code repository; configuring the environment of the target code repository based on the configuration file to obtain an initial configuration environment; testing the initial configuration environment using a target testing framework and test files, and identifying missing dependencies in the initial configuration environment if the test fails; and installing the missing dependencies in the initial configuration environment to obtain the target configuration environment of the target code repository. By automating environment configuration and testing based on configuration files and test files, errors and uncertainties caused by manual operations are reduced, saving time and ensuring the consistency of the configuration environment, reducing problems caused by environment differences. Furthermore, it does not rely on scripts or tools provided by continuous integration / continuous deployment platforms, overcoming the incompatibility issues of scripts across different platforms. Moreover, by identifying and promptly installing missing dependencies in the initial configuration environment during testing, the time spent on manual debugging and error correction is reduced, improving the efficiency and reliability of code repository configuration, ensuring the integrity and correctness of the development and testing environments, avoiding build failures or runtime errors caused by dependency issues, and improving the stability and efficiency of software development. Attached Figure Description

[0037] Figure 1 is an architecture diagram of a code repository configuration system provided in an embodiment of this disclosure;

[0038] Figure 2 is a flowchart of a code repository configuration method provided in an embodiment of this disclosure;

[0039] Figure 3 is a flowchart of a code task processing method provided in an embodiment of this disclosure;

[0040] Figure 4 is a flowchart of a code testing method provided in an embodiment of this disclosure;

[0041] Figure 5 is a flowchart of a code repository configuration method provided in an embodiment of this disclosure;

[0042] Figure 6 is a schematic diagram of a code repository configuration device provided in an embodiment of this disclosure;

[0043] Figure 7 is a schematic diagram of the structure of a code task processing device provided in an embodiment of the present disclosure;

[0044] Figure 8 is a schematic diagram of the structure of a code testing device provided in an embodiment of this disclosure;

[0045] Figure 9 is a structural block diagram of a computing device provided in an embodiment of this disclosure;

[0046] Figure 10 is a structural block diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0047] Numerous specific details are set forth in the following description to provide a full understanding of this disclosure. However, this disclosure can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this disclosure. Therefore, this disclosure is not limited to the specific implementations disclosed below.

[0048] The terminology used in one or more embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this disclosure. The singular forms “a,” “the,” and “the” used in one or more embodiments of this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” used in one or more embodiments of this disclosure refers to and includes any or all possible combinations of one or more associated listed items. The term “at least one” in one or more embodiments of this disclosure means “one or more,” and “a plurality of” means “two or more.” The term “comprising” is an open-ended description and should be understood as “including but not limiting,” and may include other content in addition to what has been described.

[0049] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this disclosure, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this disclosure, and similarly, second may also be referred to as first. Depending on the context, the word “if” as used herein may be interpreted as “when”, “in response to a determination”, or “when…”.

[0050] Furthermore, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this disclosure are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0051] In one or more embodiments of this disclosure, a large model refers to a deep learning model with a large number of model parameters, typically containing hundreds of millions, tens of billions, hundreds of billions, trillions, or even tens of trillions of model parameters. A large model can also be called a foundation model. It is pre-trained using large-scale unlabeled corpora to produce a pre-trained model with hundreds of millions of parameters. Such models can adapt to a wide range of downstream tasks and have good generalization ability. Examples include Large Language Models (LLMs) and multi-modal pre-training models.

[0052] In practical applications, large models only require a small number of samples to fine-tune the pre-trained model before they can be applied to different tasks. Large models can be widely used in fields such as Natural Language Processing (NLP) and Computer Vision. Specifically, they can be applied to computer vision tasks such as Visual Question Answering (VQA), Image Captioning (IC), and Image Generation, as well as natural language processing tasks such as text-based sentiment classification, text summarization, and machine translation. The main application scenarios for large models include digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0053] First, the terms and concepts involved in one or more embodiments of this disclosure will be explained.

[0054] Continuous Integration (CI) / Continuous Delivery (CD) refers to a practice in the software development process that aims to improve productivity and code quality by automating builds, tests, and deployments.

[0055] GitHub Actions refers to the CI / CD tools provided by GitHub, which allow developers to automate tasks such as building, testing, and deployment by defining workflows.

[0056] Pytest is a widely used Python testing framework that can be used to write various types of software tests, including unit tests, integration tests, end-to-end tests, and functional tests.

[0057] tox is an automated testing and build tool for Python projects, designed to simplify test environment management and support multiple Python interpreter versions. It helps developers easily run tests in different Python environments, ensures code compatibility, and supports CI / CI processes.

[0058] The conda virtual environment is a self-contained, independent runtime environment that allows multiple different versions of Python and related packages to be installed on the same machine without causing conflicts.

[0059] pipdeptree is a tool used to display Python package dependency trees, which can help developers analyze and manage dependencies in a project.

[0060] Multi-branch trees are a more generalized type of tree structure where each node can have more than two child nodes.

[0061] Docker is an open-source platform for automating the deployment, scaling, and management of applications. It uses containerization technology to package applications and their dependencies together, ensuring consistent operation across any environment. It provides a lightweight, portable runtime environment, simplifying consistency across development, testing, and production environments.

[0062] In many scenarios, executing project tests is crucial, such as evaluating code quality and coverage, validating code changes made by developers, and ensuring compatibility with dependencies. With the increasing prevalence of large-scale intelligent agents capable of autonomously editing project-level code, the demand for automated feedback on the correctness of code modifications is growing. Taking Python projects as an example, automating project testing is highly challenging because different Python projects use different configuration scripts, build commands, and testing frameworks, have complex dependencies, and often lack complete documentation. This makes creating reliable, universal, and efficient automated test execution methods across different projects extremely difficult.

[0063] Currently, repository configuration is typically done in the following ways: First, manual configuration, which involves manually following the project documentation and iterating to resolve errors. This method is very time-consuming and does not scale well with the number of projects. Second, using existing CI / CD workflows, whose execution usually depends on a specific CI / CD platform, such as GitHub Actions, and not all projects have such workflows. Furthermore, since multiple platforms offer similar functionality, each with its own configuration scripts, directly using CI / CD workflows becomes even more complex.

[0064] To address the aforementioned issues, this disclosure proposes an automated configuration and testing scheme for code repositories. The scheme includes: obtaining the configuration file and test files of the target code repository; configuring the environment of the target code repository based on the configuration file to obtain an initial configuration environment; testing the initial configuration environment using a target testing framework and test files, and identifying missing dependencies in the initial configuration environment if the test fails; and installing the missing dependencies in the initial configuration environment to obtain the target configuration environment for the target code repository. Furthermore, this scheme has been tested on a large-scale Python repository, achieving a very high configuration success rate. For example, experiments on 1000 Python repositories show that over 40% of the repositories have a test pass rate exceeding 50%.

[0065] This disclosure provides a code repository configuration method, and also relates to a code task processing method, a code testing method, a code repository configuration device, a code task processing device, a code testing device, a computing device, an electronic device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0066] Referring to Figure 1, Figure 1 shows an architecture diagram of a code repository configuration system provided in an embodiment of the present disclosure. The code repository configuration system may include a client 100 and a server 200.

[0067] Client 100 is used to send the configuration files and test files of the target code repository to server 200;

[0068] Server 200 is used to configure the environment of the target code repository based on the configuration file to obtain the initial configuration environment; to test the initial configuration environment using the target testing framework and test files; to identify the missing dependencies of the initial configuration environment if the test fails; and to install the missing dependencies in the initial configuration environment to obtain the target configuration environment of the target code repository.

[0069] The solution applied in this disclosure, through automated environment configuration and testing based on configuration files and test files, reduces errors and uncertainties caused by manual operations. This not only saves time but also ensures consistency in the configuration environment, mitigating problems caused by environmental differences. Furthermore, it overcomes the incompatibility issues of scripts across different platforms by not relying on scripts or tools provided by continuous integration / continuous deployment platforms. Moreover, by identifying and promptly installing missing dependencies in the initial configuration environment during testing, it reduces the time spent on manual debugging and error correction, improving the efficiency and reliability of code repository configuration. This ensures the integrity and correctness of the development and testing environments, avoids build failures or runtime errors due to dependency issues, and enhances the stability and efficiency of software development.

[0070] In practical applications, a code repository configuration system may include a server 200 and multiple clients 100. Clients 100 may include edge devices, and server 200 may include cloud-side devices. Multiple clients 100 can establish communication connections through server 200. In the code repository configuration scenario, server 200 provides code repository configuration services between multiple clients 100. Each client 100 can act as a sender or receiver, communicating through server 200. Users can interact with server 200 through client 100 to receive data from other clients 100 or send data to other clients 100. In the code repository configuration scenario, users can publish data streams to server 200 through client 100, and server 200 configures the target configuration environment of the target code repository based on these data streams. Clients 100 and server 200 establish a connection through a network. The network provides the medium for communication between clients 100 and server 200. The network can include various connection types, such as wired, wireless communication links, or fiber optic cables. The data transmitted by client 100 may need to be processed such as encoding, transcoding, and compression before being published to server 200.

[0071] Client 100 can be a browser, application (APP), web application such as HyperText Markup Language 5 (H5), or a lightweight application (also known as a mini-program), or cloud application, etc. Client 100 can be developed based on the software development kit (SDK) of the corresponding service provided by server 200, such as based on the Real-Time Communication (RTC) SDK. Client 100 can be deployed in electronic devices and depends on the device to run or on certain APPs on the device. Electronic devices may have a display screen and support information browsing, such as personal mobile terminals such as mobile phones, tablets, and personal computers. Various other types of applications can also be configured in electronic devices, such as human-computer interaction applications, model training applications, text processing applications, web browser applications, shopping applications, search applications, instant messaging tools, email clients, social platform software, etc.

[0072] Server 200 may include servers providing various services, such as servers providing communication services to multiple clients, servers supporting backend training of models used on clients, and servers processing data sent by clients. It should be noted that server 200 can be implemented as a distributed server cluster composed of multiple servers, or as a single server. The server can also be a server in a distributed system, or a server integrated with blockchain. The server can also be 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, content delivery networks (CDNs), and big data and artificial intelligence platforms, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology.

[0073] It is worth noting that the code repository configuration method provided in this disclosure is generally executed by the server. However, in other embodiments of this disclosure, the client may also have similar functionality to the server, thereby executing the code repository configuration method provided in this disclosure. In other embodiments, the code repository configuration method provided in this disclosure can also be executed jointly by the client and the server. Next, taking the server executing the code repository configuration method proposed in this disclosure as an example, the implementation process of the code repository configuration method will be described.

[0074] Referring to Figure 2, Figure 2 shows a flowchart of a code repository configuration method provided in an embodiment of this disclosure, which specifically includes the following steps:

[0075] Step 202: Obtain the configuration files and test files of the target code repository.

[0076] It's important to note that a target code repository refers to the location where all source code, configuration files, test files, and other related resources for a specific project or application are centrally stored during software development. A target code repository is typically a specific repository within a version control system (such as GitHub, GitLab, Bitbucket, etc.) used to manage and track the project's development progress and historical changes. Target code repositories can be of different types, such as Python repositories, Java repositories, etc. A Python repository contains code, libraries, and related resources written in the Python language. A Java repository contains code, libraries, and related resources written in the Java language.

[0077] Configuration files are files that contain various settings and parameters required for a project to run (such as environment variables, dependency lists, path configurations, etc.). Configuration files provide the necessary information for building, testing, and deploying the project, ensuring all developers work in the same environment and reducing problems caused by environment differences. For example, configuration files can include the ci.yaml series, tox.ini, requirement.txt series, requirement.lock series, environment.yml, pyproject.toml, and setup.py for GitHub workflows. GitHub workflow is a core concept of GitHub Actions, allowing automation of various tasks in software development, such as building, testing, and deployment. By writing workflow files (usually ci.yaml or similar YAML files), a series of steps or jobs can be defined to be executed automatically when specific events are triggered. The ci.yaml series refers to a set of YAML configuration files used to define CI and CD workflows. tox.ini is the configuration file for the tox tool, used to manage virtual environments and automated testing. requirement.txt lists the Python packages and their versions required by the project, facilitating the installation of all dependencies via pip. `requirement.lock` ensures that the exact same dependency versions are installed in different environments, avoiding problems caused by version inconsistencies. `environment.yml` describes the dependency packages and environment variables required to create a conda virtual environment. `pyproject.toml` unifies the build system configuration, not limited to Python package builds. `setup.py` defines how Python packages are installed and distributed, including metadata and dependencies.

[0078] Test files are files containing various test cases used to verify the correctness of a project's functionality. The testing process can be unit testing, integration testing, or end-to-end testing. Executing test files ensures code quality and stability, and allows for timely detection of whether newly introduced features or changes break existing code functionality. For example, in Python repositories, test files follow the Pytest rule: .py files that begin or end with "test" are considered test files.

[0079] In practical applications, if a target code repository lacks a corresponding configuration file or test file, the configuration and testing of that target code repository can be ignored. The configuration file allows for the initial configuration environment to be set up for the target code repository, and the test file then verifies whether the initial configuration environment has been successfully configured. There are multiple ways to obtain the configuration file and test file of the target code repository; the specific method should be chosen based on the actual situation, and this disclosure does not impose any limitations on this. In one possible implementation of this disclosure, the configuration file and test file of the target code repository can be downloaded from the version control system. In another possible implementation of this disclosure, the configuration file and test file of the target code repository can be obtained by executing Git command-line tools and performing commands such as `git clone` and `git pull`.

[0080] Step 204: Configure the target code repository environment based on the configuration file to obtain the initial configuration environment.

[0081] It's important to note that configuring the target code repository environment based on configuration files refers to setting up the development, testing, or production environment according to the commands in the configuration file, including installing necessary software packages and setting environment variables. Configuring the target code repository environment ensures that the project can run correctly in the specified environment, providing a consistent foundational environment to support development, testing, and deployment activities. The initial configuration environment refers to the development or testing environment after initial setup according to the configuration file. The initial configuration environment can serve as a foundation for further testing, helping to identify potential problems or missing parts during the configuration process.

[0082] In practical applications, there are multiple ways to configure the target code repository environment based on configuration files to obtain the initial configuration environment. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. In one possible implementation, all configuration commands in the configuration file can be executed to configure the target code repository environment and obtain the initial configuration environment. In another possible implementation, multiple configuration sub-files can be executed according to their priority in the configuration file to configure the target code repository environment and obtain the initial configuration environment.

[0083] For example, the first step can be to use a ci.yaml file containing the command 'Pytest' or 'tox' to extract the job section where 'Pytest' or 'tox' first appears. Parse the commands containing 'setup', 'install', and 'conda' in the job section and execute them. Here, 'setup' refers to setting up or configuring the project or environment. 'install' indicates installing packages, libraries, or other resources to the system or a specific environment. The second step can be to use a tox.ini file containing 'Pytest' to extract the testenv section where 'Pytest' first appears, and parse the 'deps' and 'commands' sections within the testenv section. Use 'pip install' to install the contents of 'deps', and execute the 'commands' directly. The testenv section is an important part of the tox.ini configuration file; it is used to define and configure different test environments for running tests in these environments. The deps section lists all dependencies required to run the tests. These dependencies typically include Python packages, but can also be other types of dependencies. The commands section lists the commands to be executed in the test environment; these commands are typically used to run the test suite. `pip install` is a command-line tool for Python used to install Python packages. The third step involves executing the corresponding commands directly for common configuration files such as `requirement.txt`, `requirement.lock`, `environment.yml`, `pyproject.toml`, and `setup.py`, without additional parameters, to obtain the initial configuration environment. During automated configuration file parsing and execution, various configuration files in the Python project (such as `ci.yaml`, `tox.ini`, and `requirement.txt`) are analyzed to automatically extract and execute relevant configuration commands, reducing manual intervention.

[0084] In one optional embodiment of this disclosure, before executing the configuration file, the code language version of the target code repository can be determined, and the conda virtual environment can be installed. That is, the above-mentioned environment configuration of the target code repository based on the configuration file to obtain the initial configuration environment may include the following steps:

[0085] Parse the configuration file to determine the code language version of the target code repository.

[0086] Based on the code language version, the configuration file is executed to obtain the initial configuration environment of the target code repository.

[0087] It's important to note that the code language version refers to the version of the programming language used by the project in the target code repository. The code language version can be a version range or a specific version number, such as Python 3.8, Java 11, Node.js 14, etc. Optionally, Python version 3.9 is preferred, with 3.11 being the highest.

[0088] In practical applications, there are various methods for parsing configuration files and determining the code language version of the target code repository. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. One possible implementation of this disclosure is to determine the code language version through information matching: the configuration file is parsed for keywords to obtain language description information including code language keywords; this language description information is matched with candidate description information for each candidate language version; and the candidate language version corresponding to the successfully matched candidate description information is determined as the code language version. Another possible implementation of this disclosure is to utilize a version determination model to determine the code language version.

[0089] By applying the solution of this disclosure embodiment, by determining the code language version of the target code repository, it can be ensured that a consistent code language version is used in the development and production environments, thus avoiding problems caused by version differences.

[0090] In one possible implementation of this disclosure, the process of parsing the configuration file and determining the code language version of the target code repository may include the following steps:

[0091] The configuration file is parsed to obtain language description information, including code language keywords.

[0092] Input the language description information into the version determination model to obtain the code language version of the target code repository.

[0093] It should be noted that keyword parsing refers to the process of extracting information related to the programming language and its version from a configuration file. Keyword parsing involves reading the configuration file, searching for keywords, and extracting language description information. Language description information refers to the specific description of the code language and its version extracted from the configuration file.

[0094] Language description information includes, but is not limited to, language names (Python, Java) and version requirements. A version determination model is a model used to analyze language description information and determine the code language version. This model can be a large model or a deep learning model trained based on sample code language versions and their corresponding sample language description information.

[0095] For example, the configuration file can be parsed to obtain language description information containing the code language keyword 'Python' in the configuration file. The language description information can be input into the version determination model to obtain the appropriate Python version range or Python version number output by the version determination model.

[0096] The solution using the embodiments of this disclosure, by parsing the configuration file and using the version determination model to infer the code language version of the target code repository, not only achieves intelligent code language version selection, but also considers the broad compatibility of versions, solves the dependency problem of different projects on code language versions, and ensures higher compatibility.

[0097] In one optional embodiment of this disclosure, the above-described environment configuration of the target code repository based on the configuration file to obtain the initial configuration environment may include the following steps:

[0098] Parse the configuration file to determine the multiple configuration subfiles within it and their priorities.

[0099] Based on priority, multiple configuration sub-files are executed to obtain the initial configuration environment for the target code repository.

[0100] It's important to note that configuration subfiles are components of the configuration file. For example, a configuration file might include a ci.yaml file containing the 'Pytest' or 'tox' command, and another tox.ini file containing 'Pytest'. The priority of a configuration subfile refers to its execution order, determining the final execution command within each subfile. For instance, the ci.yaml file containing the 'Pytest' or 'tox' command has a higher priority than the tox.ini file containing 'Pytest'.

[0101] In practical applications, there are multiple ways to parse configuration files and determine the priorities of multiple configuration subfiles within them. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. One possible implementation of this disclosure is to determine the priority of each configuration subfile based on its filename. Another possible implementation is to search for the priority of each configuration subfile in a pre-set file priority list.

[0102] Furthermore, there are multiple ways to execute multiple configuration sub-files according to priority to obtain the initial configuration environment of the target code repository. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. In one possible implementation, all configuration commands in each configuration sub-file can be executed according to priority to obtain the initial configuration environment of the target code repository. In another possible implementation, the configuration commands to be executed in each configuration sub-file can be determined according to priority, and then these commands can be executed to obtain the initial configuration environment of the target code repository. For example, configuration commands or configuration sub-files that have already been executed are skipped.

[0103] By applying the solution of this disclosure embodiment, multiple configuration sub-files are executed according to priority, and the configuration priority can be dynamically adjusted according to needs, making the configuration process of the initial configuration environment more flexible.

[0104] In one optional embodiment of this disclosure, taking two configuration sub-files as an example, the multiple configuration sub-files include a first configuration sub-file and a second configuration sub-file, with the first configuration sub-file having a higher priority than the second configuration sub-file; the above-mentioned execution of multiple configuration sub-files according to priority to obtain the initial configuration environment of the target code repository may include the following steps:

[0105] From the second configuration sub-file, the configuration commands to be deleted are determined, wherein the configuration commands to be deleted are the configuration commands that are included in both the first and second configuration sub-files.

[0106] Delete the configuration command to be deleted in the second configuration sub-file to obtain the deleted second configuration sub-file.

[0107] Execute the first configuration sub-file and the deleted second configuration sub-file to obtain the initial configuration environment of the target code repository.

[0108] It should be noted that because the first configuration subfile has a higher priority than the second configuration subfile, all configuration commands in the first configuration subfile will be executed. The second configuration file may contain configuration commands that appear in both the first and second configuration subfiles; these commonly appearing configuration commands can be referred to as the configuration commands to be deleted in the second configuration file.

[0109] In practical applications, there are multiple ways to obtain the initial configuration environment of the target code repository by executing the first configuration sub-file and the deleted second configuration sub-file. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. In one possible implementation, the first configuration sub-file can be executed first, followed by the deleted second configuration sub-file. In another possible implementation, since the deleted second configuration sub-file no longer includes the configuration commands present in the first configuration sub-file, both the first and deleted second configuration sub-files can be executed simultaneously, improving the execution efficiency of the configuration sub-files.

[0110] By applying the solution of this disclosure embodiment, deleting configuration commands that also appear in the first configuration subfile in the second configuration subfile can reduce the number of configuration commands that need to be executed, avoid repeatedly executing the same configuration commands, and improve the execution efficiency of the configuration file.

[0111] Step 206: Use the target testing framework and test files to test the initial configuration environment. If the test fails, identify the missing dependencies of the initial configuration environment.

[0112] It's important to note that the target testing framework is suitable for testing the initially configured environment using test files, such as unittest or Pytest. The target testing framework can be a pre-specified framework or a framework selected from multiple candidate frameworks. Installing and using the target testing framework to execute tests simplifies the testing process and improves testing efficiency and coverage. Dependencies refer to external resources necessary for the project to run or build the target code repository, typically including libraries, frameworks, and tools. Missing dependencies are dependencies declared in the project but not correctly installed or configured (such as libraries and tools). The reasons for missing dependencies include, but are not limited to, configuration errors, network problems, and version conflicts. Identifying missing dependencies clarifies what needs to be added, allowing for the fixing of environment configuration issues and ensuring that all dependencies are met, thus enabling the project to function correctly.

[0113] In practical applications, the initial configuration environment is tested using the target testing framework and test files. After obtaining the test results, if the test results indicate that the test passed, the initial configuration environment can be identified as the target configuration environment; if the test results indicate that the test failed, the missing dependencies of the initial configuration environment can be identified. There are multiple ways to determine the missing dependencies of the initial configuration environment, and the specific method is selected according to the actual situation. This disclosure does not limit this method. In one possible implementation of this disclosure, the command-line function provided by the package management tool can be used to automatically determine the missing dependencies of the initial configuration environment. In another possible implementation of this disclosure, an information determination model can be used to determine the missing dependencies of the initial configuration environment based on test error information.

[0114] For example, you can install the target testing framework (Pytest 3.10). For Django-related repositories, you typically need to configure the `Pytest.ini` file to provide Django settings when Pytest runs. If `[tool:Pytest]` exists in `setup.cfg`, or `[tool.Pytest.ini_options]` exists in `pyproject.toml`, then the repository has already provided the configuration parameters, and no further configuration is needed. Otherwise, you need to find the relative path to `settings.py` and add it to `Pytest.ini`. If Pytest was not installed in the previous steps, you need to determine the target testing framework based on the pass rates of different candidate testing frameworks. For Django-related projects, you also need to install `Pytest-django`. Django is a high-level, open-source Python web framework designed for rapid development of secure and maintainable websites. Django-related repositories mainly refer to codebases used to support Django development, extend its functionality, or provide examples and tools. Configuring the `Pytest.ini` file means configuring a `Pytest.ini` file to specify Django settings. Because Pytest itself doesn't directly understand Django's environment and configuration requirements, configuration files tell Pytest how to work with Django. `setup.cfg` is a configuration file typically used for building and deploying Python projects. The `[tool:Pytest]` section, located in either `setup.cfg` or `Pytest.ini`, configures Pytest's behavior. By defining the `[tool:Pytest]` section in the configuration file, various options can be specified to customize how tests run, eliminating the need to specify these options on the command line each time. `pyproject.toml` is a standardized configuration file used to specify the build system requirements and other project-related settings. `[tool.Pytest.ini_options]` is a configuration section in `pyproject.toml` that specifies configuration options for the Pytest test runner. The `settings.py` file is one of the core configuration files in a Django project, containing various project settings and configuration items. This file defines almost all parameters related to project configuration, including database connections, debugging options, static file handling, middleware, template settings, and security settings. Pytest-django is a Pytest plugin that makes testing Django projects using Pytest simpler and more efficient.Pytest is a powerful and easy-to-use Python testing framework, while Pytest-django extends Pytest's functionality by specifically supporting Django framework features such as database handling and Django settings management.

[0115] In one optional embodiment of this disclosure, the method for selecting the target testing framework is described. That is, before testing the initial configuration environment using the target testing framework and test files, the following steps may be included:

[0116] The initial configuration environment is tested using multiple candidate test frameworks and test files to obtain multiple test metrics, which correspond one-to-one with the candidate test frameworks.

[0117] The target test framework is selected from multiple candidate test frameworks based on multiple test metrics.

[0118] It should be noted that multiple candidate test frameworks refer to tools or libraries used to organize and run test files. These candidate test frameworks can be completely different frameworks or different versions of the same framework. For example, candidate test frameworks could include different versions of Pytest. Test metrics are used to describe the pass / fail performance of the candidate test frameworks when testing the initial configuration environment. Test metrics can be pass rate or pass level, such as high pass rate or low pass rate. The target test framework refers to the candidate test framework with the highest pass level or pass rate among the multiple candidate test frameworks.

[0119] In practical applications, there are various ways to select the target test framework from multiple candidate test frameworks based on multiple test metrics. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. In one possible implementation, candidate test frameworks with test metrics exceeding a test metric threshold can be identified as the target test framework, where the test metric threshold is set according to the actual situation. In another possible implementation, test metrics can be sorted from largest to smallest, and the candidate test frameworks ranked highest can be identified as the target test framework.

[0120] Furthermore, when testing the initial configuration environment using multiple candidate test frameworks and test files, errors may occur during the testing process for any candidate test framework. In this case, the missing dependencies of the candidate test framework can be identified, and the missing dependencies can be installed. After installation, the candidate test framework that did not produce any errors can then be used for testing to obtain the corresponding test metrics for that candidate test framework.

[0121] The solution of this disclosure embodiment uses the test metrics of each candidate test framework to select the target test framework with better test performance from multiple candidate test frameworks, making the test process more accurate.

[0122] Step 208: In the initial configuration environment, install the missing dependencies to obtain the target configuration environment for the target code repository.

[0123] It should be noted that installing missing dependencies refers to the process of taking corresponding measures (such as using package management tools to install missing libraries or directly executing the installation command corresponding to the missing dependency) to improve the environment configuration. There are multiple ways to determine the installation command corresponding to the missing dependency, and the specific method should be selected based on the actual situation. This disclosure does not impose any limitations on this method. In one possible implementation of this disclosure, the installation command corresponding to the missing dependency can be read from a command library. In another possible implementation of this disclosure, the test error information input information determination model can be used to obtain the missing dependencies of the initial configuration environment and the installation command for the missing dependencies. Installing missing dependencies can fill the deficiencies in the initial configuration environment, ensuring that all dependencies of the project are correctly installed and configured, and avoiding functional failures or errors caused by missing dependencies. The target configuration environment refers to the complete and correct development or testing environment that ultimately meets the expected requirements. The target configuration environment can provide a stable and reliable working environment, supporting efficient development, testing, and deployment of the project, while reducing potential risks caused by inconsistencies in the environment.

[0124] In practical applications, there are multiple ways to install missing dependencies in the initial configuration environment to obtain the target configuration environment for the target code repository. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. One possible implementation of this disclosure is to directly install the missing dependencies in the initial configuration environment, thus defining the initial configuration environment with the missing dependencies as the target configuration environment for the target code repository. Another possible implementation involves iteratively testing the initial configuration environment with the missing dependencies after installation until it passes the test, thereby obtaining the target configuration environment for the target code repository.

[0125] The solution applied in this disclosure automates the configuration and testing of large-scale target code repositories, reducing manual intervention and improving efficiency. Compared to manual configuration, it significantly reduces the time required for configuration and testing and can scale with the number of projects. Furthermore, this solution does not rely on a specific CI / CD platform but directly parses and executes configuration files in the project, enabling it to work in various environments, overcoming the incompatibility issues of scripts across different platforms, and improving cross-platform applicability.

[0126] In one optional embodiment of this disclosure, determining the missing dependencies of the initial configuration environment when the test fails may include the following steps:

[0127] If the test fails, retrieve the test error message.

[0128] The test error message is used to determine the model and obtain the missing dependencies of the initial configuration environment and the installation commands for the missing dependencies.

[0129] In the initial configuration environment, installing missing dependencies and obtaining the target configuration environment for the target code repository can include the following steps:

[0130] In the initial configuration environment, missing dependencies are installed using installation commands to obtain the target configuration environment for the target code repository.

[0131] It should be noted that test error messages refer to error logs or exception information generated when running test files using the target testing framework. Test error messages typically include the specific reason why the test failed, the location of the failure, and possible related context. Missing dependencies can be identified through test error messages. An information determination model is a model used to analyze test error messages and extract missing dependencies. Optionally, the information determination model can not only provide the missing dependencies but also the installation commands for those dependencies. In the initial configuration environment, the installation commands for the missing dependencies can be executed directly to obtain the target configuration environment of the target code repository. The information determination model for installing missing dependencies based on installation commands can be a large model or a deep learning model trained based on sample missing dependencies and their corresponding sample test error messages.

[0132] In practical applications, there are various ways to obtain test error information, and the specific method chosen depends on the actual situation. This disclosure does not impose any limitations on these methods. One possible implementation of this disclosure involves receiving test error information from the target testing framework. Another possible implementation involves parsing test error information from test logs.

[0133] The solution of this disclosure uses an information determination model to identify missing dependencies based on error information. It can also provide missing dependencies and installation commands, which improves the test pass rate and reduces the time for manual debugging and error correction. It is particularly effective when testing projects with complex dependencies, and realizes automated dynamic dependency management and error correction.

[0134] In one optional embodiment of this disclosure, the process of installing missing dependencies in the initial configuration environment to obtain the target configuration environment for the target code repository may include the following steps:

[0135] In the initial configuration environment, missing dependencies are installed to obtain an updated initial configuration environment.

[0136] Return to the steps of testing the initial configuration environment using the target testing framework and test files. If the test passes, obtain the target configuration environment of the target code repository.

[0137] It should be noted that the updated initial configuration environment refers to an initial configuration environment that has already installed the missing dependencies. Since the updated initial configuration environment may still have some untested missing dependencies, you can go back and execute the steps to test the initial configuration environment using the target testing framework and test files until the tests pass, thus obtaining the target configuration environment of the target code repository.

[0138] By applying the solution of this disclosure embodiment, iterative testing and installation of missing dependencies are performed on the initial configuration environment to ensure the stability and reliability of the target configuration environment.

[0139] In one optional embodiment of this disclosure, after obtaining the target configuration environment of the target code repository, the target configuration environment can be stored in a database. Furthermore, since the configuration files of different code repositories may have overlapping parts, these code repositories can share a single configuration environment. Therefore, a new configuration environment can be generated for these code repositories, and the regenerated configuration environment can be stored in the database, reducing the amount of data stored in the database.

[0140] In one optional embodiment of this disclosure, after installing missing dependencies and obtaining the target configuration environment for the target code repository in the initial configuration environment, the following steps may be further included:

[0141] Retrieves a specified configuration file from a specified code repository.

[0142] Based on the specified configuration file, construct the specified configuration graph of the specified code repository, and based on the configuration file of the target code repository, construct the target configuration graph of the target code repository.

[0143] If the specified configuration graph and the target configuration graph meet the graph merging conditions, the environment is configured according to the specified configuration file and the configuration file to obtain the updated target configuration environment. The updated target configuration environment is a configuration environment shared by the target code repository and the specified code repository.

[0144] It should be noted that the specified code repository refers to a code repository other than the target code repository. The specified configuration file refers to the configuration file of the specified code repository. The specified configuration graph is constructed based on the specified dependency packages in the specified configuration file as nodes, and the dependency relationships between the specified dependency packages are constructed as edges. The key of the node in the specified configuration graph is the specified identifier information of the specified dependency package, and the value of the node in the specified configuration graph is the specified version information of the specified dependency package. The target configuration graph is constructed based on the target dependency packages in the configuration file of the target code repository as nodes, and the dependency relationships between the target dependency packages are constructed as edges. The key of the node in the target configuration graph is the target identifier information of the target dependency package, and the value of the node in the target configuration graph is the target version information of the target dependency package. The target identifier information is used to uniquely identify the target dependency package, such as the name of the target dependency package. The target version information can be the signed version number of the target dependency package (e.g., ≥1.20.3). The specified configuration graph and the target configuration graph can be a multi-way tree structure. The graph merging condition refers to the condition used to determine whether the specified configuration graph and the target configuration graph can be merged into a single graph. The conditions for merging configuration graphs include differences between the specified and target identifier information, the same specified and target identifier information, and overlap between the specified and target version information. The specific conditions for merging are selected based on the actual situation, and this embodiment does not impose any limitations on them. If the specified configuration graph and the target configuration graph meet the conditions for merging, it means that the target code repository and the specified code repository can share a configuration environment, or it can be understood that the target code repository and the specified code repository can have their configuration environments merged.

[0145] In practical applications, there are multiple ways to construct a specified configuration graph of a specified code repository based on a specified configuration file. The specific method chosen depends on the actual situation, and this disclosure does not impose any limitations on this approach. One possible implementation of this disclosure involves constructing the specified configuration graph using specified dependency packages in the specified configuration file as nodes and the dependency relationships between these packages as edges. Another possible implementation involves calling pipdeptree to construct the specified configuration graph of the specified code repository based on the specified configuration file. The implementation of "constructing the target configuration graph of the target code repository based on the target code repository's configuration file" can refer to the implementation of "constructing the specified configuration graph of the specified code repository based on a specified configuration file," and will not be elaborated upon further in this disclosure.

[0146] Furthermore, when configuring the environment based on the specified configuration file and configuration file to obtain the updated target configuration environment, the specified configuration file and configuration file can be merged to obtain a merged configuration file. Then, the specified test files from the specified code repository and the test files from the target code repository can be merged to obtain merged test files. Based on the merged configuration file, the environment is configured to obtain an initial merged configuration environment. The initial merged configuration environment is tested using the target test framework and merged test files. If the test fails, the missing merge dependencies in the initial merged configuration environment are identified. Finally, the missing merge dependencies are installed in the initial merged configuration environment to obtain the updated target configuration environment.

[0147] The solution applied in this disclosure optimizes resource usage and avoids redundant installations of the same dependencies by constructing configuration graphs for each code repository (including specified and target code repositories) and merging Docker environments from compatible code repositories. This merging strategy makes environment configuration more efficient, especially under resource constraints.

[0148] In one optional embodiment of this disclosure, the nodes of the specified configuration graph are specified dependency packages in a specified configuration file, and the specified dependency packages carry at least one of specified identification information and specified version information; the nodes of the target configuration graph are target dependency packages in the configuration file, and the target dependency packages carry at least one of target identification information and target version information; after constructing the specified configuration graph of the specified code repository according to the specified configuration file, and constructing the target configuration graph of the target code repository according to the configuration file of the target code repository, the following steps may be further included:

[0149] If the specified identification information and the target identification information are different, determine that the specified configuration map and the target configuration map meet the map merging conditions.

[0150] If the specified identifier information and the target identifier information are the same, and the specified version information and the target version information overlap, then the specified configuration map and the target configuration map meet the map merging conditions.

[0151] It should be noted that after constructing the specified configuration graph and the target configuration graph, it can be determined whether the target code repository and the specified code repository can share a configuration environment. Specifically, if the specified configuration graph of any specified code repository and the target configuration graph do not meet the graph merging conditions, it means that the two configuration graphs cannot be merged, and the two code repositories cannot share a configuration environment; the configuration environments of each code repository need to be stored separately. If the specified configuration graph of any specified code repository and the target configuration graph meet the graph merging conditions, it means that the two configuration graphs can be merged, and the two code repositories can also share a configuration environment; the shared configuration environment of the two code repositories can be regenerated.

[0152] For example, suppose there are two different code repositories, with configuration graphs A-tree and B-tree respectively. In one possible implementation, at the first level, if a node N in tree B has the same key as a node in tree A, and their values ​​intersect, then the subtree rooted at N in tree B can be merged into the corresponding position in tree A. If a node N in tree B has the same key as a node in tree A, but their values ​​do not intersect, then the two trees cannot be merged. In another possible implementation, at the first level, only the node M corresponding to the key appearing in tree B is used as the root node to construct a subtree. A search is then conducted in tree A for nodes with the same key. If the values ​​of all nodes with the same key intersect, then the subtree rooted at M can be merged into the corresponding position at the first level of tree A. If no intersection exists, then the two trees cannot be merged. The resulting new tree can then be merged with the remaining trees, and so on, until finally, the remaining trees cannot be merged.

[0153] The solution of this disclosure embodiment determines whether the specified configuration map and the target configuration map can be merged by specifying the identifier information and the target identifier information, specifying the version information and the target version, making the judgment process more flexible and comprehensive.

[0154] Referring to Figure 3, Figure 3 shows a flowchart of a code task processing method provided in an embodiment of this disclosure, which specifically includes the following steps:

[0155] Step 302: Obtain the task data for the target code task.

[0156] Step 304: In the target configuration environment, process the task data to obtain the task processing result of the target code task. The target configuration environment is configured based on the code repository configuration method.

[0157] It's important to note that a target code task refers to a specific task or operation that needs to be performed in the project corresponding to the target code repository, such as a code build task, code testing task, or code deployment task. Task data refers to the input data or configuration information related to the target code task. Task data includes, but is not limited to, source code files, test data, environment variables, and configuration files. The target configuration environment refers to the runtime environment configured based on the code repository configuration method, containing all necessary dependencies and tools to ensure the successful execution of the target code task. Task processing results refer to the output generated after executing the target code task in the target configuration environment. Task processing results include, but are not limited to, logs, reports, and test results. The task processing results provide feedback on the execution of the target code task, helping developers understand whether the task was successfully completed and to proceed with subsequent operations.

[0158] In practical applications, there are various ways to obtain task data for target code tasks, and the specific method chosen depends on the actual situation. This disclosure does not impose any limitations on these methods. In one possible implementation, target code task data can be received from a user via a client. In another possible implementation, target code task data can be read from other databases or data acquisition devices.

[0159] By applying the scheme of this disclosure embodiment, the target configuration environment is configured based on the code repository configuration method, ensuring that all dependencies and configurations in the target code repository are correctly installed and set, thereby creating a stable and reliable runtime environment. Then, processing task data in the target configuration environment avoids problems caused by environmental differences, ensuring that the target code tasks run consistently on different machines.

[0160] Referring to Figure 4, Figure 4 shows a flowchart of a code testing method provided in an embodiment of this disclosure, which specifically includes the following steps:

[0161] Step 402: Obtain the source code files for the code testing task.

[0162] Step 404: In the target configuration environment, test the source code file and obtain the test results of the source code file. The target configuration environment is configured based on the code repository configuration method.

[0163] It's important to note that code testing refers to a series of operations performed during software development to verify and evaluate the quality, performance, and correctness of source code. Code testing includes, but is not limited to, designing test cases, running these tests to check if the code's functionality meets expectations, identifying and logging errors or defects, and ultimately ensuring that the software product meets user needs and project goals. Source code files are the original program code written by programmers, typically existing as text files. Source code files contain a set of instructions to implement specific functions or solve specific problems, written in one or more programming languages. Testing source code files in the target configuration environment refers to the process of evaluating the functionality, reliability, performance, and security of the source code files in an environment that ensures their correct operation. The test results of source code files refer to the data and information obtained after completing a series of tests on the source code files, including but not limited to discovered problems or defects, performance indicators, etc. The test results of source code files are used to determine the quality of the source code and whether it meets the established requirements.

[0164] In practical applications, the implementation methods of steps 402 to 404 are the same as those of steps 302 to 304, and will not be described again in this embodiment.

[0165] By applying the scheme of this disclosure embodiment, the target configuration environment is configured based on the code repository configuration method, ensuring that all dependencies and configurations in the target code repository are correctly installed and set, thereby creating a stable and reliable runtime environment. Then, testing the source code files in the target configuration environment avoids problems caused by environmental differences and ensures the accuracy of the test results for the source code files.

[0166] The code repository configuration method proposed in this disclosure will be further described below with reference to Figure 5. Figure 5 shows a flowchart of the processing procedure of a code repository configuration method according to an embodiment of this disclosure, specifically including six stages: configuration and test file acquisition stage, code language version determination stage, configuration file execution stage, test framework installation stage, test and environment configuration correction stage, and configuration environment merging stage. These six stages will now be described in detail.

[0167] Configuration and test file acquisition phase: Acquire the configuration files and test files of the target code repository.

[0168] Code language version determination stage: The configuration file is parsed to obtain language description information including code language keywords; the language description information is input into the version determination model to obtain the code language version of the target code repository.

[0169] Configuration file execution phase: Parse the configuration file, determine the multiple configuration sub-files in the configuration file and the priority of the multiple configuration sub-files; according to the priority and code language version, execute multiple configuration sub-files to obtain the initial configuration environment of the target code repository.

[0170] Test framework installation phase: Using multiple candidate test frameworks and test files, the initial configuration environment is tested to obtain multiple test metrics, in which each test metric corresponds one-to-one with a candidate test framework; based on multiple test metrics, the target test framework is selected from the multiple candidate test frameworks.

[0171] Testing and Environment Configuration Correction Phase: Using the target testing framework and test files, test the initial configuration environment. If the test fails, obtain the test error information. Input the test error information into the information determination model to obtain the missing dependencies of the initial configuration environment. Install the missing dependencies in the initial configuration environment to obtain the updated initial configuration environment. Return to execute the steps of testing the initial configuration environment using the target testing framework and test files. If the test passes, obtain the target configuration environment of the target code repository.

[0172] Configuration environment merging phase: Obtain the specified configuration file of the specified code repository; construct the specified configuration graph of the specified code repository based on the specified configuration file, and construct the target configuration graph of the target code repository based on the configuration file of the target code repository. The nodes of the specified configuration graph are the specified dependency packages in the specified configuration file, each carrying specified identifier information and specified version information. The nodes of the target configuration graph are the target dependency packages in the configuration file, each carrying target identifier information and target version information. If the specified identifier information and the target identifier information are different, it is determined that the specified configuration graph and the target configuration graph meet the graph merging conditions. If the specified identifier information and the target identifier information are the same, and the specified version information and the target version information overlap, it is determined that the specified configuration graph and the target configuration graph meet the graph merging conditions. If the specified configuration graph and the target configuration graph meet the graph merging conditions, environment configuration is performed based on the specified configuration file and the configuration file to obtain the updated target configuration environment. The updated target configuration environment is a shared configuration environment for both the target code repository and the specified code repository.

[0173] The automated configuration and testing solution for large-scale code repositories proposed in this disclosure solves the problems of time-consuming manual configuration and CI / CD workflow dependence on specific platforms, greatly saving manpower and time costs in the large-scale repository configuration and testing process. Furthermore, it enables repository configuration and testing to be completed locally by the user, without relying on a specific platform. By designing strategies such as code language version selection, automated configuration file parsing and execution, dynamic dependency correction mechanisms, and environment dependency merging, it effectively solves many challenges in large-scale project configuration and testing, laying an important foundation for automated software engineering and AI programmers, and achieving a more efficient, flexible, and centralized code project configuration and testing solution.

[0174] Corresponding to the above-described code repository configuration method embodiments, this disclosure also provides a code repository configuration device embodiment. Figure 6 shows a schematic diagram of the structure of a code repository configuration device provided in one embodiment of this disclosure. As shown in Figure 6, the device includes:

[0175] The first acquisition module 602 is configured to acquire the configuration files and test files of the target code repository.

[0176] Configuration module 604 is configured to configure the target code repository environment based on configuration files to obtain the initial configuration environment.

[0177] The first test module 606 is configured to use the target test framework and test files to test the initial configuration environment, and to determine the missing dependencies of the initial configuration environment if the test fails.

[0178] Install module 608, which is configured to install missing dependencies in the initial configuration environment to obtain the target configuration environment of the target code repository.

[0179] Optionally, the configuration module 604 is further configured to parse the configuration file, determine the code language version of the target code repository, and execute the configuration file based on the code language version to obtain the initial configuration environment of the target code repository.

[0180] Optionally, the configuration module 604 is further configured to perform keyword parsing on the configuration file to obtain language description information including code language keywords; and input the language description information into the version determination model to obtain the code language version of the target code repository.

[0181] Optionally, configuration module 604 is further configured to parse the configuration file, determine multiple configuration sub-files in the configuration file and the priority of the multiple configuration sub-files; and execute the multiple configuration sub-files according to the priority to obtain the initial configuration environment of the target code repository.

[0182] Optionally, the multiple configuration sub-files include a first configuration sub-file and a second configuration sub-file, with the first configuration sub-file having a higher priority than the second configuration sub-file; the configuration module 604 is further configured to determine the configuration command to be deleted from the second configuration sub-file, wherein the configuration command to be deleted is a configuration command commonly included in both the first and second configuration sub-files; delete the configuration command to be deleted from the second configuration sub-file to obtain a deleted second configuration sub-file; execute the first configuration sub-file and the deleted second configuration sub-file to obtain the initial configuration environment of the target code repository.

[0183] Optionally, the first test module 606 is further configured to, in the event that a test fails, obtain test error information; input the test error information into the information determination model to obtain the missing dependencies of the initial configuration environment and the installation commands for the missing dependencies; and in the initial configuration environment, install the missing dependencies based on the installation commands to obtain the target configuration environment of the target code repository.

[0184] Optionally, module 608 is further configured to install missing dependencies in the initial configuration environment to obtain an updated initial configuration environment; then return to the step of testing the initial configuration environment using the target testing framework and test files, and if the test passes, obtain the target configuration environment of the target code repository.

[0185] Optionally, the device further includes: a screening module configured to test the initial configuration environment using multiple candidate test frameworks and test files to obtain multiple test metrics, wherein the test metrics correspond one-to-one with the candidate test frameworks; and to screen the target test framework from the multiple candidate test frameworks based on the multiple test metrics.

[0186] Optionally, the device further includes: a fourth acquisition module, configured to acquire a specified configuration file of a specified code repository; construct a specified configuration graph of the specified code repository based on the specified configuration file, and construct a target configuration graph of the target code repository based on the configuration file of the target code repository; and, if the specified configuration graph and the target configuration graph meet the graph merging conditions, perform environment configuration based on the specified configuration file and the configuration file to obtain an updated target configuration environment, wherein the updated target configuration environment is a configuration environment shared by the target code repository and the specified code repository.

[0187] Optionally, the nodes of the specified configuration graph are specified dependency packages in the specified configuration file, and the specified dependency packages carry at least one of specified identification information and specified version information; the nodes of the target configuration graph are target dependency packages in the configuration file, and the target dependency packages carry at least one of target identification information and target version information; the device further includes: a determining module, configured to determine that the specified configuration graph and the target configuration graph meet the graph merging conditions when the specified identification information and the target identification information are different; and to determine that the specified configuration graph and the target configuration graph meet the graph merging conditions when the specified identification information and the target identification information are the same, and the specified version information and the target version information have an intersection.

[0188] The solution applied in this disclosure, through automated environment configuration and testing based on configuration files and test files, reduces errors and uncertainties caused by manual operations. This not only saves time but also ensures consistency in the configuration environment, mitigating problems caused by environmental differences. Furthermore, it overcomes the incompatibility issues of scripts across different platforms by not relying on scripts or tools provided by continuous integration / continuous deployment platforms. Moreover, by identifying and promptly installing missing dependencies in the initial configuration environment during testing, it reduces the time spent on manual debugging and error correction, improving the efficiency and reliability of code repository configuration. This ensures the integrity and correctness of the development and testing environments, avoids build failures or runtime errors due to dependency issues, and enhances the stability and efficiency of software development.

[0189] The above is an illustrative scheme of a code repository configuration device according to this embodiment. It should be noted that the technical solution of this code repository configuration device and the technical solution of the code repository configuration method described above belong to the same concept. For details not described in detail in the technical solution of the code repository configuration device, please refer to the description of the technical solution of the code repository configuration method described above.

[0190] Corresponding to the above-described code task processing method embodiments, this disclosure also provides a code task processing apparatus embodiment. Figure 7 shows a schematic diagram of the structure of a code task processing apparatus provided in one embodiment of this disclosure. As shown in Figure 7, the apparatus includes:

[0191] The second acquisition module 702 is configured to acquire task data of the target code task.

[0192] Processing module 704 is configured to process task data in a target configuration environment to obtain the task processing result of the target code task, wherein the target configuration environment is configured based on the code repository configuration method.

[0193] By applying the scheme of this disclosure embodiment, the target configuration environment is configured based on the code repository configuration method, ensuring that all dependencies and configurations in the target code repository are correctly installed and set, thereby creating a stable and reliable runtime environment. Then, processing task data in the target configuration environment avoids problems caused by environmental differences, ensuring that the target code tasks run consistently on different machines.

[0194] The above is an illustrative scheme of a code task processing device according to this embodiment. It should be noted that the technical solution of this code task processing device and the technical solution of the above-described code task processing method belong to the same concept. For details not described in detail in the technical solution of the code task processing device, please refer to the description of the technical solution of the above-described code task processing method.

[0195] Corresponding to the above-described code testing method embodiments, this disclosure also provides code testing device embodiments. Figure 8 shows a schematic diagram of the structure of a code testing device provided in one embodiment of this disclosure. As shown in Figure 8, the device includes:

[0196] The third acquisition module 802 is configured to acquire the source code files of the code test task.

[0197] The second test module 804 is configured to test the source code files in the target configuration environment and obtain the test results of the source code files. The target configuration environment is configured based on the code repository configuration method.

[0198] By applying the scheme of this disclosure embodiment, the target configuration environment is configured based on the code repository configuration method, ensuring that all dependencies and configurations in the target code repository are correctly installed and set, thereby creating a stable and reliable runtime environment. Then, testing the source code files in the target configuration environment avoids problems caused by environmental differences and ensures the accuracy of the test results for the source code files.

[0199] The above is an illustrative scheme of a code testing device according to this embodiment. It should be noted that the technical solution of this code testing device and the technical solution of the code testing method described above belong to the same concept. For details not described in detail in the technical solution of the code testing device, please refer to the description of the technical solution of the code testing method described above.

[0200] Figure 9 shows a structural block diagram of a computing device 900 provided in one embodiment of the present disclosure.

[0201] The computing device 900 includes:

[0202] Memory 910 and processor 920;

[0203] The memory 910 is used to store computer programs / instructions, and the processor 920 is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor 920, they implement the steps of the above-mentioned code repository configuration method, code task processing method, or code testing method.

[0204] In one or more embodiments of this disclosure, the computing device can be understood as an integrated smart terminal, including but not limited to a server, desktop computer, personal computer (PC), all-in-one model machine, mobile phone, tablet computer or other portable smart terminal, etc., and the computing device may have the model described in the above embodiments of this disclosure pre-installed.

[0205] Specifically, this computing device can pre-install various types of models, including but not limited to models in natural language processing, visual processing, speech processing, code processing, and multimodal task processing, thus providing diverse model selection. In different product forms, this computing device can support one or more model usage methods, including but not limited to model training, model invocation, model fine-tuning, model deployment, model inference, and application. In some product forms, this computing device also supports model management, including but not limited to multi-type model management (supporting the management of discriminative, generative, and other types of models), model version control (supporting the control of different model versions), and model evaluation (evaluating model performance and effectiveness based on model evaluation tools). In other product forms, this computing device can also create applications based on models, providing application programming interface (API) invocation capabilities. Models can be invoked into created applications through the API interface, and application management tools are provided for application management and monitoring.

[0206] Furthermore, the computing device may also include data management (supporting the creation and management of model tuning datasets), a training center (providing abundant training resources to help users learn and master artificial intelligence technologies), and basic control capabilities (providing enterprise-level basic control capabilities to ensure the security and efficient operation of the system). Through the above functions, it provides a comprehensive and integrated device for artificial intelligence development, training, deployment, and application.

[0207] Figure 10 shows a structural block diagram of an electronic device 1000 provided according to an embodiment of the present disclosure.

[0208] The memory 1010 and the processor 1020 are connected via a bus 1030;

[0209] The memory 1010 is used to store computer programs / instructions, and the processor 1020 is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor 1020, they implement the steps of the above-mentioned code repository configuration method, code task processing method, or code testing method.

[0210] Specifically, the components of the electronic device 1000 include, but are not limited to, a memory 1010 and a processor 1020. The processor 1020 and the memory 1010 can be connected via a bus 1030.

[0211] Electronic device 1000 may also include access device 1040, which enables electronic device 1000 to communicate with database 1050 storing data via one or more networks 1060. Examples of such networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. Access device 1040 may include one or more of any type of wired or wireless network interface (e.g., Network Interface Card (NIC)), such as IEEE 802.11 Wireless Local Area Networks (WLAN) wireless interface, Wi-MAX (World Interoperability for Microwave Access) interface, Ethernet interface, Universal Serial Bus (USB) interface, cellular network interface, Bluetooth interface, Near Field Communication (NFC) interface, and so on.

[0212] In one embodiment of this disclosure, the aforementioned components of the electronic device 1000, as well as other components not shown in FIG. 10, may also be connected to each other, for example, via a bus. It should be understood that the electronic device structural block diagram shown in FIG. 10 is merely for illustrative purposes and is not intended to limit the scope of this disclosure. Those skilled in the art can add or replace other components as needed.

[0213] Electronic device 1000 can be any type of stationary or mobile electronic device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable electronic devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary electronic devices such as desktop computers or PCs. Electronic device 1000 can also be a mobile or stationary electronic device.

[0214] The above is an illustrative scheme of an electronic device according to this embodiment. It should be noted that the technical solution of this electronic device belongs to the same concept as the technical solutions of the code repository configuration method, code task processing method, and code testing method described above. For details not described in detail in the technical solution of the electronic device, please refer to the description of the technical solutions of the code repository configuration method, code task processing method, or code testing method described above.

[0215] An embodiment of this disclosure also provides a computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the above-described code repository configuration method, code task processing method, or code testing method.

[0216] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solutions of the code repository configuration method, code task processing method, and code testing method described above. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solutions of the code repository configuration method, code task processing method, or code testing method described above.

[0217] An embodiment of this disclosure also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the above-described code repository configuration method, code task processing method, or code testing method.

[0218] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product belongs to the same concept as the technical solutions of the code repository configuration method, code task processing method, and code testing method described above. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solutions of the code repository configuration method, code task processing method, or code testing method described above.

[0219] The foregoing has described specific embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0220] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added or removed according to the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0221] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this disclosure are not limited to the described order of actions, because according to the embodiments of this disclosure, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this disclosure.

[0222] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0223] The preferred embodiments disclosed above are merely illustrative of this disclosure. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of this disclosure. These embodiments are selected and specifically described in this disclosure to better explain the principles and practical applications of the embodiments of this disclosure, thereby enabling those skilled in the art to better understand and utilize this disclosure. This disclosure is limited only by the claims and their full scope and equivalents.

Claims

A code repository configuration method includes: Obtain the configuration files and test files of the target code repository; Based on the configuration file, the target code repository is configured to obtain an initial configuration environment; Using the target testing framework and the test files, the initial configuration environment is tested. If the test fails, the missing dependencies of the initial configuration environment are determined. In the initial configuration environment, the missing dependencies are installed to obtain the target configuration environment for the target code repository. According to the method of claim 1, the step of configuring the target code repository based on the configuration file to obtain an initial configuration environment includes: The configuration file is parsed to determine the code language version of the target code repository; Based on the code language version, the configuration file is executed to obtain the initial configuration environment of the target code repository. According to the method of claim 2, the step of parsing the configuration file and determining the code language version of the target code repository includes: The configuration file is parsed to obtain language description information, including code language keywords; The language description information is input into the version determination model to obtain the code language version of the target code repository. According to any one of claims 1 to 3, the step of configuring the target code repository based on the configuration file to obtain an initial configuration environment includes: Parse the configuration file to determine the multiple configuration sub-files in the configuration file and the priority of the multiple configuration sub-files; Based on the stated priority, the plurality of configuration sub-files are executed to obtain the initial configuration environment of the target code repository. According to the method of claim 4, the plurality of configuration sub-files includes a first configuration sub-file and a second configuration sub-file, wherein the first configuration sub-file has a higher priority than the second configuration sub-file; The step of executing the plurality of configuration sub-files according to the priority to obtain the initial configuration environment of the target code repository includes: From the second configuration sub-file, the configuration commands to be deleted are determined, wherein the configuration commands to be deleted are configuration commands that are included in both the first configuration sub-file and the second configuration sub-file; Delete the configuration command to be deleted from the second configuration sub-file to obtain the deleted second configuration sub-file; Execute the first configuration sub-file and the deleted second configuration sub-file to obtain the initial configuration environment of the target code repository. The method according to any one of claims 1 to 5, wherein determining the missing dependencies of the initial configuration environment in the event that the test fails, includes: If the test fails, obtain the test error information; The test error information is used to determine the model, and the missing dependencies of the initial configuration environment and the installation commands for the missing dependencies are obtained. The process of installing the missing dependencies in the initial configuration environment to obtain the target configuration environment for the target code repository includes: In the initial configuration environment, the missing dependencies are installed based on the installation command to obtain the target configuration environment of the target code repository. The method according to any one of claims 1 to 5, wherein installing the missing dependency in the initial configuration environment to obtain the target configuration environment of the target code repository includes: In the initial configuration environment, install the missing dependencies to obtain an updated initial configuration environment; Return to the step of testing the initial configuration environment using the target testing framework and the test file, and if the test passes, obtain the target configuration environment of the target code repository. The method according to any one of claims 1 to 7, prior to testing the initial configuration environment using the target testing framework and the test file, further includes: The initial configuration environment is tested using multiple candidate test frameworks and the test files to obtain multiple test metrics, wherein each test metric corresponds one-to-one with a candidate test framework. The target test framework is selected from the multiple candidate test frameworks based on the multiple test metrics. According to the method of claim 8, the step of testing the initial configuration environment using multiple candidate testing frameworks and the test file to obtain multiple test metrics includes: For any of the candidate test frameworks, if an error occurs during the test, the missing dependencies in the test of the candidate test framework are identified and installed. Continue testing using the candidate testing framework and obtain the corresponding test metrics for the candidate testing framework. The method according to any one of claims 1 to 9, after installing the missing dependency in the initial configuration environment to obtain the target configuration environment of the target code repository, further includes: Retrieves a specified configuration file from a specified code repository; Based on the specified configuration file, construct the specified configuration graph of the specified code repository, and based on the configuration file of the target code repository, construct the target configuration graph of the target code repository; If the specified configuration graph and the target configuration graph meet the graph merging conditions, the environment is configured according to the specified configuration file and the configuration file to obtain the updated target configuration environment, wherein the updated target configuration environment is a configuration environment shared by the target code repository and the specified code repository. According to the method of claim 10, the node of the specified configuration graph is a specified dependency package in the specified configuration file, the specified dependency package carries at least one of specified identification information and specified version information, and the node of the target configuration graph is a target dependency package in the configuration file, the target dependency package carries at least one of target identification information and target version information; After constructing the specified configuration graph of the specified code repository based on the specified configuration file, and constructing the target configuration graph of the target code repository based on the configuration file of the target code repository, the method further includes: If the specified identification information and the target identification information are different, it is determined that the specified configuration map and the target configuration map satisfy the map merging condition; If the specified identification information and the target identification information are the same, and the specified version information and the target version information have an intersection, then the specified configuration map and the target configuration map are determined to meet the map merging condition. According to the method of claim 10 or 11, the step of constructing the specified configuration graph of the specified code repository based on the specified configuration file includes: The specified configuration graph is constructed using the specified dependency packages in the specified configuration file as nodes and the dependency relationships between the specified dependency packages as edges. The method according to any one of claims 10 to 12, wherein the step of configuring the environment according to the specified configuration file and the configuration file to obtain the updated target configuration environment includes: Merge the specified configuration file and the configuration file to obtain a merged configuration file; Merge the specified test files from the specified code repository and the test files from the target code repository to obtain the merged test files; Based on the merged configuration file, the environment is configured to obtain the initial merged configuration environment; Using the target testing framework and the merged test file, the initial merged configuration environment is tested. If the test fails, the missing merge dependencies of the initial merged configuration environment are determined. In the initial merge configuration environment, the missing merge dependencies are installed to obtain the updated target configuration environment. The method according to any one of claims 1 to 13, after obtaining the configuration file and test file of the target code repository, further includes: If the target code repository does not obtain the corresponding configuration file and / or test file, then the configuration and testing of the target code repository will be ignored. A code task processing method, comprising: Obtain task data for the target code task; In the target configuration environment, the task data is processed to obtain the task processing result of the target code task, wherein the target configuration environment is configured based on the method described in any one of claims 1 to 14. A code testing method, comprising: Obtain the source code files for the code testing task; In the target configuration environment, the source code file is tested to obtain the test results of the source code file, wherein the target configuration environment is configured based on the method described in any one of claims 1 to 14. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 16. An electronic device, comprising: A memory and a processor, the memory and the processor being connected via a bus; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 16. A computer-readable storage medium storing a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 16. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 16.

Images