GitLab code repository permission hosting method and system for project management

Abstract

The present invention provides a GitLab code warehouse authority hosting method and system for project management, and the method includes: step S1: collecting authority configuration data, and updating data in real time; step S2: setting authority configuration rules, establishing a user authority control data model, and inputting the collected authority configuration data into the user authority control data model, and obtaining authority synchronization data; step S3: GitLab agent adaptation platform converts the authority synchronization data into unified authority data; step S4: deploying the authority data to all code warehouses corresponding to the project in the GitLab agent adaptation platform, and performing unified authority hosting management. The present invention converts various forms of authority control data into unified authority synchronization data, so as to realize GitLab code warehouse authority hosting, and ensure the data consistency, maintainability and scalability of project management authority control.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a GitLab code repository permission hosting method and system for project management, and in particular to a GitLab code repository permission hosting method and system based on project management. Background Art

[0002] In the actual operation of the project management platform, permission control is crucial, as it is directly related to the security of the system, the integrity of the data, and the efficiency of teamwork. However, traditional permission control methods usually adopt a decentralized management strategy, that is, setting up separate permission control data for different resources such as project roles, users, and organizational structures. This approach not only easily leads to data inconsistency problems, increases the complexity and maintenance costs of data updates, but also limits the scalability of the system, making it difficult to adapt to the rapid changes in project requirements.

[0003] A Chinese patent document with publication number CN111294379A discloses a blockchain network service platform and its authority trusteeship method and storage medium, the method comprising: when a trusteeship request is received, obtaining trusteeship information from the trusteeship request, the trusteeship information being used to characterize the authority of at least one entrusting node to trust itself to a proxy node; generating at least one proxy private key fragment on at least one entrusting node according to the trusteeship information, the at least one proxy private key fragment corresponding to at least one entrusting node one-to-one, the at least one proxy private key fragment being used to characterize the trusteeship authority of at least one entrusting node; generating a proxy signature on the proxy node according to the at least one proxy private key fragment; and when the proxy signature is judged to be valid on the signature verification node, trusting the authority of at least one entrusting node to the proxy node.

[0004] The permission management in the prior art requires hierarchical management, and each project needs to be signed before the next permission management can be carried out, which makes it impossible to achieve unified hosting management. Therefore, it is necessary to synchronize permissions between the project management platform and the GitLab code repository, and a GitLab code repository permission hosting method and system for project management is needed. Summary of the invention

[0005] In view of the defects in the prior art, the purpose of the present invention is to provide a GitLab code repository permission hosting method and system for project management.

[0006] A GitLab code repository permission hosting method for project management provided by the present invention includes:

[0007] Step S1: Collect permission configuration data and update the data in real time;

[0008] Step S2: By setting the permission configuration rules, a user permission control data model is established, and the collected permission configuration data is input into the user permission control data model to obtain permission synchronization data;

[0009] Step S3: The GitLab proxy adapter platform converts the permission synchronization data into unified permission data;

[0010] Step S4: Deploy the permission data to all code repositories corresponding to the project in the GitLab proxy adaptation platform for unified permission hosting management.

[0011] Preferably, the step S1 comprises:

[0012] Step S1.1: Collecting authority data of various types of organizational structures in the project, where the types of organizational structures include departments, roles, groups, and individuals;

[0013] Step S1.2: Collect permission matching data of the code repository corresponding to the project;

[0014] Step S1.3: Integrate the permission data and permission matching data to form permission configuration data, and merge the difference permission configuration data generated by the permission adjustment in the project in real time to update the permission configuration data.

[0015] Preferably, step S2 comprises:

[0016] Step S2.1: Setting permission configuration rules;

[0017] Step S2.2: Create a user authority control data model according to the authority configuration rules;

[0018] Step S2.3: Input the permission configuration data into the user permission control data model and convert it into permission synchronization data.

[0019] Preferably, step S2.1 comprises:

