we are migrating from self hosted gitlab to gitlab.com subscription. We have parent 28 group and under these groups there are multiple subgroups and projects.
I know I can export one group and it will export all the subgroups under it and then I can import it.
but documentation says to export/import single project at a time. I have almost 3000+ Projects and doing this things 3000+ time is not possible.
Can you please suggest me How can I export/import all the projects under a group regardless it is in a group or under someother subgroup in hierarchy ?
or is there any other way ?
You will need to write scripts that interact with the GitLab API to perform the migration of groups/orgs, projects, branches, and merge requests. See the following post on GitLab's forum for guidance.
Related
There is an unstable gitlab server and I am not sure that it will be able to work in the future. Therefore, I want to make a backup copy of all the repositories (projects) that are there.
Cloning the source code will be enough, but it will be great if there is a way to save issues as well. Are there any ways to do this?
It depends on what kind of access you have, but if you don't have administrator access to do a full backup, then the best thing to do is to use a couple of API endpoints to get the information you need and go from there.
Use the Projects API to get a list of all projects accessible to you.
Note the pagination limits.
What you store depends on how you want to get the information.
Store at least the ID number of each.
Filter by membership if you only want the ones you're a member of.
Filter by min_access_level = maintainer (or higher) if you want to export whole projects.
Use the Project export API to trigger a project export for each project you're a member of, and you're a maintainer (or higher).
For all other projects where you have a lower role, or where it's public, you could still use git clone for the repositories by storing the ssh_url_to_repo or http_url_to_repo from the Projects API and running through each.
For all other parts of a project, you could store the JSON version to recreate them later if you want to go through the hassle. For example, for issues, use the Issues API.
When I select all projects, I cannot search by commits or code.
Can I enable search by code or commits across all projects?
You can only do this across an entire instance for self-managed GitLab instances OR searching across repositories within a single organization/group in GitLab.com
For example, you can search across all of the gitlab-org group or any other group/namespace you have access to.
Currently, GitLab has not enabled global code search on gitlab.com. However, self-hosted GitLab Premium and Ultimate customers can leverage the advanced search feature and enable global code search for a self-managed instance with Elasticsearch.
That might be because a true global code search does not seem to be implemented yet, as illustrated by issue 556 or issue 14597.
Which is why there are alternatives like phillipj/gitlab-search (but only to search for contents across all your GitLab repositories)
I am setting up a on premises instance of Azure DevOps 2019 and have read over the guide for planning the organizational structure. In our situation, having a single organization and several projects and teams seems to be the most appropriate structure.
The question I have is in a situation where people have small utility programs they have written to help with their day to day tasks, where should I have them have place their code. In this situation, it may not pertain to a certain project and I feel like creating projects for every individual user that wants their own little playground to put code would be messy.
Is there a way I can have a project where users can have their own little area of repositories for their use and not see all other people's repositories in that project and therefore not look so cluttered?
Is there some better way to give users their own area to have repositories for their own use without cluttering up projects?
You can create a new project to place the repositories of the developers.
You change the repositories permission settings to achieve users can only view their own little area of repositories for their use and not see all other people's repositories in that project. See below:
1, Set the permission on All Repositories Level
Go to project settings of the project--> Repositories under Repos-->Permissions under All Repositories-->Search for the users in the search bar-->Change his permission to Not set or Deny
By denying this user's permission on the All repositories level, so that he willnot be able to see other people's repositories in that project
2, Set the permission on Single Repository Level
Go to project settings of the project--> Repositories under Repos-->Select the repository of this user-->Permissions tab-->Search for the user in the search box-->Set the permission to allow for the user his own repository(override the permission set on above All Repositories level).
By doing above two steps. Users will only be able to view their own repositories on the project portal.
I agree common code or small utilities should reside separately apart from project code base. You can make a new project like CommonScripts or any name then the user can create a separate repository and maintain there own code or utility.
Advantage of doing that other person or multiple project can access that common piece of library in pipeline if required without doing code redundancy.
As an example in our organization we have project name called DevOps then we have separate repositories accordingly.
I want to understand the difference between projects and subgroups in GitLab.
Please help me on understanding the above.
Project
A project manages one git repository and adds an issue tracker, a wiki, etc:
See: https://docs.gitlab.com/ee/user/project/index.html#doc-nav
Groups
Groups can be used to combine several projects under one topic. Examples:
You could put all your JavaScript projects in a group called "js"
You could create one group for each of your developer teams; then if somebody new joins a team, you can just add them to the group instead of having to grant developer access for every project.
Groups can be referred in issues or commit discussions.
See: https://docs.gitlab.com/ee/user/group/index.html#doc-nav
Different groups may have different permissions
Subgroups
Subgroups are only available in GitLab 9 and above; they allow you to create additional groups inside of groups, e.g. "js/frontend"; this is useful if you are working on a large project with several sub-projects. See the official documentation for some examples:
https://docs.gitlab.com/ee/user/group/subgroups/index.html
How to transfer the repository or a whole set of repositories from one gitlab group to another subgroup. For example companyname.gitlab.com/team one/. To gitlab.com/team_first/phase1/
The repositories/projects themselves still need to be exported by API, one by one.
But the new "Group Import/Export " feature from GitLab 13.0 (May 2020) can be a welcome addition.
Export and Import Groups in the UI
Previously, users could only migrate groups by using the Export/Import API to create an Export file, then using the API a second time to upload the file to the target instance.
As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI.
We plan to introduce similar Import functionality to the UI within the next few weeks.
See documentation, issue and Epic.
See GitLab 14.2 (August 2021)
Group Migration achieves parity with group import/export
The new GitLab Migration feature can now migrate an entire group with all its subgroups and related data. The data migrated includes everything contained in group exports, making this a much easier way to migrate entire groups.
The pre-existing group import/export is a two-step process that requires exporting a file and then importing it into another GitLab instance.
Now, users can initiate a group migration with a single click. Migration also includes all the subgroups and their data, which previously required separate export and import processes for each subgroup.
See Documentation and Epic.
See GitLab 15.6 (November 2022)
Associate MRs to issues when migrating groups with projects
When migrating groups using GitLab Migration, GitLab now preserves associations of imported merge requests to issues.
This populates the Related merge requests section
on the issue details page.
See Documentation and Issue.