The Jenkins Importer category represents a collection of tools and documentation to help you migrate away from your existing Jenkins implementation and easily move to GitLab CI/CD. There can be a lot of complexity in the details when it comes to a large, enterprise Jenkins installation that uses a lot of different maintained (or even non-maintained) plugins, but our goal is to make 80% of the automatable tasks easy and then offer Professional Services as needed for the remaining 20%.
People ask for a Jenkins importer often: they are bought into the GitLab concept, they can quickly import their projects from GitHub/Bitbucket and the next logical question is "okay how about Jenkins?" Customers are fearful of the amount of time it's going to take to "rebuild" their CI pipelines in another system. This comes from the years of effort they've had to put into building and maintaining Jenkins and their pipelines, and they are fearful of going down that road again. At least for the moment, many enterprises do not yet see Auto DevOps as a real option for them to decrease this work.
At the same time, putting Jenkins jobs into a container and wrapping them inside of a GitLab job doesn't bring the benefits of GitLab CI to you. As a result it's important we build tools which help bring things to GitLab in a way which facilitates the end goal of ensuring a modern, efficient CI/CD process for development teams. This could temporarily include running Jenkins jobs compartmentalized inside of GitLab jobs, but this is not a workable end-state even if it is an important step along the journey.
Our focus is currently on the epic gitlab-org&2779 which will implement a wrapper around the open source (CloudBees implemented) Jenkinsfile Runner. This will enable teams which are in the middle of a migration to identify parts of the Jenkins stack which are less urgent to be converted and set them aside temporarily.
At the moment we are performing customer-involved beta testing (internal issues gitlab#213158 and gitlab#208932). Feedback from this process will be used to refine the tooling and then launch it on real customer engagements.
Building a wrapper has been determined to bear more fruit in the immediate term than implementing an automated translator (scripted or declarative) between GitLab and Jenkins. As is common, translators between various CI languages, configuration, idioms, and best practices requires human reasoning to do correctly. We've extensively evaluated (1, 2, 3, 4) the feasability of strict translators. Our evaluations have always resulted in the determiniation that in the majority of circumstances a strict translation would leave users desiring to quickly convert to GitLab CI/CD from Jenkins in a WORSE position.
ux-research#765 has been created to understand the full scope of what is needed to mature this category. The intent is to uncover all different usecases Jenkins satisfies and how they could translate to GitLab. Furthermore, we intend to uncover the client's expectation and painpoints towards converting existing configurations.
The beta testing issues (internal issues gitlab#213158 and gitlab#208932 will also guide us to defining the next maturity steps for this category.
The complete list of issues relevant for this category can be found under the epic gitlab-org&2735.
There are existing importers out there of various capability and reliability. Atlassian has documentation on their solution, as well as a video demo. Bamboo also offers documentation on their solution. None of these however provide a complete lift and shift capability, successfully translating between the concepts and technologies between the different systems.
Jenkins used to offer a wrapper to convert from Jenkins to Jenkins X, but has discontinued it and now provide professional services to support migrations.
We haven't yet seen a consensus on the sales/CS side on which of the three pillars (listed below in your vision section) are most important to deliver first, but conversations are ongoing. In a general sense, all are important unlocks.
There are a few places where we can improve our customer-facing migration documentation:
There are three pillars in our vision for this category representing the kinds of Jenkinsfiles that need to be imported or ways we can execute them: