Code warehouse detection method, device and equipment and computer readable storage medium

Abstract

The invention discloses a code warehouse detection method, device and equipment and a computer readable storage medium, and belongs to the technical field of computers. The method comprises the steps that multiple pieces of metadata of a code warehouse are obtained, the multiple pieces of metadata describe the running condition of the code warehouse through at least one detection dimension, and the detection dimensions are divided based on operation executed by the code warehouse in the process of providing a code hosting service; determining health parameters of the code warehouse in each detection dimension according to the multiple metadata, wherein the health parameters of the detection dimensions indicate execution performance of the code warehouse in executing operation corresponding to the detection dimensions; and obtaining a health detection result of the code warehouse based on the health parameters of the code warehouse in each detection dimension. The metadata of the code warehouse is automatically collected, the health degree of the code warehouse is automatically detected according to the collected metadata, the detection process of the code warehouse is simple, the operation difficulty is low, manual participation is not needed in the detection process, the labor cost is low, and the efficiency is high.

Description

[0001] This application claims priority to Chinese patent application No. 202311452067.4 filed on November 2, 2023, with invention name “Method, device, equipment and storage medium for determining the health of a code repository”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a code repository detection method, apparatus, device, and computer-readable storage medium. Background Art

[0003] In the field of computer technology, a code repository can be established to implement code hosting, where the code repository is used to store and manage code. Code hosting includes but is not limited to functions such as online code reading, code modification, code submission, and code merging. Code hosting can effectively solve problems such as cross-regional collaboration, multi-branch concurrency, code version management, or security for software developers. In the process of providing code hosting services, the performance of the code repository will decrease with incorrect usage. For example, an operation error when downloading code through the code repository will cause the download speed of the code repository to decrease, thereby affecting the user experience. Therefore, a code repository detection method is needed.

[0004] In the related technology, it is necessary to install an open source detection tool, use the installed detection tool to collect various size indicators of the code repository, mark the size indicators that may cause problems, provide the marked size indicators to professionals, and have the professionals perform manual analysis to obtain the detection results.

[0005] The above method requires a separate installation tool, the installation process is cumbersome and inefficient. In addition, it needs to be analyzed by professionals, which relies on manual labor and has high labor costs. Summary of the invention

[0006] The present application provides a code repository detection method, apparatus, device, and computer-readable storage medium to solve the problems existing in the related technologies. The technical solution is as follows:

[0007] In a first aspect, a code repository detection method is provided, the method comprising: obtaining multiple metadata of the code repository, the code repository is used to provide code hosting services for stored codes, the codes are stored based on project level or program level, the multiple metadata describe the operation of the code repository through at least one detection dimension, the detection dimension is divided based on operations performed by the code repository in the process of providing the code hosting service; determining health parameters of the code repository in each detection dimension according to the multiple metadata, the health parameters of the detection dimension are used to describe the execution performance of the code repository executing operations corresponding to the detection dimension; obtaining health detection results of the code repository based on the health parameters of the code repository in each detection dimension, the health detection results are used to describe the service performance of the code hosting service provided by the code repository.

[0008] This application automatically collects metadata of the code repository, and automatically detects the health of the code repository based on the collected metadata, thereby detecting the service performance of the code hosting service provided by the code repository. The detection process of the code repository is simple, the operation difficulty is low, the detection process does not require human participation, the labor cost is low, and the detection efficiency is high.

[0009] In a possible implementation, the metadata includes the actual value of the operating indicator, and the health parameters of the code warehouse in each detection dimension are determined based on multiple metadata, including: for multiple metadata of any detection dimension, obtain the reference value of the operating indicator corresponding to each metadata of any detection dimension, determine the indicator parameter of each operating indicator according to the difference between the actual value and the reference value of each operating indicator, and the indicator parameter indicates the health of the operating indicator; perform weighted summation on the multiple indicator parameters of any detection dimension to obtain the health parameter of the code warehouse in any detection dimension. For any detection dimension, by counting the health of multiple operating indicators of any detection dimension, the health of the detection dimension is determined based on the health of multiple operating indicators. The detection process is highly comprehensive and the health parameters obtained by the detection are highly reliable, thereby improving the accuracy of the health check results of the code warehouse.

[0010] In a possible implementation, the health detection result includes at least one of the health parameters of the code repository in each detection dimension or the health level of the code repository in each detection dimension, and the health level is determined based on the health parameter. The health detection result can be a health parameter or a health level, which is highly flexible and widely used.

[0011] In a possible implementation, after obtaining the health detection result of the code warehouse based on the health parameters of the code warehouse in each detection dimension, the method further includes: obtaining a graphical visualization result of the health detection result, the graphical visualization result including a display mark of the health detection result of the code warehouse in each detection dimension; and displaying the graphical visualization result. The graphical visualization result can be used to intuitively display the health detection result, which is convenient for users to use and understand.

[0012] In a possible implementation, the graphical visualization result also includes display information of metadata of each detection dimension. On the basis of displaying the health detection result, detailed metadata display information is also displayed to provide a detailed understanding of the health status of the detection dimension, and the displayed information is more comprehensive.

[0013] In a possible implementation, displaying the graphical visualization result includes: for detection dimensions of different health levels, using different display features to display display identifiers of the detection dimensions of different health levels. By displaying the display identifiers of the detection dimensions of different health levels with different display features, different health levels can be distinguished, and the graphical display process is more intuitive and clear.

[0014] In a possible implementation, after obtaining the health test results of the code warehouse based on the health parameters of the code warehouse in each test dimension, the following further includes: determining the operating indicators of the code warehouse to be repaired according to the health test results of the code warehouse; generating alarm information of the operating indicators to be repaired, and displaying the alarm information, the alarm information is used to prompt the repair of the operating indicators to be repaired. For the operating indicators to be repaired, timely reminders will be given through alarm information to shorten the interval between discovering the operating indicators and repairing the operating indicators, and the repair of the operating indicators is highly timely.

[0015] In a possible implementation, after determining the operating indicators of the code repository to be repaired according to the health detection results of the code repository, the method further includes: determining the repair strategy corresponding to the operating indicator to be repaired according to the correspondence between the operating indicator and the repair strategy; and displaying the repair strategy corresponding to the operating indicator to be repaired. For the operating indicator to be repaired, a repair strategy is also provided to assist in repairing the operating indicator, thereby improving the repair efficiency of the operating indicator.

[0016] In a possible implementation, at least one detection dimension includes at least one of a warehouse object dimension, a warehouse file dimension, a warehouse engineering capability dimension, a warehouse large file storage LFS dimension, or a warehouse merge request MR dimension. This method does not limit the detection dimension, and can perform health detection on the code repository through one or more detection dimensions, which is highly flexible and widely applicable.

[0017] In a second aspect, a detection device for a code repository is provided, the device comprising: an acquisition module, used to acquire multiple metadata of the code repository, the code repository is used to provide code hosting services for the stored codes, the codes are stored based on the project level or the program level, the multiple metadata describe the operation status of the code repository through at least one detection dimension, the detection dimension is divided based on the operations performed by the code repository in the process of providing the code hosting service; a determination module, used to determine the health parameters of the code repository in each detection dimension according to the multiple metadata, the health parameters of the detection dimension are used to describe the execution performance of the code repository executing the operations corresponding to the detection dimension; the determination module is also used to obtain the health detection result of the code repository based on the health parameters of the code repository in each detection dimension, the health detection result is used to describe the service performance of the code hosting service provided by the code repository.

[0018] In one possible implementation, the metadata includes the actual value of the operating indicator, and a determination module is used to obtain the reference value of the operating indicator corresponding to each metadata of any detection dimension for multiple metadata of any detection dimension, and determine the indicator parameter of each operating indicator according to the difference between the actual value and the reference value of each operating indicator, where the indicator parameter indicates the health of the operating indicator; and perform weighted summation on multiple indicator parameters of any detection dimension to obtain the health parameter of the code repository in any detection dimension.

[0019] In a possible implementation, the health detection result includes at least one of a health parameter of the code repository in each detection dimension or a health level of the code repository in each detection dimension, and the health level is determined based on the health parameter.

[0020] In a possible implementation, the acquisition module is also used to obtain graphical visualization results of the health detection results, and the graphical visualization results include display identifiers of the health detection results of the code repository in each detection dimension; the device also includes: a first display module, which is used to display the graphical visualization results.

