Information processing method, apparatus, device, storage medium, and computer program product

By retrieving and archiving file and version information of specified versions from a remote repository and storing it in a third-party storage system, the high-concurrency read and write performance problem of Git repositories in large-scale DevOps practices is solved, and efficient source code distribution and resource utilization are achieved.

CN114047943BActive Publication Date: 2026-04-28BEIJING BAIDU NETCOM SCI & TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
BEIJING BAIDU NETCOM SCI & TECH CO LTD
Filing Date
2021-11-09
Publication Date
2026-04-28

AI Technical Summary

Technical Problem

In large-scale DevOps practices, the traditional Git repository source code distribution method leads to a decrease in read and write performance under high concurrency, an increase in read and write pressure on remote Git repositories, and an inability to meet the requirements of high concurrency and high performance.

Method used

By obtaining specified version file information and version information from a remote repository, archiving the data, and storing it in a third-party storage system, archive packages are provided to reduce the read and write pressure on the remote repository and improve overall read and write performance and throughput.

Benefits of technology

It reduces the read and write pressure on the remote repository, improves overall read and write performance and throughput, is suitable for different use cases, and reduces resource waste and download time.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114047943B_ABST
    Figure CN114047943B_ABST
Patent Text Reader

Abstract

The present disclosure provides an information processing method, device, equipment, storage medium and computer program product, relates to the technical field of computers, and particularly relates to the field of software development. The specific implementation scheme is as follows: acquiring at least one item of information in file information and version information of a specified version in a remote version library; archiving the at least one item of information to obtain an archiving package of the specified version; the type of the archiving package of the specified version is a first type or a second type, the archiving package of the first type carries the file information of the specified version, and the archiving package of the second type carries the file information and the version information of the specified version; sending the archiving package of the specified version to a third-party storage system; and the third-party storage system is used for storing the archiving package. The technical scheme of the present disclosure can archive at least one item of information in the file information and the version information of the specified version in the remote version library and store the information in the third-party storage system, so as to reduce the read-write pressure of the remote version library and improve the overall read-write performance and throughput.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to the field of software development, specifically to an information processing method, apparatus, device, storage medium, and computer program product. Background Technology

[0002] DevOps (a collective term for processes, methods, and systems) practices are now widely used in the software development field. In DevOps practice scenarios, Git (a distributed version control system) is currently the most popular code hosting tool. Every developer can copy a complete Git repository from a remote repository locally by cloning (git clone).

[0003] Existing source code distribution methods require retrieving source code from a remote Git repository. Due to the special nature of the Git protocol, the main methods for retrieving source code from a remote Git repository are cloning (git clone) and pulling (git pull / fetch). Both methods require creating a local Git repository, and the amount of data pulled is relatively large, typically including all historical versions of a specified branch. In various DevOps scenarios such as compilation, building, automated testing, deployment, and production, the read and write performance of a single Git repository will drop sharply under high concurrency. This is especially true for some large Git repositories, where the read success rate will decrease significantly. Continuous failures and retries further increase the read and write pressure on the remote Git repository, creating a vicious cycle that further prolongs the source code download time and also affects the performance of other push requests. Summary of the Invention

[0004] This disclosure provides an information processing method, apparatus, device, storage medium, and computer program product.

[0005] According to a first aspect of this disclosure, an information processing method is provided, comprising:

[0006] Retrieves at least one of the following information from a remote repository: file information and version information for a specified version.

[0007] Archive at least one piece of information to obtain an archive package of a specified version; the archive package of the specified version is of type 1 or type 2, the archive package of type 1 carries file information of the specified version, and the archive package of type 2 carries file information and version information of the specified version;

[0008] Send a specified version of the archive package to a third-party storage system; the third-party storage system is used to store the archive package.

[0009] According to a second aspect of this disclosure, an information processing apparatus is provided, comprising:

[0010] The information acquisition module is used to acquire at least one of the following information from the remote repository: text information and version information for a specified version.

[0011] The archiving module is used to archive at least one piece of information to obtain an archive package of a specified version. The archive package of the specified version is of type 1 or type 2. The archive package of type 1 carries file information of the specified version, and the archive package of type 2 carries file information and version information of the specified version.

[0012] The archive storage module sends a specified version of the archive package to a third-party storage system; the third-party storage system is used to store the archive package.

[0013] According to a third aspect of this disclosure, an electronic device is provided, comprising:

[0014] At least one processor; and

[0015] A memory that is communicatively connected to at least one processor; wherein,

[0016] The memory stores instructions that can be executed by at least one processor to enable the at least one processor to perform the information processing method provided in any embodiment of this disclosure.

[0017] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to perform an information processing method provided in any embodiment of this disclosure.

[0018] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the information processing method provided in any embodiment of this disclosure.

