I'd like to migrate GitLab to GitHub. Of course, Git repo is easy to migrate. But other working items, such as Issue. Can I migrate all working items to GitHub Enterprise? If API is needed, please let me know the GitHub and GitLab APIs for the migration. If there is a tool, it is the best and helpful.
Best Regards,
I believe that is there a more efficient approach to solve this, but today we are trying Enterprise Edition and migrations projects individualy.
To export a full project, with Issues, MR history, ..., there is a section called Export Project.
Under project Settings > General > Export Project section with the following instructions:
Export this project with all its related data in order to move your
project to a new GitLab instance. Once the export is finished, you can
import the file from the "New Project" page.
Once the exported file is ready, you will receive a notification email
with a download link.
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:
Job traces and artifacts
LFS objects
Container registry images
CI variables
Any encrypted tokens
Now, I wanna learn if there is a global export for all projects.
Related
I have apex code stored in the master branch of my remote repository in GitHub and would like to deploy it directly into my Salesforce Org.
Is there a way to setup a "pipeline" in GitHub with Salesforce.com in order to facilitate a direct deployment into Salesforce?
Edited on 22nd-Oct-2022: is there a way to setup a button on GitHub that I can click on when I want to deploy changes (delta) from the master branch to a related Salesforce DEV Org?
Learn from Salesforce themselves. The https://github.com/trailheadapps/lwc-recipes (all lwc demos mentioned in documentation) contains actions to run code quality tools (prettier, lint), unit tests (apex, jest), deploy to scratch org, assign permission set, run all tests, delete the scratch org, report on code coverage...
Lots of goodies there. Might be too much if you're just after plain deploy to prod but it's good to know what toys are out there.
I have an existing project that uses project boards on GitHub. I want to move all issues (open and closed) to projects (beta) on GitHub. Is there a way to do that automatically? Right now, I only know how to add issues manually to projects (beta).
As far as I know, there is currently no official guide on how to migrate to GitHub Projects (beta). You might want to follow this discussion on the topic: https://github.com/github/feedback/discussions/6141
However, I created a tutorial on how to migrate from the legacy project boards to the new projects (beta) myself: https://github.com/galargh/projects-migration#how-to-migrate-from-github-projects-to-github-projects-beta
It describes how to migrate cards (including column names) by either running a GitHub Actions workflow or a bash script.
Unfortunately, it does require some manual steps because projects (beta) API is not complete yet - the project itself and the Status field options have to be created manually to be precise.
After the migration, I'm also heavily using this action I created https://github.com/protocol/github-api-action-library/tree/master/add-project-items-by-content-query. I use it to periodically populate my projects based on content search queries (e.g. I automated adding all the issues that mention me - https://github.com/galargh/.github/blob/684c316/.github/workflows/add-project-items.yml).
I implemented python script that helps you migrate your project (similar to #galargh's solution) which uses the GraphQL api for the old projects too (might be more future proof) and also allows you to map column names and migrate PRs.
https://github.com/doidor/gh-projects-migration
You can now do this by enabling the Project migration feature in feature preview
Once you enable it you should see a Start migration button when you go to your Classic (not beta) Project Board
Here are the official docs on how to do it
We are using TFS 2015 On Premise, not in the cloud and I am trying to give access to Stakeholders so they can access the wiki. However, as a stakeholder I keep getting this error:
TF400409: You do not have licensing rights to access this feature: Code
After researching the error it seems to be related to the fact that Stakeholders do not have access to view Code Wikis as shown here. That link is for Azure DevOps and I am not sure if it applies to my case but I cannot find anything else so my assumption is it does apply. Even links within our TFS site, takes us to Azure DevOps for help and thus my assumption is it applies to us as well.
Here is a screenshot from the aforementioned link:
Question
What is the difference between Code Wikis and Project Wikis? It seems I need Project Wikis but how do I create a Project Wiki?
Thanks in advance!
Code Wiki are not available on TFS server 2015. You need to use version TFS 2018 or above for this.
Project Wiki
Every team project can have a wiki. Use the wiki to share information
with your team to understand and contribute to your project.
Each team project wiki is powered by a Git repository in the back-end.
When you create a team project, a Wiki Git repo is not created by
default. Provision a Git repository to store your wiki Markdown files,
or publish existing Markdown files from a Git repository to a wiki.
In the project page, you could directly choose to create project wiki.
Code Wiki
Content that you already maintain in a Git repository can be published to a wiki. For example, this could be content written to
support a software development kit (SDK), product documentation, or
README file. You can publish multiple wikis within a single team
project.
More details about the difference of them, kindly refer our official doc here:
Provisioned wikis vs. published code as a wiki
As how to use them in Azure DevOps/TFS, you could also take a look at this step by step tutorial -- Collaborating using Azure DevOps Wiki
I am planning to soon migrate a couple of Collections from a on premises TFS 2017 server to a on premises Azure DevOps 2019 server. These collections have multiple Git repos, no older VSTS style code repos.
I've found all sorts of good documents covering how to migrate the collection- and I am able to do that with ease. I took snapshots of my old and new servers and did a temporary test move over a weekend, everything came up just fine. I then reverted to the snapshots.
Does anyone know of a good document or URL for me to provide as instructions to my 20+ developers for them to reconfigure their Team Explorer in Visual Studio? The Collections on the old server will be detached, so there's no need for them to continue to have the old server configured. I don't want anyone to have to completely switch to the new server in a way where they lose any git branches that they only have local (not pushed up to the server.)
I myself only use TortoiseGit to interact with the git repos. I can see in my git repos, I go to the .git folder and change the URL in the file named "config" and the repo is switched over painlessly.
Almost all of the devs only use Team Explorer. If anyone knows of a good guide that I can walk them through with to make the switch from within Team Explorer instead of having to edit text files and registry keys, I appreciate it.
Thanks!
If I understand you correctly, you are looking for guides to connect your devs' Team Explorer in Visual Studio to the projects in the new on premises Azure DevOps 2019 server.
You can check the documents provided in Microsoft site Connect from Visual Studio or Team Explorer.
For more detailed steps you can check out this thread.
You can ask your devs to follow the steps in above thread to add the URL of the new server to Team Explorer. Then they can switch to code repo of new server.
I have got a project in an old org (from VSTS), that I want to move to my new one.
I can't see any options in Azure DevOps on migrating projects, or any information on the interwebs.
Anyone know how to do it?
If you just need to move repos, you can use the built in clone functions:
Go to the Azure Devops source repo -> Files
Click "Clone"
Choose "Generate Git Credentials"
Create the target repo in the target Azure DevOps
Choose "Import a repository"
Use the URL and credentials from Step 3
Done
This is not supported today. But this feature was planned to develop: make it possible to move a Team Project between Team Project Collections
If your Azure Devops project only tracks code versions using a single Git repo, hence no boards, user stories, tasks, pipelines, etc. then you can do the following:
Clone your project repo.
For example with Visual Studio.
You don't need to clone if you already have a local repo.
Destroy the association with the remote.
For this typically, you need to open a command line prompt in the folder that contains the .git database folder, most likely the solution folder of Visual Studio and type git remote rm origin.
Here is an example using git bash showing the content of the solution folder, including the .git database and the *.sln Visual Studio solution file:
Open the solution with Visual Studio if not already done.
It should now show that you have many commits waiting to be pushed to a remote. For illustration purpose, my toy project only have 8 commits in total.
Click the up arrow and choose your new remote, say a brand new Azure DevOps project, in the organization of your choice, then push.
You are now done cloning the project in another organization. If needed, then destroy the project in the old organization to complete the "move" operation.
There are 3 projects that I know of to achieve this.
A paid for option by Ops Hub -
OpsHub Visual Studio Migration Utility
An open source tool that requires making changes to the work item process template - Azure DevOps Migration tools
An lastly an Unofficial but still written by Microsoft tool to create Azure DevOps project templates - Azure DevOps Demo Generator & extractor tool
With the last one (the Demo Generator) you extract the project as a template, then apply it to the new organisation. As it is a tool for demo's there is no support provided and in my experience it works for simple projects but falls over on anything complex.
Expanding on others' answers, this post regards Pipelines.
Azure DevOps API
Migrating nearly all aspects of a project across organizations is doable, but it is a lot of manual work using the Azure DevOps API. The link below shows you all the end points, variables, etc. From there you'll probably want to write a Power Shell script and do a couple test runs to a dummy Organization.
https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-6.1&viewFallbackFrom=azure-devops-rest-6.0
In App options
If you avoid the API, there is no way to migrate pipelines that preserve build or release history, but you can preserve your configurations and processes by going into your Pipelines and selecting View YAML. From here you can either take this away as notes to recreate the GUI steps in your new org/project location, or actually adopt the YAML standard in your git repository.
I do not believe there is a way to migrate pipeline variables outside of the API. However, you can move the variables to Azure Key Vault and change your pipeline settings (YAML) to reference values from key vault. This is not a large amount of effort and is a nice process improvement.
Lastly, if you have any locally installed pipeline agents for releases, you will need to run the Power Shell script for your new organization on the boxes. Very simple 5m step, but right now the Agent Pools are not sharable across organization.
As #Frederic mentioned in his answer, we can actually easily do it with Visual Studio. I have done this without Visual Studio. The steps involved are below.
Add a User to Both Organization
Configure SSH Key
Update the SSH Key in Source DevOps and Clone the Repository
Check out all the Branches and Tags
Update the SSH Key in the Destination DevOps
Remove Old and Add New Origin
Push all the branches
The commands and detailed explanations can be found here.
BTW, if you need to change the entire Devops Organization tied to your personal Tenant (E.g. VS Enterprise Subscription) and move it to new Tenant, you can change the AAD and point it to the new one e.g. your EA Tenant on Azure commercial cloud.
Before you switch your organization directory, make sure the following statements are true:
You're in the Project Collection Administrator group for the
organization.
You're a member or a guest in the source Azure AD and a
member in the destination Azure AD
You have 100 or fewer users in
your source organization. Otherwise you will have to open a support ticket.
You may have to add the users back in destination org if they do not exist becuase they will loose access the moment you switch the AAD.
you could just download as a zip file and then download it to the destination repo