Is there a way to migrate JIRA issues to GitLab EE starter?
We have two projects each having 1 board on JIRA that I would like to migrate.
After emailing the GitLab team, this feature is in the Roadmap and is "scheduled for release in 3-6 months" as of June 15, 2017.
And 3 to 6 months later indeed, in April 2020, for GitLab 12.10:
(I mean, talk about "six to eight weeks"!)
Import Issues from Jira to GitLab
Until now, the only way to get Jira issues into GitLab was manually, with our CSV importer, or by hand-rolling your own migration utility.
GitLab 12.10 includes an MVC to automatically import your Jira issues into GitLab. This is the first of many planned enhancements to make transitioning from Jira to GitLab as frictionless as possible.
To get started, set up the Jira integration on your GitLab project, click the import icon at the top of your project’s Issue List, and select Import From Jira.
See documentation and Epic.
Note that, with GitLab 13.2 (July 2020), you now have:
Map Jira users to GitLab users when importing issues
When importing issues from Jira to GitLab, you can now map Jira users to GitLab project members prior to running the import.
This enables the importer to set the correct reporter and assignee on the issues you’re moving to GitLab.
See Documentation and Issue.
After emailing the GitLab team, this feature is in the Roadmap and is "scheduled for release in 3-6 months" as of June 15, 2017.
In the meantime, you can use the script that #M. Awais mentioned in the comments.
Related
How to migrate a TFVC project from TFS to AZDO ?
Goal:
Is to migrate host projects on (TFS 2017) using TFVC, to switch them to Azure DevOps Service (AZDO) using TFVC there too.
My context:
TFS 2017 server version 2 hosting current source projects.
AZDO 2019 service wanting to host projects targeted on TFS.
Context wish:
Keep the history of source projects (TFS) on AZDO services.
I Just want to migrated the projects (TFS) in TFVC to (AZDO) in TFVC, without doing any TFVC -> GIT conversion.
I would like to avoid updating the TFS 2017 server for 2018 then to
the AZDO server to switch to AZDO services afterwards.
You understand
that is a lot of step to just want to switch a project in TFVC on
TFS2017 to a TFVC on AZDO
The easiest way to migrate is to upgrade your TFS2017 server to Azure Devops Server 2019 and then using the full fidelity import feature to upload your whole database backup to Azure Devops Service.
At the moment migration tools support TFS2018u3 as well as Azure Devops Server 2019 and 2019u1 as well as 2020 can be imported into the service. We do these kinds of imports regularly and it's a very straightforward process to restore your TFS server backup to a temporary SQL server, install the correct version of TFS/Ads and have it perform the upgrade in-place during the installation. Then use the migration tools to import the collection into Azure Devops Server. Depending on the size of your collection this may take between a couple of minutes to a couple of hours. I've done the upgrade on my laptop on certain occasions as well, installing Azure Devops Server and SQL Server Developer edition directly on Windows 10. Even a trial versions will do.
For all the details on the. Import process, see:
https://learn.microsoft.com/en-us/azure/devops/migrate/migration-import
If you want to import your tfvc project from one TFS servers to another TFS server/Azure Devops Server, you can detach the project collection on you current TFS server and bacmup/restore the database on another server. It will automatically be upgraded
If your project collection has multiple projects, you can delete the projects you don't need after attaching and upgrading your collection.
There are a few tools to perform a history replay from one server to another, those tools can't import everything, your changes id's will change and you'll lose the exact date a commit was made (and possibly the user who made the commit if that account no longer exists). Tools like:
https://www.opshub.com/products/opshub-visual-studio-migration-utility/
Depending on how old and how big your collection is, it may take many hours to migrate the data. If data has previously been deleted/destroyed or branched across projects or edited during branch operations, then the replay may fail or may be forced to perform alternative actions, some of these operations are no longer supported. I've used opshub on a couple of projects and some it completely failed to migrate, others migrated with incomplete or incorrect data. This was 4 years ago, maybe these were bugs and they were fixed, but since the import tools have been released we've used those almost exclusively.
PS: using tfs-git to convert (part of) your TFVC repo to git would be an alternative which I'd recommend you look into further. TFVC has been declared feature complete and has received very little love in the past few years. It's not supported by the new Multi-stage YAML pipelines, the integration for VS Code has been deprecated, the cross platform commandline tool for tfvc has been deprecated and therefore support for eclipse and rider and intellij as well. Team Explorer in VS 2019 is now pushed to the background with the release of the new git features which have escaped the Team Explorer window. It's clear that TFVC is fighting for a lost cause and that Git is winning, you'll need to switch over at some point.
The Team Foundation Server plugin is not available in Jenkins. The Jenkins official page shows the message:
Distribution of this plugin has been suspended due to unresolved security vulnerabilities
Is there any alternative to this plugin using which I can integrate Team Foundation Server with Jenkins?
MS have effectively abandoned support for TFVC and for the plugin.
You can still grab the plugin from the GitHub TFS plugin releases page and upload manually. ({JENKINS_URL}/pluginManager/advanced ). You may have to reconcile any dependencies manually.
MS recommended alternative is the tf command line from a shell step (brutal), which they also silently abandoned support for TFS SDK/CLI.
ps: aside from the vulnerability ( SECURITY-1506 / CVE-2020-2249 ), it does not meet the OSI open source license requirements - INFRA-2751 to be made available via the plugins site.
2021-03-30: It appears the OSI licensing issue has been resolved. This Jenkins Community post suggests a fix to SECURITY-1506 / CVE-2020-2249 is available in a fork but additional security issues ( SECURITY-2283 / CVE-2021-21636, CVE-2021-21637 (permission check), CVE-2021-21638 (CSRF) ) are outstanding, need to be resolved and released, or someone steps up to adopt the plugin.
pss: M$ also announced (23 February, 2021) retirement for Azure plugins for Jenkins, effective February 29, 2024.
I recently upgraded from Team Foundation Server 2017 to Team Foundation Server 2018. I have a couple of questions about the build portion of the install. Our current TFS build agents live on a different server than the TFS Web application.
I believe in previous upgrades and installs there was an option on the install media to just install the build portion of TFS.
Do I have to do any type of upgrade on the build server or just update all of the agents from the web application as seen in this image 1?
Although my upgrade was from TFS 2017 to TFS 2018 the build server has an administration console that shows it's version as 2015 (see image 2). Do I need to uninstall this 2015 application?
Image 1
Image 2
There are two flavors of Build agents with TFS ever since 2015.
"Team Build"/"XAML Build"
This is the Controller+Agent based infrastructure that has been around since 2010 and which has been deprecated with TFS 2017. The agents that are supported are the 2010 (on XP and framework 4) and 2015 agents. There is an unsupported 2017 version of the XAML agent which is purely meant for single machine installations where the TFS application Tier and the Build agent are running on the same server.
2015 is the preferred version to be on for as long as you still need these. You should be planning to remove your dependency on these agents as soon as possible.
*2018u2** reintroduce the XAML agent, purely for clients who're too heavily invested in the XAML infrastructure to upgrade directly to the new build system. If you're one of these I sincerely hope you have a plan in place to break this dependency. This reintroduced agent comes pre-deprecated and will be removed again in a future version.
VSO/VSTS/vNext/2015 agents
These have had many names, but are essentially the new agents that shipped first with 2015. There are two versions of these 1.x and 2.x. While the new agents auto-upgrade, they only auto-upgrade to highest available build of their major version. To upgrade from 1.x to 2.x you will need to uninstall the old agent and install the new one.
As with the XAML builds, the 1.x agent is now considered deprecated and if you're still relying on these you should plan to upgrade to 2.x as soon as possible.
Concluding
If you're still using XAML builds, you should be using the Team Foundation Server 2015 Build Agent+Controller. And plan to move away from these. This will require re-authoring the build process to the new build+release infrastructure
If you're still using the 1.x VSTS build agents, you should be upgraded to the highest version of those. And plan to move away from these by uninstalling the 1.x agent and installing the 2.x agent that matches your TFS version.
If you're using the 2.x VSTS build agents, you can upgrade them from the TFS web based admin console. These are the preferred agents for both Build and Release.
The agents should auto-update.
That's XAML build. If you're not using XAML build, you can ignore it or even uninstall it entirely.
Can anyone explain to me (or point me to a link) how TFS 2015 works with Release Management?
We have been using Release Management for about 6 months and recently started doing some research on TFS 2015. From what I understand, TFS 2015 V2 has integrated with RM.
Since my question is so broad, let me narrow it down to a few specific questions.
Do I still need to manage my templates and release paths in the RM client or is there a way of managing them from the TFS web site? I have read about how to set up a release from TFS, but its always about scheduling and linking artifacts. It seems similar to setting up a CI build in Jenkins. The client works well for me, but I am under the impression that I wont need it anymore.
Do I have to manually kick off an RM release from a TFS Release. When we use Jenkins, we have some post build steps that include starting an RM Release from command line. When I am setting up build tasks in TFS, I only see 2 options for deployment that arent relate to Azure: run command line or run a Powershell script. Do I need to kick off the RM release using a powershell or command line script, or is there a better way of telling TFS to kick off an RM release.
It is probably obvious that I am not clear on how TFS and RM integrate together, so feel free to chastise me and point me to some reading material. I have read the documentation on MSDN but even the screenshots in their docs dont look like my TFS interface, so maybe we didnt install it correctly?
The new Release hub in the TFS/VSTS web portal is a complete, ground-up rewrite of the Release experience. It has no relation to or integration with the old Release Management Server product. They are totally separate. The new Release hub is based on the idea of you writing your own deployment scripts in whatever manner works for you and using the Release hub to invoke the deployment scripts and track their progress through your environment pipeline.
You'll want to migrate off of Release Management Server, as it's no longer receiving feature updates, only bugfixes. For migration, you can use the ALM Rangers' migration utility (disclosure: I worked on this project).
For kicking off existing Release Management Server releases as part of your build process, I wrote some build tasks for the new TFS build system that you can grab on Github. They won't work in Jenkins, but you should be able to use them as a reference point. If you are using TFS build, you can import them using the TFS CLI.
I would like to upload on my TFS 2015 some of the build tasks that are available here https://github.com/Microsoft/vso-agent-tasks.
I do have a problem with certain task as they do require a minimum agent version of 1.89.0. My build agents are 1.83.2 version.
Now, the question is, how do I update my agents for a given pool? If I do right click the agent pool on my TFS and choose update all agents option, nothing happens. I suppose because the latest version of my agent available on TFS is the 1.83.2.
Where can I find the latest version of it and how do I update it?
Note I'm working on premises TFS 2015 and not VSO.
Thanks
If you right-click the agent pool and choose "Update all agents", it will upgrade the agents to the version of the on-premise TFS server. For instance, if you initially installed some RC, and upgraded the server to RTM later, some agents might have lower version. Otherwise, as you mentioned, nothing will happen because all agents are up to date.
VSO has a different release model and updates/fixes to its agents are continuously delivered. That's why the version is constantly growing.
Technically it might be possible to grab the source code of the latest VSO agent tasks, and push it to the on-premise version of TFS 2015. However, it is considered an anti-pattern, and the behavior is undocumented and unsupported.
Let me quote build vNext developers from this discussion (see the bottom of the thread):
That is not a supported option. It is very likely that the agent we
have in VSO will not work with the on-prem server. You must use the
version of the agent that ships with your server.
And:
The behavior is undefined/untested. It may work, may not. The design
is for agents to get pulled forward via an auto update process
downloaded from your service. The auto update process may alter
configs/layout on disk, whatever. That future agent might call REST
apis that don't exist, etc... The primary focus for agents is on
forward compat so they can lazily get upgraded (via task minimum agent
demand, on restart or eventually a scheduled job).
Same answer as #Yan, but putting this here because the following error came from nowhere - so I think Microsoft updated the minimum requirements this week.
No agent found in pool Default which satisfies the specified demands:
msbuild
visualstudio
Agent.Version -gtVersion 1.95.0
For your own hosted agent just right click on the queue, or click the ... icon.
I had to restart the agent service after a few minutes as it didn't seem to want to by itself. Give it a chance to update properly before doing this.