[0019] The technical solution disclosed herein can achieve at least the following beneficial effects:

[0020] The technical solution disclosed herein can archive at least one of the following information from a remote repository: file information and version information of a specified version. The archived package is then stored in a third-party storage system. The third-party storage system can store the archive package and provide it to the user when needed, thereby providing the corresponding version information. This reduces the read and write pressure on the remote repository and improves overall read and write performance and throughput. The archive package can carry version information of a specified version or not, making it suitable for scenarios where the original version information needs to be restored or where it does not need to be restored, thus meeting different usage requirements.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0023] Figure 1 This is a flowchart illustrating an information processing method provided in an embodiment of this disclosure;

[0024] Figure 2 This is a schematic diagram illustrating the principle of obtaining a specified version based on the Git shallow bundle method in this embodiment of the disclosure;

[0025] Figure 3 This is a partial flowchart illustrating another information processing method provided in this embodiment of the disclosure;

[0026] Figure 4 This is a schematic diagram illustrating an example of the information processing method provided in this embodiment of the disclosure;

[0027] Figure 5 This is a schematic diagram of the structural framework of an information processing device provided in an embodiment of this disclosure;

[0028] Figure 6 This is a schematic diagram of the structural framework of the address generation module in an embodiment of this disclosure;

[0029] Figure 7 This is a schematic diagram of the structural framework of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0030] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0031] First, the following is a brief introduction to several terms used in this disclosure:

[0032] DevOps, a combination of Development and Operations, is a collective term for a set of processes, methods, and systems used to facilitate communication, collaboration, and integration among development (application / software engineering), technical operations, and quality assurance departments. DevOps requires the use of highly standardized and automated processes and tools to support efficient collaboration among roles, thereby achieving the goal of faster, more frequent, and more reliable software delivery.

[0033] Git: An open-source distributed version control system that can effectively and quickly handle version management for projects ranging from very small to very large.

[0034] Cloud-native: A methodology for building and running applications that fully leverage the advantages of the cloud computing model. Cloud-native technologies enable organizations to build and run elastically scalable applications in new, dynamic environments such as public, private, and hybrid clouds. Key cloud-native technologies include containers, service meshes, microservices, immutable infrastructure, and declarative APIs (Application Programming Interfaces). These technologies enable the construction of loosely coupled systems that are fault-tolerant, easy to manage, and observable. Combined with reliable automation, cloud-native technologies allow engineers to easily make frequent and predictable major changes to systems.

[0035] In the cloud-native era, DevOps itself widely adopts large-scale distributed build and large-scale distributed continuous integration / delivery technology architectures in scenarios involving large-scale automated processes and tools. Containerization is a crucial aspect of cloud-native development, and the challenges it brings to source code hosting primarily stem from statelessness and high-concurrency, high-performance access.

[0036] Traditional source code distribution primarily involves creating local Git repositories through cloning (git clone) and pulling (git pull / fetch). However, in various DevOps scenarios such as compilation, building, automated testing, deployment, and production, only a specific version of the source code is truly needed. Downloading and transferring a large amount of irrelevant version history consumes computing resources and reduces development efficiency. Furthermore, in large-scale DevOps scenarios, excessive data reading and transmission leads to inefficient source code downloads and wasted computing and network resources. Therefore, traditional source code distribution methods cannot meet the high concurrency and high performance requirements of large-scale DevOps practices.

[0037] To address this issue, the following are the main solutions:

[0038] Option 1 involves adding read nodes to the remote server to handle the high concurrency access pressure on the source code from large-scale DevOps automation tasks.

[0039] Option 2: Add source code caching to the local client to alleviate the read pressure on the remote server.

[0040] Option 3 involves upgrading the Git protocol on a remote server to enable single-version fetching, thereby reducing unnecessary resource waste.

[0041] However, the above solution has the following problems:

[0042] In Option 1, there is a delay in data synchronization between the master node and the read node, resulting in poor data synchronization. Furthermore, due to the inherent principles of Git and its characteristic of needing to handle a large number of small files in practice, the number of concurrent connections that a single Git service instance can support is very limited.

[0043] Option 2 is not applicable to the cloud-native era. Services running in containers in the cloud-native era typically mount third-party storage services. Therefore, due to the limitation that a Git workspace can only have one view corresponding to a given version at any given time, services in containers cannot see multiple versions of the same view in the same workspace at the same time, and therefore cannot use multiple versions of the source code simultaneously in the same space.

[0044] Solution 3 fails to retrieve a specific version and does not completely solve the high-concurrency read problem of the remote Git repository. First, changes to the remote Git repository can occur at any time, and the client cannot know the cloning depth or version time, thus making it impossible to accurately retrieve a specific version. Second, Solution 3 must retrieve the source code of the remote Git repository starting from the latest commit information of the version, i.e., the commit information pointed to by the branch head pointer (HEAD). To retrieve the source code of a specific version, all commit information from the current latest commit information back to the specified commit information must be retrieved, thus failing to completely solve the high-concurrency read problem of the remote Git repository and still resulting in significant resource waste.