[0021] In a possible implementation, the graphic visualization result also includes display information of metadata of each detection dimension.

[0022] In a possible implementation, the first display module is used to display display identifiers of detection dimensions of different health levels using different display features.

[0023] In one possible implementation, the determination module is also used to determine the operating indicators to be repaired of the code warehouse based on the health check results of the code warehouse; the device also includes: a second display module, used to generate alarm information of the operating indicators to be repaired, and display the alarm information, wherein the alarm information is used to prompt the repair of the operating indicators to be repaired.

[0024] In a possible implementation, the determination module is further used to determine the repair strategy corresponding to the operating indicator to be repaired according to the correspondence between the operating indicator and the repair strategy; the second display module is further used to display the repair strategy corresponding to the operating indicator to be repaired.

[0025] In a possible implementation, at least one detection dimension includes at least one of a warehouse object dimension, a warehouse file dimension, a warehouse engineering capability dimension, a warehouse large file storage LFS dimension, or a warehouse merge request MR dimension.

[0026] In a third aspect, a computing device cluster is provided, which includes at least one computing device, each computing device including a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster executes any one of the code repository detection methods of the first aspect above.

[0027] In a fourth aspect, a computer-readable storage medium is provided, the computer-readable storage medium comprising computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes any one of the code repository detection methods of the first aspect.

[0028] In a fifth aspect, a computer program (product) comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes any one of the code repository detection methods of the first aspect.

[0029] In a sixth aspect, a communication device is provided, the device comprising: a transceiver, a memory, and a processor. The transceiver, the memory, and the processor communicate with each other through an internal connection path, the memory is used to store instructions, the processor is used to execute the instructions stored in the memory to control the transceiver to receive signals and control the transceiver to send signals, and when the processor executes the instructions stored in the memory, the processor executes the method in the first aspect or any possible implementation of the first aspect.

[0030] Optionally, there are one or more processors and one or more memories.

[0031] Optionally, the memory may be integrated with the processor, or the memory may be provided separately from the processor.

[0032] In the specific implementation process, the memory can be a non-transitory memory, such as a read-only memory (ROM), which can be integrated with the processor on the same chip or can be set on different chips. This application does not limit the type of memory and the setting method of the memory and the processor.

[0033] In a seventh aspect, a chip is provided, comprising a processor for calling and executing instructions stored in a memory from the memory, so that a communication device equipped with the chip executes the methods in the above aspects.

[0034] In an eighth aspect, another chip is provided, comprising: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the methods in the above aspects.

[0035] It should be understood that the beneficial effects achieved by the technical solutions of the second to eighth aspects of the present application and the corresponding possible implementation methods can be referred to the above-mentioned technical effects of the first aspect and its corresponding possible implementation methods, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 A schematic diagram of an implementation environment provided for an embodiment of the present application;

[0037] Figure 2 A schematic diagram of another implementation environment provided for an embodiment of the present application;

[0038] Figure 3 A schematic diagram of another implementation environment provided for an embodiment of the present application;

[0039] Figure 4 A flowchart of a code repository detection method provided in an embodiment of the present application;

[0040] Figure 5 A schematic diagram of a graphical visualization result provided in an embodiment of the present application;

[0041] Figure 6 A schematic diagram of another graphical visualization result provided in an embodiment of the present application;

[0042] Figure 7 A schematic diagram of a process for detecting a code repository provided in an embodiment of the present application;

[0043] Figure 8 A schematic diagram of the structure of a code repository detection device provided in an embodiment of the present application;

[0044] Fig. 9 A schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0045] Fig.10 A connection diagram of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The terms used in the implementation method of this application are only used to explain the specific embodiments of this application, and are not intended to limit this application. In order to make the purpose, technical solution and advantages of this application clearer, the implementation method of this application will be further described in detail below with reference to the accompanying drawings.

[0047] In the field of computer technology, code repositories can be used to store code, which can be public or private. Users can operate code repositories to read, modify, and submit code stored in the code repositories online. The above operations can also be called code hosting services in some cases. In the process of using code repositories, health checks can also be performed on the code repositories to avoid using unhealthy code repositories that reduce the user experience. Among them, health checks refer to detecting the performance indicators of the code repositories to obtain the health status of the code repositories. Performance indicators include, but are not limited to, the download rate or merge time of the code repositories.

[0048] In the related art, the user downloads the open source source code, compiles and generates a detection tool based on the downloaded open source source code, and installs the detection tool into the distributed version control system (Git) platform where the code repository is located. After that, the user downloads the code repository to be detected, runs the detection tool to collect size indicators in the code repository, and the size indicators are used to indicate the size of the code stored in the code repository or the storage space size of the code repository. Based on the detection tool, the problematic size indicators in the collected size indicators are marked, and the marked size indicators are fed back to professionals, who analyze and give an evaluation conclusion. The above-mentioned process of installing the detection tool is cumbersome. If the user has a low subjective awareness of warehouse governance, the code repository detected by the user's active use of the detection tool will be in poor timeliness.

[0049] This application embodiment provides a code repository detection method, please refer to Figure 1 , which shows a schematic diagram of the implementation environment of the code warehouse detection method provided in the embodiment of the present application, and the implementation environment includes a detection device 01. A communication connection is established between the detection device 01 and the code warehouse configured in the cloud. The detection device 01 can obtain metadata for describing the operation of the code warehouse based on the communication connection, determine the health parameters of the code warehouse in various detection dimensions according to the metadata, and then obtain the health detection result of the code warehouse according to the health parameters.

[0050] Optionally, Figure 2 A schematic diagram of an implementation environment of another code repository detection method provided in an embodiment of the present application, Figure 2The detection device includes a project server and a portal module. The project server is the back-end application layer processing service of the detection device, and the portal is a module used by the detection device to provide website (wb) front-end services. Figure 2 It also includes a collector and a database (DB). The collector provides data collection and reporting services, obtains metadata collected by each underlying module on the code repository, and caches it in the database (DB). The underlying modules include but are not limited to Figure 2 At least one of the large file storage server (LFS server), Git server or Git proxy. LFS server provides Git LFS related processing services. The collected metadata can be metadata of the warehouse LFS dimension. The metadata of the warehouse LFS dimension is used to describe storage space, total number of files or file size, etc. Git server provides Git underlying logic processing services. The collected metadata can be metadata of the warehouse file dimension and warehouse object dimension. The metadata of the warehouse file dimension is used to describe the number of code lines, and the metadata of the warehouse object dimension is used to describe the number of branches or loose objects, etc. Git proxy provides upload and download services. The collected metadata can be metadata of the warehouse engineering capability dimension, including but not limited to metadata used to describe the read-write ratio, current limiting status, etc.

[0051] Exemplarily, after the collector collects the metadata of the code repository, it stores the metadata in the DB. The project server obtains the metadata stored in the DB, and detects the code repository based on the received metadata to obtain the health detection result of the code repository. The project server sends the health detection result to the protal, and displays the health detection result through the protal so that the user can intuitively view the health status of the code repository. The collector and the DB can be integrated into the detection device or other network devices independent of the detection device, which is not limited in the embodiments of the present application.

[0052] In one possible scenario, the above method can be Figure 1 As shown, it is performed by a detection device 01, or it can be performed as shown Figure 3 The process shown is performed by multiple detection devices 01. Figure 3The computing device cluster 01 includes multiple detection devices 01 for providing cloud services, and the multiple detection devices 01 can communicate with each other through a wired or wireless network. Optionally, the above code repository detection method can be interactively executed by multiple detection devices 01 included in the computing device cluster 10. The embodiment of the present application does not limit the number of detection devices 01 included in the computing device cluster 10. Figure 3 Only two detection devices 01 are taken as examples for illustration.

[0053] For example, Figure 1 or Figure 3 The detection device 01 in the embodiment may be a server, such as a central server, an edge server, or a local server in a local data center. The server may be a physical server or a cloud server providing cloud computing services. In some embodiments, Figure 1 or Figure 3 The detection device 01 in the example may also be a terminal device such as a desktop computer, a laptop computer or a smart phone involved in the cloud service.

[0054] The present application embodiment provides a code repository detection method, which can be applied to the above Figure 1-Figure 3 In the implementation environment shown in FIG. 1 , the method can be executed by a detection device. The flowchart of the method is as follows: Figure 4 As shown, including S401-S403.