[0020] Step S2.1.1: Set the permission granting rules; specifically, the permissions granted individually have the highest priority;

[0021] Step S2.1.2: Set the organizational structure authority rules; specifically, when the organizational structures are different, grant the maximum authority range, and when the organizational structures are the same, grant the minimum authority range;

[0022] Each organizational structure corresponds to one or more permission processing.

[0023] Preferably, step S3 comprises:

[0024] Step S3.1: The GitLab proxy adapter platform verifies the received permission synchronization data and deletes the data with errors;

[0025] Step S3.2: Set the conversion relationship between the GitLab proxy adaptation platform and the user authority control data model;

[0026] Step S3.3: Parse the verified permission synchronization data and convert it into permission data suitable for the GitLab agent adaptation platform.

[0027] A GitLab code repository permission hosting system for project management provided by the present invention includes:

[0028] Collection module: used to collect and update permission configuration data in real time;

[0029] Model building module: used to build a user authority control data model, input the collected authority configuration data into the user authority control data model, and output authority synchronization data;

[0030] Conversion module: used to enable the GitLab agent adapter platform to convert permission synchronization data into unified permission data;

[0031] Hosting module: used to deploy permission data to all code repositories corresponding to the project in the GitLab proxy adaptation platform for unified permission hosting management.

[0032] Preferably, the acquisition module comprises:

[0033] Collection authority module: used to collect authority data of various types of organizational structures in the project, including departments, roles, groups, and individuals;

[0034] Collection permission matching module: used to collect permission matching data of the code repository corresponding to the project;

[0035] Integration module: used to integrate permission data and permission matching data to form permission configuration data, and update the permission configuration data in real time.

[0036] Preferably, the model building module comprises:

[0037] Setting rules module: setting permission configuration rules;

[0038] Creation module: used to create user authority control data model;

[0039] Output module: inputs permission configuration data into the user permission control data model and outputs permission synchronization data.

[0040] Preferably, the setting rule module includes:

[0041] Granting rules module: used to set the granting rules;

[0042] Organizational structure permission rule module: used to set organizational structure permission rules; specifically, when the organizational structure is different, the maximum permission range is granted, and when the organizational structure is the same, the minimum permission range is granted;

[0043] Each organizational structure corresponds to one or more permission processing.

[0044] Preferably, the conversion module comprises:

[0045] GitLab proxy module: used to convert the data output by different user permission control data models into unified data, and then match the data of the code repository, so that the code repository permissions are hosted on the GitLab proxy adaptation platform;

[0046] Verification module: used to verify the received permission synchronization data using the GitLab proxy adaptation platform;

[0047] Conversion relationship module: used to set the conversion relationship between the GitLab proxy adaptation platform and the user authority control data model;

[0048] Parsing module: used to parse the verified permission synchronization data and convert it into permission data suitable for the GitLab agent adaptation platform.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] 1. The user authority control data model proposed in the present invention supports the conversion of the authority configuration of various organizational structures or code repositories based on roles, users, etc. in project management into a unified authority data structure. The platform manager only needs to clarify the authority of the department and role of the platform user in the project management platform, without paying attention to the details of the GitLab platform controlling the authority of the code repository. The project management platform will use the authority control data model as the basis and convert and generate model data in combination with the platform's own authority configuration details. This ensures the consistency and accuracy of the authority data while reducing the business complexity of distinguishing and synchronizing various types of authority configurations;

[0051] 2. Based on the user authority control data model proposed in the present invention, the authority characteristics of the management tools are integrated, and extended attributes are reserved on this basis, so that the authority synchronization of other types of version control systems other than GitLab can be quickly adapted, so that the project management platform can freely expand other version control systems, ensuring the scalability and flexibility of the project management platform;

[0052] 3. The present invention converts various forms of permission control data into a unified permission synchronization data to realize GitLab code repository permission hosting and ensure the data consistency, maintainability and scalability of project management permission control;

[0053] 4. Based on the user authority control data model proposed by the present invention, the project management platform can realize the rapid association and authority management of multiple GitLab code repositories. By automatically deploying the code repository adapter, the project management platform can quickly horizontally expand the associated GitLab code repository platform, while ensuring that the authority configuration of all associated GitLab code repository platforms is completely consistent. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0055] Figure 1 A flowchart of the GitLab code repository permission hosting method for project management of the present invention;

[0056] Figure 2 Schematic diagram of the method flow of Example 1 of the present invention;

[0057] Figure 3 A schematic diagram of setting permission configuration rules according to Embodiment 1 of the present invention. DETAILED DESCRIPTION

[0058] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0059] The present invention can be used in a project management platform that integrates the GitLab code repository function to achieve model data conversion of the project's permission configuration and synchronize it to all GitLab code repositories hosted under the project. The present invention includes a unified user permission control model and a GitLab proxy adapter tool developed based on the model.

[0060] The present invention is used for synchronizing permissions between a project management platform and a GitLab code repository. In the project management platform, various forms of permission control data are involved, such as permission configuration data for various organizational structures such as roles and users in the project, and permission configuration data for the code repository. The present invention uses a user permission control data model based on project management, which can convert various forms of permission control data into a unified permission synchronization data, so as to realize GitLab code repository permission hosting and ensure the data consistency, maintainability and scalability of project management permission control.

[0061] A GitLab code repository permission hosting method for project management provided by the present invention includes:

[0062] Step S1: Collect permission configuration data and update the data in real time;

[0063] Step S2: By setting the permission configuration rules, a user permission control data model is established, and the collected permission configuration data is input into the user permission control data model to obtain permission synchronization data;

[0064] Step S3: The GitLab proxy adapter platform converts the permission synchronization data into unified permission data;

[0065] Step S4: Deploy the permission data to all code repositories corresponding to the project in the GitLab proxy adaptation platform for unified permission management. Different types of permission data can be managed by the GitLab proxy adaptation platform for unified permission management of different code repositories, that is, the GitLab proxy adaptation platform realizes the management of permissions for different types of projects.

[0066] Preferably, the step S1 comprises:

[0067] Step S1.1: Collecting authority data of various types of organizational structures in the project, where the types of organizational structures include departments, roles, groups, and individuals;

[0068] Step S1.2: Collect permission matching data of the code repository corresponding to the project;

[0069] Step S1.3: Integrate the permission data and permission matching data to form permission configuration data, and merge the difference permission configuration data generated by the permission adjustment in the project in real time to update the permission configuration data.

[0070] Preferably, step S2 comprises:

[0071] Step S2.1: Setting permission configuration rules;

[0072] Step S2.2: Create a user authority control data model according to the authority configuration rules;

[0073] Step S2.3: Input the permission configuration data into the user permission control data model and convert it into permission synchronization data.

[0074] Preferably, step S2.1 comprises:

[0075] Step S2.1.1: Set the permission granting rules; specifically, the permissions granted individually have the highest priority;

[0076] Step S2.1.2: Set the organizational structure authority rules; specifically, when the organizational structures are different, grant the maximum authority range, and when the organizational structures are the same, grant the minimum authority range;

[0077] Each organizational structure corresponds to one or more permission processing.

[0078] Preferably, step S3 comprises:

[0079] Step S3.1: The GitLab proxy adapter platform verifies the received permission synchronization data and deletes the data with errors;

[0080] Step S3.2: Set the conversion relationship between the GitLab proxy adaptation platform and the user authority control data model;

[0081] Step S3.3: Parse the verified permission synchronization data and convert it into permission data suitable for the GitLab agent adaptation platform.

[0082] Example 1

[0083] A GitLab code repository permission hosting method for project management, including:

[0084] Step 1: In the project in the project management platform, collect various permission configuration data of the project in the project management platform.