[0045] According to embodiments of this disclosure, this disclosure provides an information processing method that can be applied to Git servers or other servers, such as... Figure 1 As shown, the method includes:

[0046] S101, retrieve at least one of the following information from the remote repository: file information and version information for a specified version.

[0047] In this embodiment of the disclosure, the remote repository can be a Git repository on a remote Git server, hereinafter referred to as a remote Git repository.

[0048] In this embodiment of the disclosure, the file information of the specified version may include information of at least one file, namely a text file (i.e., a source code file) and a binary file, and the version information of the specified version may include the history of the specified version.

[0049] Optionally, the operation of obtaining file information and / or version information of a specified version in a remote repository can be implemented through an archive task building service or other services. The corresponding services can be set according to the actual situation, and the embodiments of this disclosure do not limit this.

[0050] S102, archive at least one of the file information and version information of the specified version to obtain an archive package of the specified version.

[0051] The archive package for the specified version is of type 1 or type 2. Type 1 archive packages contain file information for the specified version, while type 2 archive packages contain both file information and version information for the specified version.

[0052] In scenarios where archiving is based on the first type, file information for a specified version can be archived to obtain a first-type archive package for that version. In scenarios where archiving is based on the second type, both file information and version information for a specified version can be archived to obtain a second-type archive package for that version. Both first-type and second-type archive packages can be used to restore (restore from file information) a specified version of a file. The second-type archive package can also be used to restore (restore from version information) a specified version of a version record.

[0053] Optionally, the operation of archiving file information and / or version information of a specified version can be implemented through an archiving task processing service or other services. The corresponding services can be set according to the actual situation, and the embodiments of this disclosure do not limit this.

[0054] S103 sends a specified version of the archive package to a third-party storage system.

[0055] Third-party storage systems are used to store archive packages.

[0056] Optionally, the operation of sending a specified version of the archive package to a third-party storage system can be implemented through an archive storage and distribution service or other services. The corresponding services can be set according to the actual situation, and the embodiments disclosed herein do not limit this.

[0057] The technical solution disclosed herein can archive at least one of the following information from a remote repository: file information and version information of a specified version. The archived package is then stored in a third-party storage system. The third-party storage system can store the archive package and provide it to the user when needed, thereby providing the corresponding version information. This reduces the read and write pressure on the remote repository and improves overall read and write performance and throughput. The archive package can carry version information of a specified version or not, making it suitable for scenarios where the original version information needs to be restored or where it does not need to be restored, thus meeting different usage requirements.

[0058] The third-party storage system in this embodiment can be set up on a remote Git server or other server. Using a third-party storage system to store and distribute archive packages can alleviate the read and write pressure on the remote repository in high-concurrency scenarios and eliminate the single point of dependency on the remote repository.

[0059] In one optional implementation, obtaining at least one of the file information and version information of a specified version in a remote repository includes: if a version change occurs in the remote repository, obtaining at least one of the file information and version information of the changed version as at least one of the file information and version information of the specified version.

[0060] Optionally, whether a version change has occurred in the remote repository can be determined by monitoring or polling the versions in the remote repository, or by other methods. The goal is simply to determine whether a version change has occurred in the remote repository.

[0061] In one example, the archive task build service can monitor a remote repository to determine if the source code signals of each version in the remote repository have changed. When the archive task build service detects that the file information of one or more versions in the remote repository has changed, it considers that one or more versions to have changed. The archive task build service obtains the basic information of the one or more changed versions (as the specified version), creates an archive task based on the basic information, and sends the archive task to the next service, such as the archive task processing service. The archive task processing service can obtain at least one of the file information and version information of the changed version from the remote repository. The information obtained can be determined according to the actual type of archive required. Among them, the basic information of the changed version can include the commit information of the changed version.

[0062] In one example, the archive task build service can poll the remote repository periodically, checking its change log to determine if file information for each version in the remote repository has changed. When it's determined that file information for one or more versions in the remote repository has changed, the archive task build service considers those versions to have changed. The archive task build service can then obtain basic information about one or more changed versions (as specified versions) from the remote repository, create an archive task based on this basic information, and send the archive task to the next service, such as the archive task processing service. The archive task processing service can obtain at least one of the following information from the remote repository: file information and version information. The information obtained can be determined based on the type of archive required. The basic information of the changed version can include commit information. In one example, the changed version has specified commit information.

[0063] The above-described implementation method, which determines version changes by listening or polling and then creates an archive task, is a proactive archiving approach. It can obtain version change information in real time. When changes from the local client are sent to the remote repository, the archive task building service can quickly listen for the change and respond quickly to create an archive task, which helps improve the efficiency of source code archiving.