[0055] S401, obtaining multiple metadata of a code repository, where the code repository is used to provide code hosting services for stored codes, where the codes are stored at a project level or a program level, and the multiple metadata describe the operation of the code repository through at least one detection dimension, where the detection dimension is divided based on operations performed by the code repository in the process of providing the code hosting service.

[0056] Exemplarily, a code warehouse refers to a warehouse for storing and managing codes. In the process of storing codes, the code warehouse stores them at the project level or program level. For example, multiple codes included in different projects are stored in different storage spaces. In the process of storing codes, the code warehouse can also provide code hosting services, which include but are not limited to functions such as online reading codes, modifying codes, submitting codes or merging codes. In one possible case, the code warehouse involved in the code hosting service includes a local warehouse and a remote warehouse. Among them, the local warehouse refers to a code warehouse stored on a local computer, and the remote warehouse refers to a code warehouse stored on a remote server, which is used for multi-person collaborative development and backup code. The process of performing code hosting services through local warehouses and remote warehouses is, for example, that object A and object B jointly develop a software, and object A and object B respectively create local warehouses locally, which are used to store the codes compiled by object A and object B locally, and then object A and object B push the codes stored in the local warehouse to the remote warehouse. Through the remote warehouse, object A can view the code compiled by object B, and object B can also view the code compiled by object A, and the remote warehouse can also merge the code compiled by object A and the code compiled by object B to obtain a complete code for developing software. In this case, the code repository to be tested can be a local repository or a remote repository.

[0057] The embodiments of the present application do not limit the triggering method for detecting the code warehouse. The detection device can detect the code warehouse based on a detection period, and the detection period can be any duration set based on experience or application scenarios. Alternatively, the detection device can detect the code warehouse when the code warehouse starts running. For example, object A starts to modify the code stored in the code warehouse, and the detection device starts to detect the code warehouse modified by object A after detecting the code modification in the code warehouse. During the operation of the code warehouse, the code warehouse is detected to achieve long-term tracking of the usage of the code warehouse, so that when there is a problem in the usage of the object, resulting in a decrease in the performance of the code warehouse, it can be promptly determined and corrected.

[0058] Optionally, the detection device can also start detecting the code warehouse based on the detection instruction, and the detection instruction can be obtained by inputting through the information input control. Continuing with the example of using the code warehouse by the user object, the user object needs to detect the code warehouse before using the code warehouse to determine the health of the code warehouse, and avoid using a code warehouse with low health and prone to errors to modify the code, resulting in the modified code cannot be synchronized to other objects in time, causing waste of compilation work. The user object inputs a code detection instruction into the information input control provided to the detection device based on the detection requirements. The code detection instruction includes the identification of the code warehouse to be detected, and the detection device thereby determines the code warehouse to be detected. The identification of the code warehouse can be the identity document (ID) of the code warehouse or the login account of the object using the code warehouse, etc.

[0059] Regardless of the method by which the detection device determines the code warehouse to be detected, multiple metadata of the code warehouse can be obtained based on the detection requirements of the code warehouse, and the multiple metadata describe the operation of the code warehouse through at least one detection dimension. Among them, the detection requirement refers to the health detection of the code warehouse to be performed, and the detection dimension can be divided according to the operations performed by the code warehouse in the process of providing code hosting services. Taking the operations performed by the code warehouse as an example, including Git service, LFS service and upload and download service, Git service is used to manage and maintain the code warehouse, and LFS service refers to large file storage technology. Since non-text files may be stored in the code warehouse, non-text files are, for example, multimedia files, software product files or binary files. These non-text files are large in size, and using Git service to directly manage them will cause the volume of the warehouse to expand rapidly, which will slow down many operations involved in Git service, and also affect the upload of files in the local warehouse to the files in the remote warehouse. Therefore, non-text files can be stored through LFS service, and pointers to non-text files are used instead of actual non-text files, and the actual non-text files are stored in the remote LFS server, while the changes of non-text files in the remote LFS server are tracked in real time in the code warehouse. The upload and download service is used to upload and download the code stored in the code repository.

[0060] For the Git service, the detection dimension can be determined as the warehouse file dimension and the warehouse object dimension used to describe the underlying logical processing of the Git service. For the LFS service, the detection dimension can be determined as the warehouse LFS dimension. For the warehouse upload and download service, the detection dimension can be determined as the warehouse engineering capability dimension. The warehouse engineering capability dimension is used to describe the operating quality of the services provided by the code warehouse. The operating quality is, for example, the download speed of the warehouse upload and download service. Optionally, since the code warehouse will also merge the codes of different warehouses, the detection dimension of the code warehouse can also be the warehouse merge requests (merge requests, MR) dimension. The above examples are intended to explain the correspondence between the services provided by the code warehouse and the detection dimensions, rather than to limit the services that the code warehouse can provide. When the code warehouse adopts other services with different processes but similar functions, detection can also be based on the same detection dimension.

[0061] Exemplarily, after acquiring multiple detection dimensions that support detection, the detection device can randomly select at least one detection dimension from the multiple detection dimensions to perform detection of the code warehouse. For example, the warehouse object dimension and the warehouse file dimension are randomly selected to comprehensively detect the Git service provided by the code warehouse. The detection device can also select the detection dimension based on the service currently running in the code warehouse. For example, if the code warehouse is currently executing the upload and download service, the detection dimension is determined to be the warehouse engineering capability dimension. Optionally, the detection device can also select the detection dimension based on the interaction with the user object. For example, the detection device displays a selection control of multiple detection dimensions, and the user object triggers the detection dimension to be detected based on the demand. For example, the user object triggers the selection controls of the warehouse file dimension, the warehouse object dimension, the warehouse LFS dimension, the warehouse engineering capability dimension, and the warehouse MR dimension in turn. The detection device thus determines to detect the code warehouse from five detection dimensions: the warehouse file dimension, the warehouse object dimension, the warehouse LFS dimension, the warehouse engineering capability dimension, and the warehouse MR dimension.

[0062] After determining the detection dimension of the code repository, the detection device can collect metadata for each detection dimension. The metadata is used to describe the operation of the code repository in the detection dimension. A metadata can be understood as the actual value of an operation indicator. For example, the detection dimension is the warehouse file dimension. Figure 2, the metadata of the warehouse file dimension collected by the Git server is used to describe the number of lines of code. The metadata of the warehouse file dimension includes the lines of code used to describe the number of lines of code, and may also include at least one of the single warehouse storage size, the binary file size ratio, the number of modifications of super large text files, or the number of super large files. The single warehouse storage size is used to describe the storage space, the binary file size ratio is used to describe the file size, and the number of super large files is used to describe the file size. Among them, a single warehouse refers to a single warehouse, which means that multiple files are placed in the same warehouse, a super large text file refers to a text file larger than a first threshold, and a super large file refers to a file larger than a second threshold. The first threshold and the second threshold can be set based on experience and implementation environment, and the first threshold and the second threshold can be the same or different. For example, the first threshold is 20 megabytes (megabit, MB), and the second threshold is 50MB. In this case, the detection device can count the number of modifications of each text file larger than 20MB to obtain the number of modifications of super large text files, and count the number of files larger than 50MB to obtain the number of super large files.

[0063] Take the detection dimension as the warehouse object dimension as an example, see Figure 2 , the metadata of the repository object dimension collected by the Git server can be used to describe at least one of the number of branches or loose objects, and the metadata includes but is not limited to the number of Git objects, the number of code branches used to describe the number of branches, or the number of loose objects used to describe loose objects. Optionally, the metadata may also include the number of tags, the proportion of repeated commit tags, etc. Among them, a code branch refers to a code separated from the main line for additional operations. Tag is a mark of the Git version, which is used to identify different release versions. Commit tag is used to identify a change to the code, repeated commit tag refers to repeated changes to a code, and loose objects refer to objects that are not in the package file.

[0064] Take the warehouse LFS dimension as an example, see Figure 2 , the metadata of the warehouse LFS dimension collected by the LFS server is used to describe the storage space, the total number of files or the file size, etc. The metadata includes at least one of the total size of the LFS single warehouse used to describe the storage space, the percentage of small files used to describe the total number of files, the total number of LFS files, or the maximum single file size used to describe the file size. Among them, small files refer to files smaller than the third threshold value, and the third threshold value can be set based on experience and implementation scenarios. The third threshold value is, for example, 10MB, then the percentage of small files refers to the ratio of the number of files smaller than 10MB to the total number of files in the code warehouse, the largest single file refers to the file with the largest volume among at least one file stored by the LFS service, and the LFS file refers to a file stored by the LFS service.

[0065] Take the inspection dimension as the warehouse engineering capability dimension as an example, see Figure 2 The metadata of the repository engineering capability dimension collected by Git proxy is used to describe at least one of the read-write ratio or the current limiting status. The metadata includes at least one of the full download ratio, the WebHook delivery error ratio, or the application programming interface (API) call current limiting number used to describe the current limiting status. Among them, full download refers to all downloads. Corresponding to full downloads, code repositories can also be downloaded in batches. WebHook delivery means that the front end does not send a request for acquisition, and the back end actively delivers it. API call current limiting refers to limiting the number of API calls within a certain period of time to ensure the availability and stability of the code repository.

[0066] Taking the warehouse MR dimension as an example, metadata is used to describe the MRs processed by the code repository. Metadata includes but is not limited to the proportion of super-large MRs or the number of zombie MRs. Among them, super-large MRs refer to MRs with more than 5,000 changes or more than 50 submissions. Super-large MRs can also be MRs that exceed other lines or other times. Zombie MRs refer to MRs that have not been updated for a long time. The long time can be set based on experience. For example, it is set to 1 month. MRs that have been in the open state for more than 1 month without updates are zombie MRs.

[0067] In a possible implementation, the detection device can collect metadata of the code repository through a server, and continue to Figure 2 Taking the connection relationship between the detection device and the code repository shown in the figure as an example, the collector periodically sends collection tasks to three servers, namely Gitserver, LFS server and Git proxy. The Git server collects metadata of the warehouse object dimension and warehouse file dimension of the code repository, the LFS server collects metadata of the warehouse LFS dimension of the code repository, and the Git proxy collects metadata of the warehouse project dimension of the code repository. After the collector receives the metadata collected by the Git server, LFSserver and Git proxy, it stores the collected metadata in the database. The detection device can obtain the metadata stored in the database by accessing the database. For the metadata of the warehouse MR dimension, the detection device can directly count the MRs in the database to obtain the proportion of super large MRs and the number of zombie MRs. For example, the detection device can use Figure 2 The projectserver in reads the metadata of the warehouse MR dimension from the database.

[0068] S402, determining health parameters of the code repository in each detection dimension according to the plurality of metadata, where the health parameters of the detection dimension are used to describe the execution performance of the code repository in executing operations corresponding to the detection dimension.

[0069] Since the process of determining the health parameters of the code warehouse in different detection dimensions is similar, the process of determining the health parameters of the code warehouse is described below by taking any detection dimension as an example. For example, referring to the metadata shown in S401, the metadata indicates the actual value of the operating indicator. Therefore, for multiple metadata of any detection dimension, the detection device can obtain the reference value of the operating indicator corresponding to each metadata, and determine the indicator parameter of each operating indicator according to the difference between the actual value and the reference value of each operating indicator. The indicator parameter indicates the health of the operating indicator; the weighted sum of multiple indicator parameters of any detection dimension is performed to obtain the health parameter of the code warehouse in any detection dimension.

[0070] Among them, the reference value corresponding to the metadata refers to the ideal numerical value of the operating indicator corresponding to the metadata. The reference value can be set based on experience and implementation environment. Table 1 is a correspondence table between metadata and reference values ​​provided in an embodiment of the present application, see Table 1.

[0071] Table 1

[0072]

[0073]

[0074] In Table 1, the reference value is used to indicate the ideal range of the operation index corresponding to the metadata. Taking the single-warehouse storage size in Table 1 as an example, when the single-warehouse storage size is less than 1 gigabyte (GB), for example, the single-warehouse storage size is 0.9GB, the single-warehouse storage size belongs to the ideal range. When the single-warehouse storage size is not less than 1GB, for example, the single-warehouse storage size is 1.1GB, the single-warehouse storage size does not belong to the ideal range. In a possible case, the reference value can also indicate the operation threshold of the operation index corresponding to the metadata, and the operation threshold is used to limit the ideal range. Continuing to take the single-warehouse storage size in Table 1 as an example, the reference value is 1GB. In this case, when the single-warehouse storage size is greater than 1GB, the single-warehouse storage size does not belong to the ideal range, and when the single-warehouse storage size is not greater than 1GB, the single-warehouse storage size belongs to the ideal range. Optionally, each metadata may have a corresponding reference value, or may partially have a corresponding reference value. For example, in Table 1, the value of the code line has a low correlation with the health of the code file, so the code line is not set with a corresponding reference value. When the health detection of the code file dimension is performed based on the metadata later, the code line is not combined for detection.

[0075] Exemplarily, the detection device can determine the index parameter of the metadata that belongs to the ideal range as the initial parameter, and the initial parameter can be any value set based on experience and implementation environment, such as 0 or 10 or 100. Alternatively, the detection device can also determine the index parameter of the metadata in the ideal range based on the difference between the actual value and the reference value in combination with the initial parameter. Continuing with the example of the single warehouse storage size of 0.9GB in the above embodiment, it is reduced by (1-0.9) / 1=10% compared to the reference value, then 1 point is added to the initial parameter, and the index parameter is equal to 11.

[0076] When the actual value of the operating index does not fall within the ideal range, the detection equipment can determine the index parameter based on the difference between the actual value and the reference value in combination with the initial parameters. Taking the single warehouse storage size of 1.1GB, the calculation method of the index parameter is the calculation method shown in Table 1 as an example, (1.1-1) / 1=0.1, the single warehouse storage size exceeds the reference value by 0.1, that is, 10%, and 1 point can be subtracted from the initial parameter, and the obtained index parameter is, for example, 10-1=9 points. For the process of determining the index parameters from other metadata, please refer to the calculation method shown in Table 1, and the detailed process will not be repeated one by one. Among them, the index parameter can be in the form of a score in the above embodiment, or it can be in the form of a grade or other parameter form that can describe the health of the operating indicator.

[0077] After determining the indicator parameters corresponding to each metadata, the detection device can perform weighted summation on multiple indicator parameters of the same detection dimension. Among them, the indicator weights corresponding to each metadata can also be determined based on experience and implementation environment. Table 1 also shows the indicator weights corresponding to each metadata set based on experience. The sum of multiple indicator weights included in any detection dimension in Table 1 is equal to 1. It should be understood that Table 1 is intended to give an example of the indicator weights corresponding to metadata, rather than to limit the indicator weights corresponding to metadata. The indicator weights corresponding to each metadata can be dynamically adjusted according to the actual operating environment of the code repository.

[0078] For example, the process of obtaining the health parameter by weighted summation of the indicator parameter and the indicator weight can be seen in Formula 1.

[0079]

[0080] Among them, total_score refers to the health parameters of the code repository under this detection dimension, i is the metadata identifier, which is used to distinguish different metadata in this detection dimension, n is a positive integer, indicating the total number of metadata under this detection dimension, and metric_score i The metric parameter corresponding to the metadata, metric_weight iis the indicator weight corresponding to the metadata. In formula 1, the indicator parameters corresponding to each metadata and the indicator weight corresponding to the metadata are multiplied to obtain multiple products, and the multiple products are added to obtain the weighted summation calculation result. For the calculation result of the weighted summation, the detection equipment can retain two decimal places as the health parameter, or retain other digits as the health parameter. Formula 1 is an example of weighted summation. The present application can use Formula 1, or other more weighted summation methods to calculate the health parameters.

[0081] Taking the warehouse file dimension as an example, the code line is 100, the single warehouse storage size is 1.1GB, the binary file size accounts for 20%, the number of super large text file modifications is 49, the number of super large files is 10, and the total number of files and subfolders under the super large directory is 255. Based on the calculation method of the indicator parameters in Table 1, the indicator parameters corresponding to each metadata are respectively the indicator parameter 0 corresponding to the code line, the indicator parameter 9 corresponding to the single warehouse storage size, the indicator parameter 10-1 (20%-10%) / 5%=8 corresponding to the binary file size ratio, the indicator parameter 10 corresponding to the number of super large text file modifications, the indicator parameter 10-10 / 20×1=9.5 corresponding to the number of super large files, and the indicator parameter 10 corresponding to the total number of files and subfolders under the super large directory. The health parameter obtained by weighted summation of multiple indicator parameters is 0×0+9×0.2+8×0.2+10×0.2+9.5×0.2+10×0.2=9.3. Through multiple metadata, the health of the code repository in the detection dimension is detected from different operating indicators. The detection process is more comprehensive and the calculated health parameters are more accurate. The health of the code repository in the detection dimension is reflected by the health parameter. When the health level indicated by the health parameter is higher, the performance of the corresponding operation executed by the code repository is better, and the probability of abnormality of the executed operation is smaller.

[0082] S403, obtaining a health detection result of the code repository based on the health parameters of the code repository in each detection dimension, where the health detection result is used to describe the service performance of the code hosting service provided by the code repository.

[0083] In a possible implementation, the detection device can directly use the health parameters of the code warehouse in each detection dimension as the detection result of the code warehouse. The health parameters can also be processed to obtain the health detection result. For example, since the health parameters are an abstract representation of the health status of the code warehouse, the detection device can determine the health level of the code warehouse in each detection dimension based on the health parameters of the code warehouse in each detection dimension, and obtain a health detection result including the health level of at least one detection dimension.

[0084] Among them, the health level can be divided into at least two levels of different health levels. Taking the division into four levels as an example, the four levels with different health levels include healthy, sub-healthy, unhealthy and extremely unhealthy. The above health levels are arranged from high to low according to the health level, that is, healthy is better than sub-healthy, sub-healthy is better than unhealthy, and unhealthy is better than extremely unhealthy. The health of the code warehouse can be understood as the pros and cons of the running performance of the code warehouse or the probability of abnormal operation of the code warehouse. The higher the health of the code warehouse, the smaller the probability of abnormal operation of the code warehouse, and the lower the health of the code warehouse, the greater the probability of abnormal operation of the code warehouse. For example, the probability of abnormal operation of a healthy code warehouse is less than the probability of abnormal operation of an unhealthy code warehouse.

[0085] Exemplarily, the detection device obtains the parameter range of each level, and determines the health level of the code warehouse in each detection dimension according to the parameter range of each level and the health parameters of the code warehouse in each detection dimension. Optionally, the parameter range of each level can be set based on experience and implementation environment. Continuing with the initial parameter of 10 in the above embodiment, since the health level is divided into four levels, 0 to 2.5 can be determined as an extremely unhealthy parameter range based on 10 ÷ 4 = 2.5, 2.5 to 5 can be determined as an unhealthy parameter range, 5 to 7.5 can be determined as a sub-healthy parameter range, and 7.5 to 10 can be determined as a healthy parameter range. In addition, the size of the parameter range of different levels may also be different, for example, 0 to 3 is an extremely unhealthy parameter range, 3 to 5 is an unhealthy parameter range, 5 to 8 is a sub-healthy parameter range, and 8 to 10 is a healthy parameter range.

[0086] After obtaining the parameter ranges of each level, the detection device can compare the health parameters of the code warehouse with the parameter ranges of each level to obtain the health level of the code warehouse in the detection dimension. Continuing with the example of the health parameter of the code warehouse in the warehouse file dimension being 9.5 as shown in S402, the health parameter is between 8 and 10, so the health level of the code warehouse in the warehouse file dimension is healthy.

[0087] For boundary values ​​of different levels, such as 2.5, 5, and 7.5 in the above embodiment, when the health parameter of the code warehouse in any detection dimension is equal to the boundary value, the health level of the detection dimension can be determined as any one of the two levels corresponding to the boundary value. Taking 2.5 as an example, the two levels corresponding to the boundary value are extremely unhealthy and unhealthy, and the detection device can randomly select unhealthy as the health level of the code warehouse in this detection dimension. Optionally, the detection device can also determine the division rules of the boundary values. For example, when the health parameter of the code warehouse in any detection dimension is equal to the boundary value, a high health level is determined as the health level of the code warehouse in any detection dimension, or a low health level is determined as the health level of the code warehouse in any detection dimension.

[0088] Optionally, the detection device can choose to use at least one of the health parameters or health levels of the code warehouse in each detection dimension as the health detection result, or determine the overall health parameters of the code warehouse based on the health parameters of the code warehouse in each detection dimension. When there are multiple detection dimensions, the detection device can perform a weighted sum of the health parameters of multiple detection dimensions to obtain an overall health parameter, and use the overall health parameter as the health detection result. Similar to the principle of determining the health level based on the health parameters of any detection dimension, the detection device can also determine the overall health level of the code warehouse based on the overall health parameters after obtaining the overall health parameters, and obtain a health detection result including at least one of the overall health parameters or the overall health level.

[0089] In one possible case, after obtaining the health detection result of the code repository, the detection device will also display the health detection result to the user. Optionally, the detection device can feed back each health detection result to the user, and can also feed back the health detection result to the user when the health detection result indicates that the code repository is abnormal, such as when the health level of a detection dimension is equal to or lower than unhealthy.

[0090] In one possible implementation, the process of displaying the health detection results by the detection device includes but is not limited to: obtaining a graphical visualization result of the health detection result, the graphical visualization result including a display mark of the health detection result of the code warehouse in each detection dimension; and displaying the graphical visualization result. Among them, the health detection result of the code warehouse in the detection dimension refers to at least one of the health parameters or health levels of the code warehouse in the detection dimension, and the display mark of the health detection result can be a display number of the health parameter or a display text of the health level. The graphical visualization result refers to the relationship between entities presented through graphics. The graphics used can be radar charts, statistical charts, coordinate charts, etc., which are not limited in the embodiments of the present application.

[0091] Figure 5A schematic diagram of a graphical visualization result provided in an embodiment of the present application, see Figure 5 The health parameters of the code warehouse in the warehouse file dimension can be called warehouse file health, the health parameters of the code warehouse in the warehouse object dimension can be called warehouse object health, the health parameters of the code warehouse in the warehouse LFS dimension can be called warehouse LFS health, the health parameters of the code warehouse in the warehouse MR dimension can be called warehouse MR health, and the health parameters of the code warehouse in the warehouse engineering capability dimension can be called engineering capability health. Figure 5 In the analysis, the health parameters of the code repository in the five detection dimensions are 8, 5, 7, 5, and 10 respectively. Figure 5 In the display, the health test results of different test dimensions are displayed as dots or numbers on the radar chart.

[0092] After determining the graphic visualization result, the detection device can display the graphic visualization result. In the case where the detection device has a display function, for example, the detection device is a terminal used by the user, the detection device can directly display the graphic visualization result on the display screen. In the case where the detection device does not have a display function, for example, the detection device is a server, the detection device can send the graphic visualization result to the terminal based on the communication connection with the terminal of the user, and control the terminal to display the graphic visualization result.

[0093] In one possible case, for detection dimensions of different health levels, the detection device may use different display features to display the display identifiers of detection dimensions of different health levels. The display feature may be display color, font, or size, etc. Taking the display feature as color as an example, the color corresponding to health is green, the color corresponding to sub-health is yellow, the color corresponding to unhealthy is orange, and the color corresponding to extremely unhealthy is red. For example, the healthy parameter range is 8 to 10, the sub-healthy parameter range is 5 to 7, the unhealthy parameter range is 3 to 4, and the extremely unhealthy parameter range is 0 to 2. Figure 5 The health level corresponding to the warehouse file dimension and warehouse engineering capability dimension is healthy, and the numbers on the radar chart are green. The health level corresponding to the warehouse object dimension, warehouse LFS dimension, and warehouse MR dimension is sub-healthy, and the numbers on the radar chart are yellow.

[0094] Exemplarily, the graphical visualization result also includes display information of metadata of each detection dimension. After displaying the health score or health level of the code repository in each detection dimension, the detection device also displays detailed indicator information, i.e., metadata, of each detection dimension. Figure 6 Another graphical visualization result provided by the embodiment of the present application is: Figure 6 In the example, the radar chart also displays multiple metadata of the warehouse object dimensions.

