<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> This would help customers adopt GitLab CI faster. I've heard multiple customers ask how to transition from Jenkins to GitLab CI. This epic contains, among other things, the initial implementation steps for our new [Jenkins Importer category](https://about.gitlab.com/direction/verify/jenkins_importer/), which is where you can see longer term plans for this topic. ### Urgency and next steps The driver for this, and why it has become an emergency, is to unblock sales and support teams who need help to get their teams to start using GitLab in cases where they are heavily invested in Jenkins for pipelines. GitLab has rapidly increased our market share in the CI ([especially amongst cloud native/container based applications](https://containerjournal.com/news/news-releases/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/)) because we've built [a great CI product](https://about.gitlab.com/analysts/forrester-cloudci19/)! Additional context in Product Scaling agenda at https://docs.google.com/document/d/1nMJzrDfG7C14WP5v7P226oPFuXkwqIk7bdIT8ai0DNU/edit?ts=5d84fb07&skip_itp2_check=true&pli=1#bookmark=id.mssno1cba25y. Our [solution architects and technical account management teams are being confronted with customers converting from Jenkins CI to GitLab CI more frequently](https://gitlab.com/groups/gitlab-org/-/epics/2735#note_295171917). In addition, adoption of CI is considered a primary go-to-market [use case](https://about.gitlab.com/handbook/use-cases/) and a critical part of our [customers adoption of Gitlab](https://docs.google.com/presentation/d/1SHSmrEs0vE08iqse9ZhEfOQF1UWiAfpWodIE6_fFFLg/edit#slide=id.g7613b022ef_0_92) as a complete DevOps platform moving from SCM, to CI to CD (checkout [this video](https://www.youtube.com/watch?v=JoeaTYIH5lI&feature=emb_logo) highlighting the use case and journey). This is becoming more and more important for the customers we want to reach and grow, and is thus now being treated as an emergency unlock. Our first MVC is to deliver the wrapper (summarized in epic https://gitlab.com/groups/gitlab-org/-/epics/2779). Starting with documentation of the proposed approach (https://gitlab.com/gitlab-org/gitlab/issues/37032) and building product features to make this a little easier (https://gitlab.com/gitlab-org/gitlab/issues/208277) will let us deliver value quickly. This wrapper-like solution would help them start using parts of GitLab while boxing in Jenkins to a specific area until it can be systemically addressed, and well help avoid our new customers having to do a transition to GitLab at the exact same time as doing a conversion of all the .gitlab-ci.ymls. It's important to note that this Jenkins wrapper is only intended as a temporary solution and should not be seen as a long term solution where you'd leave things running this way permanently. The end goal and reality here is that companies will need to get their pipelines converted into .gitlab-ci.yml syntax, but this is not easy and takes time. After getting the immediate solution up, we will look at importers (really converters) for syntaxes to bring them into GitLab natively (https://gitlab.com/gitlab-org/gitlab/issues/208275 and https://gitlab.com/gitlab-org/gitlab/issues/208276). We will need to be careful that we don't communicate this is a permanent solution for running Jenkins inside of a container inside of GitLab, when it is really more of a stop-gap. ### Reference #### Kinds of Jenkins configuration 1. The Declarative Jenkinsfile - this has the traditional stage and node blocks. This is the most recent format. Also easiest to parse. 1. Declarative Jenkinsfile w/ Groovy Library - This is a declarative Jenkinsfile that one each stage/node simply invoked some external Groovy code. The Jenkinsfile just controls the flow. 1. The Imperative Jenkinsfile - This is the same as above, except inside the stages it calls exterior functions to Groovy functions. Because of this the pipeline can go forwards and backwards, redoing stages as necessary. It can also include if/and/else login to change the pipeline structure mid-job. 1. The configuration - No code approach. This is the approach where you use the UI to enter scripts and plugins, etc. It’s a mixture of one of the above and plugins. Part of the pipeline lives in configuration, some in code. 1. Scripted Jenkinsfile. This is a Jenkinsfile that’s written entirely in Groovy. It lacks stages and nodes. It’s essentially a Groovy/Java file with all kinds of login inside it. This file can also include massive libraries of code to invoke. This is the hardest to convert and interpret. #### Other Links - [Jenkinsfile Format](https://jenkins.io/doc/book/pipeline/jenkinsfile/) - [Possible prior art of someone working with YAML and Jenkinsfiles together, but in the opposite direction](https://jenkins.io/blog/2018/04/25/configuring-jenkins-pipeline-with-yaml-file/) - [Bamboo guide](https://confluence.atlassian.com/bamboo/importing-data-from-jenkins-317949257.html) and https://www.youtube.com/watch?v=9SGWRWcJTyA - https://github.com/jenkinsci/jenkinsfile-runner/issues/174: Remote issue for updating the Jenkinsfile Runner (CloudBees code) to support more recent versions of Jenkins.