[0064] In another optional implementation, obtaining at least one of the file information and version information of a specified version in the remote repository includes: in response to an archive command sent by the client, obtaining at least one of the file information and version information of the version specified by the archive command in the remote repository, as at least one of the file information and version information of the specified version.

[0065] Optionally, the archive command carries specified commit information that can be used to determine one or more versions in the remote repository specified by the archive command.

[0066] In one example, after receiving an archive command from a client, the archive task build service retrieves the specified commit information carried in the archive command. Based on this commit information, it obtains the basic information of one or more versions (as specified versions) specified by the archive command from the remote repository. Based on this basic information, it creates an archive task and sends it to the next service, such as the archive task processing service. The archive task processing service can obtain at least one of the following information from the remote repository: file information and version information of the changed version. The information obtained can be determined according to the actual type of archive required. The basic information of the version specified by the archive command may include commit information.

[0067] Creating archive tasks based on archive commands sent by the client is a passive archiving method that can implement source code archiving in a targeted manner based on the user's actual needs.

[0068] Based on the above, the method of obtaining at least one of the file information and version information of a specified version in the remote version repository in this embodiment of the disclosure is applicable to both active archiving and passive archiving application scenarios, which is highly flexible and can meet different archiving needs.

[0069] Optionally, the first type can be Git archive, which is used to archive file information. A Git archive only corresponds to the complete file content of a specified version and does not contain any information to restore that specified version.

[0070] In one alternative implementation, the second type does not support the Git shallow clone protocol, which can be simply referred to as Git shallow clone. For example, the second type could be a Git bundle, which is used to archive file and version information. The Git bundle archive carries the necessary information for restoring the original files of a specified version. Specifically, it carries the Git objects needed to append new historical records to the existing history of the local Git repository (or Git version control repository). Through the Git bundle archive, new commit information can be appended incrementally to the existing commit history of the local Git repository, thereby reducing the need to request the complete commit history of the remote Git repository.

[0071] In another alternative implementation, the second type supports Git's shallow clone protocol. For example, the second type could be a Git shallow bundle, a special binary file format used to archive file and version information for shallow clone compatibility. A Git shallow bundle archive carries the necessary information to restore the original files of a specified version. The archive contains the version content to be archived, including version references, commit messages, trees, objects, etc.

[0072] This disclosure provides several types of archive packages (e.g., Git archive, Git bundle, and Git shallowbundle) that enable one-time computation and permanent storage, thereby reducing the large amount of unnecessary repetitive computation caused by frequent read and write operations to the remote repository. This reduces the waste of resources such as CPU (Central Processing Unit), memory, and network, and can provide more user read and write support under the same server resources, thus alleviating the read and write pressure on the remote repository in high-concurrency scenarios.

[0073] The archive packages provided in this disclosure can be adapted to various storage services, allowing them to be stored in various read-optimized storage services. Read acceleration can be achieved through CDN (Content Delivery Network) or other means, effectively improving the access speed for users to read file information and / or version information, and ensuring a high read success rate. In actual DevOps scenarios, traffic is characterized by a high read-to-write ratio. The above-mentioned solutions, adaptable to various read-optimized storage services, can effectively guarantee the success rate of DevOps in the file information and / or version information acquisition stage, reducing the time spent in this stage.

[0074] The second type in this embodiment can be a type that supports the Git shallow clone protocol, such as a Gitshallow bundle. This type can provide one or more specified versions in a remote repository, which well meets the user's need to read any sub-repository in a remote repository quickly and accurately.

[0075] In many R&D scenarios, especially in CI (Continuous Integration) / CD (Continuous Delivery) processes, the vast amount of historical commit information in remote repositories is of little practical use for the execution of actual tasks. Users simply want to obtain file information and / or version information for specific versions in the remote repository and perform processes such as inspection, scanning, building, compiling, publishing, and deployment based on this information. These common processes are usually only related to file information and / or version information for specific versions. Reading and transferring a large amount of historical data is a huge waste of computing and network resources and also hinders the implementation of large-scale DevOps practices. Git shallow bundles support the native Git shallow clone feature, allowing users to retrieve the latest commit information from the remote repository by executing the `git pull` (`git pull`) or `git fetch` command.

[0076] Furthermore, traditional solutions typically rely on Git shallow cloning to speed up the retrieval of remote repository commit information, but this solution can only be achieved using the `--depth` option. <depth>The parameter retrieves the latest commit information on the specified branch. <depth>+1 historical commit message, or via --shallow-since <date>Retrieve commit information after a certain time, but using --depth <depth>and --shallow-since <date>Both methods fail to accurately obtain depth and version time. However, the Git shallow bundle solution in this embodiment allows users to natively obtain a Git shallowclone local repository file containing specified commit information (which can consist of any number of commits required by the user) from the remote repository. This is equivalent to any sub-version of the remote repository, overcoming the shortcomings of the native Git shallow clone, enhancing Git's flexibility in reading sub-version history, and making it more suitable for large-scale DevOps.