[0095] Similar to the principle that different display features are used to display the display identifiers of different detection dimensions based on the health level, when the detection device displays the display information of multiple metadata of any detection dimension, it will also use different display features to distinguish the display information of multiple metadata. For example, the color used is determined according to the indicator parameters corresponding to each metadata and the parameter range of each level. In this case, Figure 6 The number of Git objects and the percentage of duplicate commit tags are in red, the number of branches is in orange, and the number of tags and the number of loose objects are in green.

[0096] In a possible implementation, in addition to displaying the health test results of the code warehouse, the detection device will also issue an alarm based on the health test results. For example, the operating indicators to be repaired of the code warehouse are determined based on the health test results of the code warehouse; the alarm information of the operating indicators to be repaired is generated, and the alarm information is displayed, and the alarm information is used to prompt the operating indicators to be repaired to be repaired. Exemplarily, the detection device sets the tolerance threshold corresponding to each operating indicator based on experience or implementation environment, compares the indicator parameters and tolerance thresholds of each operating indicator, and determines that any operating indicator is an operating indicator to be repaired when the indicator parameter of any operating indicator is less than the tolerance threshold. Or the detection device compares the actual value of each operating indicator, that is, metadata and tolerance threshold, and determines that the operating indicator is an operating indicator to be repaired when the metadata of any operating indicator is less than the tolerance threshold. Taking the operating indicator as the binary file size ratio, the tolerance threshold is used for comparison with metadata as an example, the binary file size ratio of the code warehouse is 60%. The tolerance threshold set based on experience is 30%. Since 60% is greater than 30%, the binary file size ratio is determined to be the operating indicator to be repaired. In addition, the tolerance thresholds corresponding to different operating indicators may be the same or different, and the tolerance thresholds of different operating indicators may also be related to the importance of the operating indicators. For example, the higher the importance of the operating indicator, the closer the tolerance threshold is to the reference value. By setting the tolerance threshold corresponding to the operating indicator according to the importance of the operating indicator, the more important the operating indicator, the faster the alarm will be, which effectively improves the timeliness of the alarm.

[0097] After determining the operating indicator to be repaired, the detection device can generate an alarm message to prompt the repair of the operating indicator. The alarm message can be text, such as "the binary file occupies too much space", or an alarm sign can be added next to the display information of the metadata of the operating indicator. For example, a red exclamation mark is added next to the binary file size ratio as an alarm sign to prompt the object that the operating indicator of the binary file size ratio needs to be repaired.

[0098] In one possible case, after determining the operating indicator to be repaired, the detection device can also determine the repair strategy corresponding to the operating indicator to be repaired based on the correspondence between the operating indicator and the repair strategy; and display the repair strategy corresponding to the operating indicator to be repaired. The embodiment of the present application does not limit the process of the detection device obtaining the correspondence between the operating indicator and the repair strategy, which can be input by the operation and maintenance object through the information input control, or can be learned by the detection device based on historical data. For example, the detection device crawls the repair log of the code repository stored on the open source website, learns the operating indicator stored in the repair log and the repair strategy of the operating indicator, and obtains the correspondence between the operating indicator and the repair strategy.

[0099] After obtaining the correspondence between the operating indicators and the repair strategies, the detection device can query the correspondence between the operating indicators and the repair strategies according to the operating indicators to be repaired, and obtain the repair strategies corresponding to the operating indicators to be repaired. Taking the operating indicators to be repaired as the binary file size ratio in the above embodiment as an example, the corresponding repair strategy is, for example, to move large binary files to the Git-LFS warehouse. Afterwards, the detection device can display the determined repair strategy to the object. The repair strategy and the alarm information can be displayed synchronously, for example, the displayed text includes "the binary file occupies too much space, and the corresponding improvement measure is to move the large binary file to the Git-LFS warehouse". The repair strategy and the alarm information can also be displayed asynchronously. For example, when it is detected that the object starts to repair the operating indicator to be repaired, the repair strategy is displayed in the lower right corner of the screen, or the repair strategy is announced by voice to assist in the process of the object repairing the operating indicator, thereby improving the repair efficiency.

[0100] In summary, the detection method of the code warehouse provided by the embodiment of the present application, the detection device automatically collects the metadata of the code warehouse, and automatically analyzes the collected metadata to obtain the health detection result of the code warehouse. The detection process of the code warehouse is simple, the operation difficulty is low, no human participation is required, the efficiency is high, and the labor cost is low. The detection of the code warehouse can be automatically triggered based on the operation of the code warehouse, and the timeliness is high. The code warehouse is professionally and detailedly tested from multiple detection dimensions, and the health detection results obtained by comprehensive detection are highly credible. The health parameters can be determined by weighted summation of multiple indicator parameters, and multiple operating indicators are summed according to the degree of importance based on the indicator weights. The obtained health parameters are more scientific and objective, and are easier to reflect the true health status of the code warehouse. After obtaining the health detection results, the graphical visualization results of the health detection results will also be displayed to realize the online visualization of the health status of the code warehouse, so that the user can perceive the health status of the code warehouse more intuitively and clearly. For abnormal operating indicators, an alarm will be actively issued to prompt the user to repair them in time, thereby improving the interactive experience of the user using the code warehouse.

[0101] Figure 7 A schematic diagram of a process for detecting a code repository provided in an embodiment of the present application, Figure 7 For a description of portal, project server, collector, Git server, LFS server, and Git proxy, see Figure 2 The descriptions of portal, project server, collector, Git server, LFS server, and Git proxy in the previous section will not be repeated here. Figure 7 The leftmost person icon in the figure indicates the user.

[0102] See also Figure 7 , the collector collects metadata of the code repository and sends a collection instruction for obtaining metadata to the Git server. The Git server starts to collect metadata of the repository file dimension and repository object dimension of the code repository based on the collection instruction, and reports the collected metadata to the collector. The collector saves the metadata reported by the Git server, for example, in a database that establishes a communication connection. Optionally, the collector also sends a collection instruction for obtaining metadata to the LFS server and Git proxy. The LFS server starts to collect metadata of the repository LFS dimension and reports the collected metadata to the collector. The Git proxy starts to collect metadata of the repository engineering capability dimension and reports the collected metadata to the collector. The collector saves the metadata reported by the LFS server and Git proxy.

[0103] After that, the user can access the project details page through protal and trigger the detection control on the project details page. Protal sends a detection instruction to the project server to obtain the health detection result based on the triggering of the detection control. The project server sends a request instruction to the collector to obtain metadata based on the reception of the detection instruction. After receiving the request instruction, the collector returns the stored metadata to the project server. The project server thus obtains metadata in the warehouse file dimension, warehouse object dimension, warehouse LFS dimension, and warehouse engineering capability dimension. For the metadata of the warehouse MR dimension, the project server can count the MR based on the received metadata to obtain the metadata of the warehouse MR dimension, and perform health detection of the code warehouse based on the metadata of the obtained multiple detection dimensions, obtain the health detection result, and return the health detection result to protal. Protal displays the received health detection result and presents the health status of the code warehouse to the user.

[0104] During the protal display period, protal may detect that there are operating indicators to be repaired, and send instructions to projectserver to obtain alarms and improvement measures for the operating indicators to be repaired. Project server generates warehouse health alarms and improvement measures based on the received instructions, and returns the generated alarms and improvement measures. Protal displays the received alarms and improvement measures, notifies the user and guides the user to repair the code repository.

[0105] The above describes the code repository detection method of the embodiment of the present application. Corresponding to the above method, the embodiment of the present application also provides a code repository detection device. Figure 8 Schematic diagram of a code repository detection device provided in an embodiment of the present application. Figure 8 As shown in the following multiple modules, the Figure 8 The detection device of the code warehouse shown can perform the above Figure 4 It should be understood that the device may include more additional modules than the modules shown or omit some of the modules shown, and the embodiments of the present application are not limited to this. Figure 8 As shown, the device comprises:

[0106] An acquisition module 801 is used to acquire multiple metadata of a code repository, where the code repository is used to provide a code hosting service for the stored code, where the code is stored based on a project level or a program level, and the multiple metadata describe the operation of the code repository through at least one detection dimension, where the detection dimension is divided based on operations performed by the code repository in the process of providing the code hosting service;

[0107] A determination module 802 is used to determine health parameters of the code repository in each detection dimension according to the plurality of metadata, where the health parameters of the detection dimension are used to describe the execution performance of the code repository in executing operations corresponding to the detection dimension;

