Managing multiple repositories in your organization each with Jenkinsfiles for CI/CD can be dented with the security problem of them being edited. Developers can edit and interfere with what was previously configured or remove all of the approvals that had been put in place. This can be catastrophic if you have plenty of sources to keep an eye on. To prevent this, you have a lot of options. You can configure approvals in your respective Source control providers such as Premium GitLab and others or you can go with the option we are going to discuss in this guide. This will apply of you use Jenkins in your environment.
This solution depends on Remote Jenkinsfile Provider Plugin that will enable you to consolidate all of your Jenkinsfiles on a different repository where you can ward off staff without requisite rights from editing those important files. So we will be installing this plugin then configure it to pick Jenkinsfile from a different location away from the developers’ sources. We shall be utililizing multi-branch pipelines as well. In case you missed it, you can get it working on How To Use Multi-Branch Pipeline in Jenkins guide. Here we go.
Step 1: Installing Remote Jenkinsfile Provider Plugin
For this step, we shall simply login to Jenkins and proceed to install tools that will allow us to achieve what we want to achieve. To our delight, there is an amazing plugin ready for us to install and configure. Head over to your Jenkins Server Web portal, click on “Manage Jenkins” > “Manage Plugins” > Click on the “Available tab” then search for “Remote Jenkinsfile Provider“. The plugin should show up. Check on the radio button then click on “Install without restart“. After the installation, click on “Go back to the top page“. The screenshots for the above steps are shared below.
Installing then click “Go back to the top page“
Step 2: Configure Multi-Branch with the new Plugin
In this step, we are going to create a new Multi-branch pipeline with the addition of isolating our Jenkinsfile in a different repository courtesy of the new plugin. The sources will reside in a different repository and our Jenkinsfile will reside in a different repository. This separation is what we wanted to achieve so that deployments are managed by designated staff. Note that you can reconfigure your previous multi-branch pipelines with this new plugin added.
To create a new multi-branch pipeline, login to Jenkins, then on the left menu pane click on “New Item“.
Once that is clicked you will be ushered to the normal area where you have to choose an item name and select the right item (Freestyle project, Maven Project, Pipeline, Multibranch Pipeline etc).
In this example, give your item a name then scroll down and choose Multibranch Pipeline item. You will be ushered into your Multibranch Pipeline area where you will be expected to add all the details required to make the Multibranch Pipeline complete. Give it a “Display Name“, a “Description” if you want.
Next, under “Branch Sources” choose the source control type which is Git in this example as above. We shall proceed to add the URL of your GitLab/GitHub repository where your code sources are. We presume this repo can be reached by your Jenkins instance.
Once that is done, add credentials that can log in to Git as follows:
Click on the “Add” drop down menu then choose “Jenkins“.
That will open the “Jenkins Credentials Provider: Jenkins” where you can add the right username and password that can connect to your repository successfully.
Once you have populated the fields, click “Add” and you will be back to the “New-Multi-Branch” item area. Under credentials, click on the down arrow and choose the new credential we just added.
After that is done, scroll down to the “Build Configuration” space where all the magic with the new plugin will happen. We will be specifying the repository and file we want our Jenkins to read, build and deploy our application once it has cloned the sources from GitLab. At the same time, we will be specifying another repository that will be holding our Jenkinsfile.
Under “Mode” while at “Build Configuration“, click on the drop down arrow and choose “by Remote Jenkinsfile Provider Plugin“.
Once that has been selected, a new form will appear like shared below.
Leave the “Local Marker” blank, under “Script Path” you can specify any other file-name if you do not like the default “Jenkinsfile“. For this example, we will retain the default though. Under “Jenkinsfile SCM“, input the repository that has your Jenkinsfile then place the credentials that has access to the repository just like we did previously above. If you have a specific branch in your repository, you can specify it under “Branches to build“.
Once that is done, scroll to the next tab, that is “Scan Multibranch Pipeline Triggers“. Here, you will see two options: “Periodically if not otherwise run” and “Scan by webhook“. As you can guess, we will be going for the “Scan by webhook” option. Click on the check box which will reveal a text area where you will input a “Trigger token” which will be added to the GitLab/GitHub webhook side as well. Input a good token and we should be good to go. Click on “Apply” and then “Save“.
Ensure that the token has been updated in your version control system (GitLab, GitHub, Mercurial, etc) as well
Step 3: Making sure everything works
With our Jenkinsfile in one repository and developer’s source code in another repository, we are good to start testing whether our new setup works to the best of our delights. Click on the “Scan Multibranch Pipeline now“
It should detect all of your branches and once you push or merge to them, it should start building depending on your Jenkinsfile configuration.
It has been a good trip and we hope you enjoyed it as much as possible. Now you can be able to separate your worries from work by this simple trick and have a good night sleep knowing that no unwarranted editing or deployments can happen without due process.
Thank you for following through to the end. Moreover, receive our appreciation for the generosity, the comments and the encouraging words we continue to receive.