[0077] The following reference Figure 2 The present disclosure provides a further description of the method for obtaining a specific version using a Git shallow bundle in the embodiments of this disclosure.

[0078] Figure 2 The first line shows the version of the remote repository on a certain branch, including the version with the branch's head pointer, the version containing commit message 1 (commit 1), and the version containing commit message 2 (commit 2). Figure 2 The second line shows a diagram illustrating how a version containing commit 2 can be obtained locally via Git shallow clone. Figure 2 The third line shows a diagram illustrating how to obtain a version containing commit 2 and commit 1 locally using Git shallow clone. As can be seen from the diagrams in the second and third lines, when obtaining file information and / or version information of a specified version locally using Git shallow clone, it is necessary to backtrack from the latest commit information of the branch, i.e., the commit information pointed to by the head pointer (HEAD), to all commit information of the specified commit information (commit 2 and / or commit 1), which involves unnecessary backtracking.

[0079] Figure 2 The fourth line illustrates a diagram of obtaining a version containing commit 2 locally via the Git bundle method in this embodiment of the disclosure. Figure 2 The fifth line illustrates a diagram of obtaining versions containing commit 2 and commit 1 locally using the Git bundle method in this embodiment. As can be seen from the diagrams in the fourth and fifth lines, when obtaining file information and / or version information of a specified version locally using the Git bundle method, it is also necessary to trace back from the latest commit information of the branch, i.e., the commit information pointed to by the head pointer (HEAD), to all the commit information carried by the Git bundle archive itself. Furthermore, when using the version of the specified commit information (commit 2 and / or commit 1) locally, the local repository must have the version of the Git bundle archive containing the historical commit information of the specified commit information (commit 2 and / or commit 1) as a prerequisite for normal use; otherwise, the Git bundle archive cannot be used normally.

[0080] Figure 2 The sixth line illustrates a diagram of obtaining a version containing commit 2 locally using the Git shallow bundle method in this embodiment of the disclosure. Figure 2 Line 7 illustrates a diagram of obtaining versions containing commit 2 and commit 1 locally using the Git shallow bundle method in this embodiment of the disclosure. As can be seen from the diagrams in lines 6 and 7, the Git shallow bundle method in this embodiment of the disclosure can directly obtain file information and / or version information of a specified version without having to backtrack from the latest commit information of the branch one by one, which can greatly reduce unnecessary backtracking and reduce waste of resources. At the same time, the version of the specified commit information (commit 2 and / or commit 1) can be used locally, without needing the version of the specified commit information (commit 2 and / or commit 1) in the local repository.

[0081] In one alternative implementation, such as Figure 3 As shown, archiving at least one of the specified version's file information and version information includes the following steps S301-S303:

[0082] S301, Add initial information of the second type to the first archived file formed from the file information of the specified version.

[0083] The second type of initial information includes formatted information for archiving file and version information, such as information in bundle format.

[0084] In one example, the first file to be archived can be a .pack file, which contains file information for a specified version. The second type of initial information can be bundle format information, which can be included in the header of the .pack file.

[0085] S302, if a specified version has specified commit information, add the specified commit information of the specified version to the second archive file that supports the shallow clone protocol of Git.

[0086] In one example, the second file to be archived can be a .git / shallow file, which is a file named shallow in the .git directory of the remote Git repository. This file supports Git's shallow clone protocol, such as SHA1 (Secure Hash Algorithm 1) hash value, MD5 (Message-Digest Algorithm 5) hash value, etc., or other types of key information, which will not be listed one by one in this disclosure embodiment.

[0087] In one example, the SHA1 hash value (as a specified commit message) can be written to the .git / shallow file, allowing the locally restored Git repository to have no parent commit for the root node of the local repository, even if it only has one or more specified commit messages.

[0088] S303, archive the first and second files to be archived after adding information.

[0089] Optionally, the above steps S301-S303 can be implemented by the archiving task processing service. The archiving task processing service can perform archiving through the above steps S301-S303 and send the obtained archive package to the next service, such as the archive storage and distribution service.

[0090] The archive package obtained after archiving in the above manner can be transmitted to the recipient via file transfer methods such as network transmission and storage media transmission. The recipient can then restore it locally as a local shallow clone version file containing specified commit information (which can be composed of any number of commit information required by the user).

[0091] In one optional implementation, the information processing method provided in this disclosure further includes:

[0092] In response to an archive access request sent by a client, an archive access address is generated based on the storage address of the archive requested in the third-party storage system; the archive access address is then sent back to the client.