[0108] The determination module 802 is further used to obtain a health detection result of the code repository based on the health parameters of the code repository in various detection dimensions. The health detection result is used to describe the service performance of the code hosting service provided by the code repository.

[0109] In one possible implementation, the metadata includes the actual value of the operating indicator. The determination module 802 is used to obtain the reference value of the operating indicator corresponding to each metadata of any detection dimension for multiple metadata of any detection dimension, and determine the indicator parameter of each operating indicator according to the difference between the actual value and the reference value of each operating indicator, where the indicator parameter indicates the health of the operating indicator; and perform weighted summation on multiple indicator parameters of any detection dimension to obtain the health parameter of the code repository in any detection dimension.

[0110] In a possible implementation, the health detection result includes at least one of a health parameter of the code repository in each detection dimension or a health level of the code repository in each detection dimension, and the health level is determined based on the health parameter.

[0111] In a possible implementation, the acquisition module 801 is also used to obtain a graphical visualization result of the health detection result, and the graphical visualization result includes a display mark of the health detection result of the code repository in each detection dimension; the device also includes: a first display module, which is used to display the graphical visualization result.

[0112] In a possible implementation, the graphic visualization result also includes display information of metadata of each detection dimension.

[0113] In a possible implementation, the first display module is used to display display identifiers of detection dimensions of different health levels using different display features.

[0114] In one possible implementation, the determination module 802 is also used to determine the operating indicators of the code warehouse to be repaired based on the health check results of the code warehouse; the device also includes: a second display module, used to generate alarm information of the operating indicators to be repaired, and display the alarm information, wherein the alarm information is used to prompt to repair the operating indicators to be repaired.

[0115] In a possible implementation, the determination module 802 is further used to determine the repair strategy corresponding to the operating indicator to be repaired according to the correspondence between the operating indicator and the repair strategy; the second display module is further used to display the repair strategy corresponding to the operating indicator to be repaired.

[0116] In a possible implementation, at least one detection dimension includes at least one of a warehouse object dimension, a warehouse file dimension, a warehouse engineering capability dimension, a warehouse large file storage LFS dimension, or a warehouse merge request MR dimension.

[0117] The above device automatically collects metadata of the code warehouse, and automatically detects based on the collected metadata, so as to determine the health detection result of the code warehouse. The detection process of the code warehouse is simple, the operation difficulty is low, the detection process does not require human participation, and the labor cost is low.

[0118] Wherein, both the acquisition module 801 and the determination module 802 can be implemented by software or by hardware. Exemplarily, the implementation of the determination module 802 is described below by taking the determination module 802 as an example. Similarly, the implementation of the acquisition module 801 can refer to the implementation of the determination module 802.

[0119] As an example of a software functional unit, the module 802 can include code running on a computing instance. Among them, the computing instance can include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance can be one or more. For example, the module 802 can include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code can be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including a data center or multiple data centers with similar geographical locations. Among them, usually a region can include multiple AZs.

[0120] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0121] As an example of a hardware functional unit, the determination module 802 may include at least one computing device, such as a server, etc. Alternatively, the determination module 802 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0122] The multiple computing devices included in the determination module 802 may be distributed in the same region or in different regions. The multiple computing devices included in the determination module 802 may be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the determination module 802 may be distributed in the same VPC or in multiple VPCs. The multiple computing devices may be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0123] It should be noted that, in other embodiments, the acquisition module 801 or the determination module 802 can be used to execute any step in the code repository detection method, and the steps that the acquisition module 801 or the determination module 802 is responsible for implementing can be specified as needed. The acquisition module 801 or the determination module 802 can respectively implement different steps in the code repository detection method to realize the full functions of the code repository detection device.

[0124] The present application also provides a computing device 900. Fig. 9 As shown, the computing device 900 includes: a bus 902, a processor 904, a memory 906, and a communication interface 908. The processor 904, the memory 906, and the communication interface 908 communicate through the bus 902. The computing device 900 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 900.

[0125] The bus 902 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig. 9 The bus 902 may include a path for transmitting information between various components of the computing device 900 (eg, the memory 906, the processor 904, and the communication interface 908).

[0126] The processor 904 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0127] The memory 906 may include a volatile memory, such as a random access memory (RAM). The processor 904 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0128] The memory 906 stores executable program codes, and the processor 904 executes the executable program codes to implement the functions of the acquisition module or the determination module, respectively, thereby implementing the code repository detection method. That is, the memory 906 stores instructions for executing the code repository detection method.

[0129] The communication interface 908 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 900 and other devices or communication networks.

[0130] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0131] Optionally, the structure of at least one computing device included in the computing device cluster can be found in Fig. 9 The computing device 900 is shown. The memory 906 in one or more computing devices 900 in the computing device cluster may store the same instructions for executing the code repository detection method.

[0132] In some possible implementations, the memory 906 of one or more computing devices 900 in the computing device cluster may also store partial instructions for executing the code repository detection method. In other words, the combination of one or more computing devices 900 may jointly execute instructions for executing the code repository detection method.

[0133] It should be noted that the memory 906 in different computing devices 900 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of the detection device of the code repository. That is, the instructions stored in the memory 906 in different computing devices 900 can implement the functions of one or more modules in the acquisition module or the determination module.

[0134] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.10 A possible implementation is shown. Fig.10 As shown, two computing devices 1000A and 1000B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, computing devices 1000A and 1000B include a bus 1002, a processor 1004, a memory 1006, and a communication interface 1008. The memory 1006 in the computing device 1000A stores instructions for executing the functions of the acquisition module. At the same time, the memory 1006 in the computing device 1000B stores instructions for executing the functions of the determination module.

[0135] Fig.10 The connection method between the computing device clusters shown can be based on the interactive intention that the detection method of the code repository provided in the present application needs to feedback the health detection results, so it is considered to hand over the functions implemented by the determination module to the computing device 1000A for execution.

[0136] It should be understood that Fig.10 The functions of the computing device 1000A shown in FIG. 1000A may also be completed by multiple computing devices 1000. Similarly, the functions of the computing device 1000B may also be completed by multiple computing devices 1000.

[0137] The embodiment of the present application also provides a communication device, which includes: a transceiver, a memory, and a processor. The transceiver, the memory, and the processor communicate with each other through an internal connection path, the memory is used to store instructions, and the processor is used to execute the instructions stored in the memory to control the transceiver to receive signals and control the transceiver to send signals, and when the processor executes the instructions stored in the memory, the processor executes the code repository detection method.

[0138] It should be understood that the above processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor supporting the advanced RISC machines (ARM) architecture.

[0139] Further, in an optional embodiment, the memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. The memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0140] The memory may be a volatile memory or a nonvolatile memory, or may include both volatile and nonvolatile memory. Among them, the nonvolatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM) and direct memory bus random access memory (DR RAM).

[0141] The embodiment of the present application also provides a computer program (product) comprising instructions. The computer program (product) may be software or a program (product) comprising instructions that can be run on a computing device or stored in any available medium. When the computer program (product) is run on at least one computing device, the at least one computing device executes the detection method of the code repository.

[0142] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes instructions that instruct the computing device to execute a detection method for a code repository.

[0143] An embodiment of the present application also provides a chip, including a processor, for calling and executing instructions stored in a memory from the memory, so that a communication device equipped with the chip executes any of the code repository detection methods described above.

[0144] An embodiment of the present application also provides another chip, including: an input interface, an output interface, a processor and a memory, wherein the input interface, the output interface, the processor and the memory are connected via an internal connection path, and the processor is used to execute the code in the memory. When the code is executed, the processor is used to execute any of the code repository detection methods described above.

[0145] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in this application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk), etc.

[0146] In order to clearly illustrate the interchangeability of hardware and software, the steps and components of each embodiment have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. A person of ordinary skill in the art may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0147] The computer program code for realizing the method for the embodiment of the present application can be written in one or more programming languages. These computer program codes can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable rule-finding device, so that the program code, when executed by a computer or other programmable rule-finding device, causes the function / operation specified in the flow chart and / or block diagram to be implemented. The program code can be executed completely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer or completely on a remote computer or server.

[0148] In the context of the embodiments of the present application, computer program codes or related data may be carried by any appropriate carrier to enable a device, apparatus or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, etc. Examples of signals may include electrical, optical, radio, acoustic or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0149] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0150] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the module is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, or it can be an electrical, mechanical or other form of connection.

