I've just created a brand new instance of Gitlab v.14.
I need to import all my projects (more than 100) from the old gitlab 11 to the new gitlab 14.
Do you have any suggestion or experience?
GitLab 14.x cannot import projects exported by GitLab 11.x (see version compatibility requirements.) Though you don't necessarily need to export your projects to import them to GitLab (as I'll suggest below).
Ideally, you should follow the upgrade path then migrate the two instances as a whole.
But if you must do this by creating a new GitLab instance without being on the same version, there might be a few ways to do this.
Group import
If you upgrade your original GitLab instance to at least version 13.7, you can use the group migration tool.
Project imports
If you can't upgrade your original instance, the easier way to import your projects is to have both instances running and import projects by URL. You don't need to export each project first.
Import automation
If you have GitLab Premium or Ultimate, you can use import automation.
Regarding projects, GitLab 15.0 (May 2022) allows for a more complete import
Migration support for project releases milestones
We continue to add support for more release metadata to GitLab migration.
In GitLab 15.0, we’ve added project releases milestone.
This metadata will help you migrate more of the release data without needing to manually copy over missing release attributes.
See Documentation and Issue.
That will apply to your next migration (from your current instance to a new GitLab 15 one).
GitLab 15.8 (January 2023) further improves the process:
Migrating GitLab projects by direct transfer Beta
Now, you can migrate group and project resources together when using direct transfer.
You can use direct transfers to migrate between GitLab instances or
within the same GitLab instance.
Migrating projects when migrating groups using direct transfer is a major
improvement from migrating groups and projects using file exports because:
You don’t need to manually export each project to a file and then import all those export files to a new location.
Now all projects
within a top-level group are migrated automatically, making your work more efficient.
When migrating from self-managed GitLab to GitLab.com, user associations (such as comment author) are not changed to the user who is importing the projects.
Migration using direct transfer maps users and their contributions correctly, provided a few conditions are met.
This feature is available on GitLab.com. You can migrate from a self-managed GitLab to GitLab.com right now!
To enable it on GitLab self-managed instances, see the linked documentation.
Learn more about migrating GitLab projects by direct transfer Beta and what’s coming next in our recent blog post.
See Documentation and Epic.
Related
Please suggest if someone has experience of migrating source code of 3-4 applications (including their dev, stage & production environment) from TFS to Azure Devops into Git repository & then build the CI/CD pipeline. We don't require work items or history to be migrated.
Can someone give high level steps & what would be approach for migration?
On premise TFS service is TFS 2013 & source code is to be migrated to Azure Devops services. Currently they are using TFVC. Also these are .net applications. One of the application is having around 9.5 GB of data to be migrated. Kindly advice the process and tools which could help with code migration.
Since you are working on TFVC, you need to use a third-party tool GIT-TFS.
The Git-TFS tool is a two-way bridge between Team Foundation Version Control and Git, and can be used to perform a migration. Git-TFS is appropriate if you want to attempt a migration with full history, more than the 180 days that the Import tool supports, or if you want to attempt a migration that includes multiple branches and merge relationships.
You simply need to go through the following five steps to migrate your TFCV repo to Git.
Step 1: Install git-tfs. There are multiple tools to migrate from
TFVC to Git. ...
Step 2: Export to local Git Repo. ...
Step 3: Cleanup New Git Repository. ...
Step 4: Create new Git Repo in TFS. ...
Step 5: Initial Commit to Git Repo.
More details please take a look at this blog-- Migrate From TFVC To Git – 5 Simple Steps
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.
I've read about GitLab's issue board feature (see links below), but it's not there on my instance. Under the 'Issues' page of a project, all I see are 'Issues,' 'Labels' and 'Milestones' -- nothing about Issue Boards. Why is this? Do source installations not have this feature?
My GitLab setup:
Community Edition
Created from source
Version 8.10
https://about.gitlab.com/solutions/issueboard/
https://www.youtube.com/watch?v=UWsJ8tkHAa8
Issue boards were introduced in Gitlab 8.11. Time to upgrade!
Notes:
Introduced in GitLab 8.11.
The Backlog column was replaced by the Add issues button in GitLab 8.17.
Note: with GitLab 13.5 (October 2020), you have pre-populated issue boards:
Automatically add To Do and Doing lists on new boards
In most cases, teams will be best served by keeping their workflows as simple as possible.
To encourage this and make the first experience with a board more efficient and approachable, creating a new board will now automatically pre-populate To Do and Doing lists so you can get straight to managing issues.
See Documentation and Issue.
I've been using gitlab on a private server for development. Unfortunately, requiring a dual core, 2GB RAM VPS purely for the purpose of holding git repos for a couple of people is not cost effective. I would like to migrate to the free gitlab hosted accounts.
Is there are way to transfer a repo and issues to gitlab hosted servers?
It depends on your Gitlab version. They added an import/export feature in 8.9. If you have a lower version you can update to the current version and export your data afterwards.
The following items will be exported:
Project and wiki repositories
Project uploads
Project configuration including web hooks and services
Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities
The following items will NOT be exported:
Build traces and artifacts
LFS objects
We are starting to use TFS2013 (we use svn still, but for a number of reasons we're putting new code on TFS).
I have a solution that contains a project with an EF database model and I would like to share it with a different solution (to be more specific: there is a client website solution and a separate one for backend).
On SVN I would have created svn externals - I would be able to share the code easily and if I branched, the shared project would have a nice copy on branch as well. Moreover, both projects would have the most up-to-date version of the db model, which suits me perfectly.
TFS 2013 seems to push be pushing towards NuGets. That means, that if I create a nuget package of the db project:
I will have to update the db projec separately each time there is a db change, release it and then update all projects that use it
If I branch, I'll probably have to create a different nuget package for the branched version and amend the nuget reference on merge
It pollutes the nuget repo with things that are not exactly worth a repository (in case of a DB model, you want to have the latest possible version because a website will probably break if you don't, no point for versioning so that the build doesn't break)
I spent some time trying to find a suitable solution, but the best idea I found is just referencing the project from a different solution - the problem with it is, I would have to make the root folder for the build be higher than just the solution and that would add several more projects that I don't need. Another idea is referencing by branching, which was good for TFS 2010 with multiple projects, but I can't fit it into my scenario (we have a single 'Main' node where we put all solutions).
So, how would you share a DB project on TFS 2013?