[0093] Optionally, the archive access request sent by the client carries specified commit information, which specifies one or more versions of the archive, and the archive of one or more versions is the archive requested to be accessed by the archive access request.

[0094] The aforementioned method of generating and responding to archive package access requests based on client-side requests can be implemented by an archive storage and distribution service. After generating the archive package access address using this method, the archive storage and distribution service sends the access address back to the client. The client can then use this access address to download the corresponding archive package from the third-party storage system. The third-party storage system can then send the corresponding archive package to the client via CDN to improve the speed and success rate of users reading the archive package.

[0095] The archive package access address in this embodiment can be a temporary access address or a permanent access address. When the archive package access address is a temporary access address, the validity period of the access address can be set according to actual needs.

[0096] Based on the above method, users can obtain archive packages stored in a third-party storage system through the archive package access address, and obtain the corresponding version file information and / or version information without relying on a remote repository for read and write operations to obtain the version file information and / or version information. This can reduce the read and write pressure on the remote repository and improve read and write performance and efficiency.

[0097] In one optional implementation, the process of generating an archive access address in response to an archive access request sent by a client specifically includes:

[0098] The system performs authorization authentication on archive package access requests. If the authorization authentication is successful, the system sends the storage address of the requested archive package in the third-party storage system to the client, thus generating the archive package access address.

[0099] The operation of authenticating access requests to archive packages can be implemented through authentication and auditing services, or through other services. The corresponding services can be set according to the actual situation, and the embodiments disclosed herein do not limit this.

[0100] Optionally, the archive access request sent by the client carries user information, which can be used to implement authorization authentication for the archive access request.

[0101] In one example, after receiving an archive package access request from a client, the archive storage and distribution service forwards the request to the authentication and auditing service. The authentication and auditing service verifies whether the user information carried in the archive package access request has the permission to access the archive package in the third-party storage system, and whether that permission is consistent with the permission to access the version in the remote repository. If the user information carried in the archive package access request has the permission to access the archive package in the third-party storage system and that the permission is consistent with the permission to access the version in the remote repository, then the permission authentication for the archive package access request is successful; otherwise, the permission authentication for the archive package access request fails.

[0102] Optionally, if authentication for an access request to an archive package fails, a failure message can be sent to the client. In one example, if authentication for an access request to an archive package fails, the authentication and auditing service sends a failure message to the archive storage and distribution service, which then sends the failure message to the client. In another example, after each authentication is completed, the authentication and auditing service can store a record of that authentication for later use.

[0103] Based on the above implementation methods, the technical solution of this disclosure can perform permission control on the client's archive package access request, ensuring that the sending user has access rights to the archive package in the third-party storage system, thereby improving access security; at the same time, it can also ensure that the user's access rights to the archive package in the third-party storage system are consistent with the access rights to the version in the remote repository, thereby improving the effectiveness of access.

[0104] The authentication and auditing services in this embodiment can be bypassed, decoupling the read / write and access control of archive packages. This allows for low-cost integration into various Git hosting services without altering the original access control architecture, demonstrating high practicality and compatibility. Even if the authentication and auditing services fail, user read requests will not be affected, thus improving the stability of user read operations.

[0105] In one optional implementation, authentication of archive access requests includes:

[0106] Access requests to archive packages are authenticated using any one of the multiple valid authentication channels.

[0107] In one example, authentication and auditing services can be set up in multiple data centers or network segments. Each data center or network segment's authentication and auditing service serves as an authorization channel. When the authentication and auditing service in a certain data center or network segment fails (i.e., the authorization channel becomes invalid), the authorization traffic can be quickly switched to the authentication and auditing services in other data centers or network segments that have not failed (i.e., the authorization channel is valid).

[0108] Based on the above implementation method, setting up multiple permission authentication channels helps with disaster recovery switching. When a permission authentication channel fails, it can quickly switch to other valid permission authentication channels, which can improve the stability of permission authentication and prevent the failure of a certain permission authentication channel from interrupting permission authentication, thereby ensuring that the user's normal read requests are not affected.

[0109] Figure 4 The diagram illustrates the information processing method provided in this disclosure implemented through various services. See below for reference. Figure 4 An example of the information processing method provided in this disclosure is presented.

[0110] Reference Figure 4 As shown in the example, the information processing method provided in this disclosure can be implemented through services such as archiving task building service, archiving task processing service, archiving storage and distribution service, authentication and auditing service, and specifically involves the following processes;

[0111] When the file information of the software version changes on the local client, the client sends the change to the remote Git repository via Git write operations.

[0112] When the archive task building service determines the version specified by the archive command sent by the client or the version that has changed in the remote Git repository, it obtains the basic information of the specified version (the version specified by the archive command or the version that has changed in the remote Git repository), creates an archive task based on the basic information, and sends the created archive task to the archive task processing service.