[0085] Step 2: Convert these permission configuration data into unified permission synchronization data according to the user permission control data model.

[0086] Step 2.1: Set the permission configuration rules and the relationship between the permission configuration rules.

[0087] The input parameters for creating the model include at least: user identity information, permission configuration rules for the user's identity in the platform or project, and the relationship between different identities or permission configuration rules;

[0088] Specific examples:

[0089] System configuration rules:

[0090] A1. The permissions granted to users individually have higher priority than the permissions on dimensions.

[0091] A2. For permissions in different dimensions (department / role / group / individual), handle them according to the maximum permission

[0092] A3. For permissions in the same dimension (department / role / group / individual), the minimum permissions are used.

[0093] Platform configuration rules:

[0094] B1. R&D department can access the development data of all projects

[0095] B2. The quality department can access the test data of all projects

[0096] Platform project 1 configuration rules:

[0097] C1. Developers can access and edit the development data of project 1

[0098] C2. Testers can access and edit the test data of project 1

[0099] C3. Reviewers can access development data and test data for designated projects

[0100] Assume that user A belongs to the R&D department, and the roles of user A in project 1 are defined as developer and reviewer. In addition, user A is given the permission of "access to test data of project 1". The general process of generating the permission model data of user A is as follows: Figure 3 .

[0101] The process sequence of system configuration rules is not fixed and can be added, deleted and adjusted in the project management platform.

[0102] Step 2.2: Create a user permission control data model based on permission configuration rules and permission configuration data;

[0103] Step 2.3: Convert unified permission synchronization data based on the user permission control data model.

[0104] The output model data includes user identity information, whether the user has access, read, write, manage, and authorize permissions to the code repository, and some extensible information.

[0105] For example, Zhang San's identities in the project management platform are "Developer" and "Configurator". "Developer" has the authority to read / list / preview / download / review projects, and "Configurator" has the authority to manage projects. The platform permission configurations of "Developer" and "Configurator" do not conflict with the code repository. In the basic permission details of the model data finally converted, Zhang San only has the ability to read and assign permissions to the code repository, but does not have other capabilities such as creation / modification / deletion.

[0106] Step 3: The platform sends the permission synchronization data to the GitLab proxy adapter tool developed based on the user permission control data model.

[0107] Step 4: The GitLab proxy adapter tool accepts the permission synchronization data transmitted by the platform and converts it into permission data suitable for the GitLab platform type.

[0108] Step 5: The GitLab proxy adapter tool applies the permission data to all GitLab code repositories hosted by the project.

[0109] Step 1: Collect multi-dimensional permission configuration data of the project in the project management platform, including department permissions, role permissions, group permissions, user permissions, and independent warehouse permissions in the project management platform. The permission configuration in the project management platform will be flexibly configured according to the actual scenario in production activities, and is often accompanied by complex relationships such as hierarchy and nesting, and is not directly applicable to code warehouse permission configuration;

[0110] For example, if user A belongs to the R&D department and his role in project 1 is developer, the following data will be obtained during the collection:

[0111] The R&D department has the following permissions: Access the development data of all projects

[0112] The developer's permissions are: access and edit the development of the specified project

[0113] Step 2: The collected permission configuration data is associated, compared, split, integrated, and calculated according to the permission rules for departments, roles, users, and other dimensions configured in the project management platform. Finally, it is converted into unified permission synchronization data applicable to the code warehouse based on the user permission control data model, taking the user as the unit. The permission synchronization data involves user identity information, as well as permission data such as whether the user can access, read, write, manage, and grant permissions to the code warehouse;

[0114] Taking user A as an example, the project management platform sets that the R&D department can access the development data of all projects, and project 1 sets that developers can access and edit the development data. The two are not in conflict. Then:

[0115] 1. Since it involves all projects and specific project 1, the permission target object needs to be split into two parts: the warehouse permissions of all projects and the warehouse permissions of project 1;