[0151] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0152] In addition, each functional module in each embodiment of the present application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

[0153] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions. For example, the metadata involved in this application are all obtained with full authorization.

[0154] In this application, the terms "first", "second", etc. are used to distinguish between identical or similar items with substantially the same effects and functions. It should be understood that there is no logical or temporal dependency between "first", "second", and "nth", nor is the quantity and execution order limited. It should also be understood that although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of the various described examples, a first link may be referred to as a second link, and similarly, a second link may be referred to as a first link.

[0155] It should also be understood that in the various embodiments of the present application, the size of the serial number of each process does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0156] The term "at least one" in this application means one or more, and the term "multiple" in this application means two or more, for example, multiple second messages means two or more second messages. The terms "system" and "network" are often used interchangeably herein.

[0157] It should be understood that the terms used in the description of the various examples herein are only for describing specific examples and are not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0158] It should also be understood that the term “comprise” (also known as “includes,” “including,” “comprises” and / or “comprising”) when used in this specification specifies the presence of stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0159] It should also be understood that, depending on the context, the phrase “if it is determined that…” or “if [stated condition or event] is detected” may be interpreted to mean “upon determining that…” or “in response to determining that…” or “upon detecting [stated condition or event]” or “in response to detecting [stated condition or event]”.

[0160] It should be understood that determining B based on A does not mean determining B only based on A. B can also be determined based on A and / or other information.

[0161] It should also be understood that the references to "one embodiment", "an embodiment", or "a possible implementation" throughout the specification mean that specific features, structures, or characteristics related to the embodiment or implementation are included in at least one embodiment of the present application. Therefore, the references to "in one embodiment" or "in an embodiment", or "a possible implementation" throughout the specification do not necessarily refer to the same embodiment. In addition, these specific features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0162] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A code repository detection method, characterized in that: The method comprises: Acquire multiple metadata of a code repository, the code repository is used to provide a code hosting service for stored code, the code is stored based on a project level or a program level, the multiple metadata describe the operation of the code repository through at least one detection dimension, the detection dimension is based on the operation division performed by the code repository in the process of providing the code hosting service; Determine, according to the plurality of metadata, a health parameter of the code repository in each detection dimension, where the health parameter of the detection dimension is used to describe the execution performance of the code repository in executing an operation corresponding to the detection dimension; A health detection result of the code repository is obtained based on the health parameters of the code repository in each detection dimension, and the health detection result is used to describe the service performance of the code hosting service provided by the code repository.

2. The method according to claim 1, characterized in that The metadata includes actual values ​​of the operating indicators, and determining the health parameters of the code repository in various detection dimensions according to the plurality of metadata includes: For multiple metadata of any detection dimension, obtain a reference value of an operation indicator corresponding to each metadata of the detection dimension, and determine an indicator parameter of each operation indicator according to a difference between an actual value of each operation indicator and the reference value, wherein the indicator parameter indicates a health level of the operation indicator; A weighted sum is performed on multiple indicator parameters of any detection dimension to obtain a health parameter of the code repository in any detection dimension.

3. The method according to claim 1 or 2, characterized in that: The health detection result includes at least one of a health parameter of the code repository in each detection dimension or a health level of the code repository in each detection dimension, and the health level is determined based on the health parameter.

4. The method according to any one of claims 1 to 3, characterized in that: After obtaining the health detection result of the code warehouse based on the health parameters of the code warehouse in each detection dimension, the method further includes: Obtaining a graphical visualization result of the health detection result, wherein the graphical visualization result includes a display identifier of the health detection result of the code repository in each detection dimension; The graphical visualization results are displayed.

5. The method according to claim 4, characterized in that The graphic visualization result also includes display information of metadata of each detection dimension.

6. The method according to claim 4 or 5, characterized in that: The displaying of the graphical visualization result comprises: For detection dimensions of different health levels, different display features are used to display display identifiers of the detection dimensions of different health levels.

7. The method according to any one of claims 1 to 6, characterized in that: After obtaining the health detection result of the code warehouse based on the health parameters of the code warehouse in each detection dimension, the method further includes: Determining the operating indicators of the code warehouse to be repaired according to the health detection results of the code warehouse; Generate alarm information of the operating indicator to be repaired, display the alarm information, and use the alarm information to prompt to repair the operating indicator to be repaired.

8. The method according to claim 7, characterized in that After determining the operation index of the code warehouse to be repaired according to the health detection result of the code warehouse, the method further includes: Determining the repair strategy corresponding to the operating indicator to be repaired according to the corresponding relationship between the operating indicator and the repair strategy; The repair strategy corresponding to the operating indicator to be repaired is displayed.

9. The method according to any one of claims 1 to 8, characterized in that: The at least one detection dimension includes at least one of a warehouse object dimension, a warehouse file dimension, a warehouse engineering capability dimension, a warehouse large file storage LFS dimension, or a warehouse merge request MR dimension.

10. A code repository detection device, characterized in that: The device comprises: an acquisition module, configured to acquire a plurality of metadata of a code repository, the code repository being configured to provide a code hosting service for stored code, the code being stored based on a project level or a program level, the plurality of metadata describing an operation of the code repository through at least one detection dimension, the detection dimension being divided based on operations performed by the code repository in the process of providing the code hosting service; a determination module, configured to determine health parameters of the code repository in each detection dimension according to the plurality of metadata, wherein the health parameters of the detection dimension are used to describe the execution performance of the code repository in executing operations corresponding to the detection dimension; The determination module is further used to obtain a health detection result of the code repository based on the health parameters of the code repository in each detection dimension, and the health detection result is used to describe the service performance of the code hosting service provided by the code repository.

11. The device according to claim 10, characterized in that The metadata includes an actual value of the operating indicator, and the determining module is used to obtain, for a plurality of metadata of any detection dimension, a reference value of the operating indicator corresponding to each metadata of the any detection dimension, and determine an indicator parameter of each operating indicator according to a difference between the actual value of each operating indicator and the reference value, wherein the indicator parameter indicates a health level of the operating indicator; A weighted sum is performed on multiple indicator parameters of any detection dimension to obtain a health parameter of the code repository in any detection dimension.

12. The device according to claim 10 or 11, characterized in that The health detection result includes at least one of a health parameter of the code repository in each detection dimension or a health level of the code repository in each detection dimension, and the health level is determined based on the health parameter.

13. The device according to any one of claims 10 to 12, characterized in that: The acquisition module is also used to obtain the graphical visualization results of the health detection results, and the graphical visualization results include display identifiers of the health detection results of the code repository in each detection dimension; the device also includes: a first display module, which is used to display the graphical visualization results.

14. The device according to claim 13, characterized in that The graphic visualization result also includes display information of metadata of each detection dimension.

15. The device according to claim 13 or 14, characterized in that The first display module is used to display the display identifiers of the detection dimensions of different health levels using different display features.

16. The device according to any one of claims 10 to 15, characterized in that: The determination module is also used to determine the operating indicators to be repaired of the code warehouse based on the health check results of the code warehouse; the device also includes: a second display module, used to generate alarm information of the operating indicators to be repaired, and display the alarm information, wherein the alarm information is used to prompt the repair of the operating indicators to be repaired.

17. The device according to claim 16, characterized in that The determination module is further used to determine the repair strategy corresponding to the operating indicator to be repaired according to the corresponding relationship between the operating indicator and the repair strategy; the second display module is further used to display the repair strategy corresponding to the operating indicator to be repaired.

18. The device according to any one of claims 10 to 17, characterized in that: The at least one detection dimension includes at least one of a warehouse object dimension, a warehouse file dimension, a warehouse engineering capability dimension, a warehouse large file storage LFS dimension, or a warehouse merge request MR dimension.

19. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, each computing device including a processor and a memory; The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the code repository detection method as described in any one of claims 1-9.

20. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the code repository detection method according to any one of claims 1 to 9.

21. A chip, characterized in that: The chip includes a processor, and the processor is used to run program instructions or codes, so that a device including the chip executes the code repository detection method as described in any one of claims 1-9.

22. A computer program product, characterized in that The computer program product includes a computer program / instructions, and the computer program / instructions are executed by a processor to enable a computer to execute the code repository detection method as described in any one of claims 1-9.

Images