[0113] The archiving task processing service obtains at least one piece of information from one or more specified versions of file information and version information based on the archiving task. Specifically, for archiving tasks based on the first type, it can obtain file information of a specified version; for archiving tasks based on the second type, it obtains both file information of a specified version and version information. It packages at least one piece of information from each specified version of file information and version information to generate a corresponding binary file. It uses this binary file as an archive package or uses the binary compressed file obtained by compressing the binary file as an archive package, creates an archive package upload task, and sends the archive package and the archive package upload task to the archiving storage and distribution service.

[0114] The archive storage and distribution service writes archive packages to a third-party storage system for storage based on the archive package upload task.

[0115] When a user needs to access an archive package from a third-party storage system, they send an archive package access request (Git read operation) through the client. The archive storage and distribution service forwards this access request to the authentication and auditing service. The authentication and auditing service performs authorization authentication on the archive package access request and sends the authentication result back to the archive storage and distribution service. The archive storage and distribution service then sends the authentication result back to the client. If authorization authentication is successful, the returned authentication result includes the archive package access address. If authorization authentication fails, the returned authentication result may include the reason for the failure and suggestions for re-authentication. Figure 4 The example shown only illustrates the archive access address provided when authentication is successful.

[0116] The client reads the corresponding archive package from the third-party storage system via the archive package access address.

[0117] Figure 4 The process described above can be processed asynchronously with the remote Git repository to reduce the impact of the process on the read and write performance of the remote Git repository.

[0118] exist Figure 4 In Git, client-side read and write requests can be implemented through client extensions. These extensions primarily encapsulate build, download, and restore requests, reducing the learning and usage costs for users. When applied to Git hosting services, the client extension becomes a Git client extension. When a user executes a Git clone or fetch / pull command, the extension first converts the command information into a request to retrieve the archive package (i.e., an archive package access request). After completing authentication and receiving the archive package access address, the Git client extension downloads the archive package based on that address. If the download is successful, the archive package is decompressed and restored to the native local Git repository, and the workspace is checked out. If the download fails, it automatically redirects to the native Git client to execute the native Git clone or fetch / pull command. This approach makes client usage more convenient and transparent.

[0119] According to embodiments of this disclosure, this disclosure also provides an information processing apparatus, such as... Figure 5 As shown, the device includes: an information acquisition module 501, an archiving module 502, and an archive package storage module 503.

[0120] The information acquisition module 501 is used to acquire at least one of the following information from the remote repository: file information and version information for a specified version.

[0121] The archiving module 502 is used to archive at least one of the file information and version information of a specified version to obtain an archive package of the specified version. The archive package of the specified version is of type 1 or type 2. The archive package of type 1 carries the file information of the specified version, and the archive package of type 2 carries both the file information and version information of the specified version.

[0122] Archive package storage module 503 sends a specified version of the archive package to a third-party storage system; the third-party storage system is used to store the archive package.

[0123] In one alternative implementation, the second type supports shallow cloning protocols for distributed version control systems.

[0124] In one optional implementation, the information acquisition module 501 is specifically used to: when there is a version change in the remote repository, acquire at least one of the file information and version information of the changed version as at least one of the file information and version information of the specified version; or, in response to an archive command sent by the client, acquire at least one of the file information and version information of the version in the remote repository specified by the archive command as at least one of the file information and version information of the specified version.

[0125] In one optional implementation, the archiving module 502 is specifically used to: add second type of initial information to a first file to be archived formed from file information of a specified version; add specified commit information of a specified version to a second file to be archived that supports the shallow cloning protocol when the specified version has specified commit information; and archive the first and second files to be archived after adding the information; wherein the second type of initial information includes format information for archiving file information and version information.

[0126] In one optional implementation, the information processing apparatus provided in this disclosure further includes an address generation module and an address feedback module.

[0127] The address generation module is used to respond to the archive package access request sent by the client and generate the archive package access address based on the storage address of the archive package requested in the third-party storage system.

[0128] The address feedback module is used to provide the client with the access address of the archive package.

[0129] In one alternative implementation, such as Figure 6 As shown, the address generation module includes: an authentication unit 601 and an address generation unit 602.

[0130] The authorization authentication unit 601 is used to authenticate access requests for archive packages.

[0131] Address generation unit 602 is used to send the storage address of the archive package requested by the archive package access request in the third-party storage system to the client, and generate the archive package access address, when the authorization authentication of the archive package access request is passed.

[0132] In one optional implementation, the authorization authentication unit 601 is specifically used to: authenticate the archive package access request through any one of the multiple authorization authentication channels.

[0133] The functions of each unit or module in the apparatus of this disclosure embodiment can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here.