[0116] 2. Since the R&D department can access the development data of all projects, it is calculated that user A has access rights to all project code repositories;

[0117] 3. Since the developers of Project 1 can access and edit the development data of Project 1, it is calculated that User A has access and editing permissions to the code repository of Project 1, but only has access permissions to code repositories other than the code repository of Project 1.

[0118] Step S4: Since the GitLab platform uses the permission roles method, it is significantly different from the code repository permission data in the permission synchronization data, which is based on users. Therefore, after the GitLab proxy adapter receives the permission synchronization data transmitted by the platform, it also needs to convert it into the permission data of the GitLab platform using the permission roles according to the user's access, read, write, and management permissions of the code repository;

[0119] Here is a description of how to convert the data of the user permission control model into the permission role data of the GitLab platform. The GitLab platform does not configure permissions for each user individually, but presets multiple roles (including Guest / Reporter / Developer / Maintainer / Owner). Each role has different permissions. Permission control is completed by assigning roles to users.

[0120] The step 1 comprises:

[0121] Step 1.1: Collect permission configuration data for various organizational structures such as roles and users in the project.

[0122] Step 1.2: Collect permission configuration data for each code repository in the project.

[0123] Step 1.3: Sort out the complete permission configuration data, or the differential permission configuration data generated after the project performs real-time permission adjustments.

[0124] Described step 4 comprises the following steps:

[0125] Step 4.1: Verify the received permission synchronization data to ensure that the data is accurate.

[0126] Step S4.2: Set roles and permissions corresponding to roles in the user permission control model;

[0127] Step S4.3: Parse the permission synchronization data and convert it into permission data suitable for the GitLab platform type.

[0128] The present invention also provides a GitLab code repository permission hosting system for project management. The GitLab code repository permission hosting system for project management can be implemented by executing the process steps of the GitLab code repository permission hosting method for project management, that is, those skilled in the art can understand the GitLab code repository permission hosting method for project management as a preferred implementation mode of the GitLab code repository permission hosting system for project management.

[0129] A GitLab code repository permission hosting system for project management provided by the present invention includes:

[0130] Collection module: used to collect and update permission configuration data in real time; model building module: used to establish a user permission control data model, and input the collected permission configuration data into the user permission control data model, and output permission synchronization data; conversion module: used to enable the GitLab agent adaptation platform to convert the permission synchronization data into unified permission data; hosting module: used to deploy permission data to all code repositories corresponding to the project in the GitLab agent adaptation platform for unified permission hosting management.

[0131] Preferably, the collection module includes: a permission collection module: used to collect permission data of various types of organizational structures in the project, and the types of organizational structures include departments, roles, groups, and individuals; a permission collection matching module: used to collect permission matching data of the code repository corresponding to the project; an integration module: used to integrate permission data and permission matching data to form permission configuration data, and update the permission configuration data in real time.

[0132] Preferably, the model building module includes: a rule setting module: setting permission configuration rules; a creation module: used to create a user permission control data model; an output module: inputting permission configuration data into the user permission control data model and outputting permission synchronization data.

[0133] Preferably, the rule setting module includes: a granting rule module: used to set granting authority rules; an organizational structure authority rule module: used to set organizational structure authority rules; specifically, when the organizational structures are different, the maximum authority range is granted, and when the organizational structures are the same, the minimum authority range is granted; each organizational structure corresponds to one or more authority processing.

[0134] Preferably, the conversion module includes: a GitLab proxy module: used to convert the data output by different user permission control data models into unified data, and then match the data of the code repository, so that the code repository permissions are hosted on the GitLab proxy adaptation platform; a verification module: used to use the GitLab proxy adaptation platform to verify the received permission synchronization data; a conversion relationship module: used to set the conversion relationship between the GitLab proxy adaptation platform and the user permission control data model; a parsing module: used to parse the verified permission synchronization data and convert it into permission data suitable for the GitLab proxy adaptation platform.