[0134] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0135] According to embodiments of this disclosure, this disclosure also provides an electronic device, a non-transitory computer-readable storage medium, and a computer program product.

[0136] The electronic device provided in this disclosure includes: at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to perform any of the information processing methods provided in this disclosure.

[0137] The non-transitory computer-readable storage medium provided in this disclosure embodiment stores computer instructions thereon, which are used to cause the computer to execute any of the information processing methods provided in this disclosure embodiment.

[0138] The computer program product provided in this disclosure includes a computer program that, when executed by a processor, implements any of the information processing methods provided in this disclosure.

[0139] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0140] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded into random access memory (RAM) 703 from storage unit 708. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0141] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0142] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as information processing methods. For example, in some embodiments, the information processing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the information processing method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform information processing methods by any other suitable means (e.g., by means of firmware).

[0143] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0144] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0145] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0146] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0147] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0148] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0149] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0150] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.< / date> < / depth> < / date> < / depth> < / depth>

Claims

1. An information processing method, comprising: Retrieves file information and version information for a specified version from a remote repository; The file information and version information of the specified version are archived to obtain the archive package of the specified version; the archive package of the specified version is of type second type, and the archive package of type second type carries the file information and version information of the specified version; wherein, the second type supports the shallow cloning protocol of the distributed version control system; Sending the specified version of the archive package to a third-party storage system; the third-party storage system is used to store the archive package; the archiving of the specified version's file information and version information includes: Add the second type of initial information to the first archive file formed from the specified version of the file information; the second type of initial information includes format information for archiving the file information and version information; If the specified version has specified commit information, add the specified commit information of the specified version to the second archive file that supports the shallow clone protocol; Archive the first and second files to be archived after adding the information.

2. The information processing method according to claim 1, wherein, The process of obtaining file information and version information of a specified version from a remote repository includes: If a version change occurs in the remote repository, the file information and version information of the changed version are retrieved and used as the file information and version information of the specified version. Alternatively, in response to an archive command sent by the client, the file information and version information of the version specified in the remote repository can be retrieved as the specified version.

3. The information processing method according to claim 1 further includes: In response to an archive package access request sent by a client, an archive package access address is generated based on the storage address of the archive package requested in the third-party storage system. The archive package access address is fed back to the client.

4. The information processing method according to claim 3, wherein, The step of generating an archive package access address based on the storage address of the archive package requested in the third-party storage system includes: Perform permission authentication on the access request for the archive package; If the authorization for the archive package access request is successful, the storage address of the archive package requested by the archive package access request in the third-party storage system is sent to the client, thereby generating the archive package access address.

5. The information processing method according to claim 4, wherein, The authentication of access requests to the archive package includes: The access request to the archive package is authenticated by using any one of the multiple valid authentication channels.

6. An information processing apparatus, comprising: The information acquisition module is used to acquire file information and version information of a specified version in a remote repository; An archiving module is used to archive the file information and version information of the specified version to obtain an archive package of the specified version; the archive package of the specified version is of type second type, and the archive package of type second type carries the file information and version information of the specified version; wherein, the second type supports the shallow cloning protocol of the distributed version control system; An archive storage module sends the specified version of the archive package to a third-party storage system; the third-party storage system is used to store the archive package; the archive module is specifically used for: Add the second type of initial information to the first archive file formed by the file information of the specified version; if the specified version has specified commit information, add the specified commit information of the specified version to the second archive file that supports the shallow clone protocol; archive the first archive file and the second archive file after adding the information; The second type of initial information includes format information for archiving file information and version information.

7. The information processing apparatus according to claim 6, wherein, The information acquisition module is specifically used for: If a version change occurs in the remote repository, the file information and version information of the changed version are obtained as the file information and version information of the specified version; or, in response to an archive command sent by the client, the file information and version information of the version in the remote repository specified by the archive command are obtained as the file information and version information of the specified version.

8. The information processing apparatus according to claim 6, further comprising: The address generation module is used to respond to the archive package access request sent by the client and generate an archive package access address according to the storage address of the archive package requested to be accessed in the third-party storage system. The address feedback module is used to provide the client with the access address of the archive package.

9. The information processing apparatus according to claim 8, wherein, The address generation module includes: The authorization authentication unit is used to authenticate the access request for the archive package; The address generation unit is used to send the storage address of the archive package requested by the archive package access request in the third-party storage system to the client when the authorization authentication of the archive package access request is successful, and generate the archive package access address.

10. The information processing apparatus according to claim 9, wherein, The authorization authentication unit is specifically used for: The access request to the archive package is authenticated by using any one of the multiple valid authentication channels.

11. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the information processing method according to any one of claims 1-5.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the information processing method according to any one of claims 1-5.

13. A computer program product comprising a computer program that, when executed by a processor, implements the information processing method according to any one of claims 1-5.