[0135] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0136] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A GitLab code repository permission hosting method for project management, characterized in that: include: Step S1: Collect permission configuration data and update the data in real time; Step S2: By setting the permission configuration rules, a user permission control data model is established, and the collected permission configuration data is input into the user permission control data model to obtain permission synchronization data; Step S3: The GitLab proxy adapter platform converts the permission synchronization data into unified permission data; Step S4: Deploy the permission data to all code repositories corresponding to the project in the GitLab proxy adaptation platform for unified permission hosting management; The step S2 comprises: Step S2.1: Setting permission configuration rules; Step S2.2: Create a user authority control data model according to the authority configuration rules; Step S2.3: input the permission configuration data into the user permission control data model, and convert it into permission synchronization data; The step S2.1 comprises: Step S2.1.1: Set the permission granting rules; specifically, the permissions granted individually have the highest priority; Step S2.1.2: Set the organizational structure authority rules; specifically, when the organizational structures are different, grant the maximum authority range, and when the organizational structures are the same, grant the minimum authority range; Each organizational structure corresponds to one or more permission processes.

2. The GitLab code repository permission hosting method for project management according to claim 1, characterized in that: The step S1 comprises: Step S1.1: Collecting authority data of various types of organizational structures in the project, where the types of organizational structures include departments, roles, groups, and individuals; Step S1.2: Collect permission matching data of the code repository corresponding to the project; Step S1.3: Integrate the permission data and permission matching data to form permission configuration data, and merge the difference permission configuration data generated by the permission adjustment in the project in real time to update the permission configuration data.

3. The GitLab code repository permission hosting method for project management according to claim 1, characterized in that: The step S3 comprises: Step S3.1: The GitLab proxy adapter platform verifies the received permission synchronization data and deletes the data with errors; Step S3.2: Set the conversion relationship between the GitLab proxy adaptation platform and the user authority control data model; Step S3.3: Parse the verified permission synchronization data and convert it into permission data suitable for the GitLab agent adaptation platform.

4. A GitLab code repository permission hosting system for project management, characterized in that: include: Collection module: used to collect and update permission configuration data in real time; Model building module: used to build a user authority control data model, input the collected authority configuration data into the user authority control data model, and output authority synchronization data; Conversion module: used to enable the GitLab agent adapter platform to convert permission synchronization data into unified permission data; Hosting module: used to deploy permission data to all code repositories corresponding to the project in the GitLab proxy adaptation platform for unified permission hosting management; The model building module comprises: Setting rules module: setting permission configuration rules; Creation module: used to create user authority control data model; Output module: inputs permission configuration data into the user permission control data model and outputs permission synchronization data; The setting rule module includes: Granting rules module: used to set the granting rules; Organizational structure permission rule module: used to set organizational structure permission rules; specifically, when the organizational structure is different, the maximum permission range is granted, and when the organizational structure is the same, the minimum permission range is granted; Each organizational structure corresponds to one or more permission processes.

5. The GitLab code repository permission hosting system for project management according to claim 4, characterized in that: The acquisition module comprises: Collection authority module: used to collect authority data of various types of organizational structures in the project, including departments, roles, groups, and individuals; Collection permission matching module: used to collect permission matching data of the code repository corresponding to the project; Integration module: used to integrate permission data and permission matching data to form permission configuration data, and update the permission configuration data in real time.

6. The GitLab code repository permission hosting system for project management according to claim 4, characterized in that: The conversion module comprises: GitLab proxy module: used to convert the data output by different user permission control data models into unified data, and then match the data of the code repository, so that the code repository permissions are hosted on the GitLab proxy adaptation platform; Verification module: used to verify the received permission synchronization data using the GitLab proxy adaptation platform; Conversion relationship module: used to set the conversion relationship between the GitLab proxy adaptation platform and the user authority control data model; Parsing module: used to parse the verified permission synchronization data and convert it into permission data suitable for the GitLab agent adaptation platform.

Images