[Jenkins][Gerrit] Test your unmerged patchstet before submitting

We made a change in CI pipeline repo, and before merging we need to verify if everything is working as expected or not? How can we do it?

Source: Gerrit

Source: Jenkins

Lint your Jenkinsfile.

Jenkins comes with an inbuilt tool to lint your Jenkinsfile. Before submitting your change to gerrit, you can lint your change using the Jenkins linter.

# ssh (Jenkins CLI)
# JENKINS_PORT=[sshd port on controller]
# JENKINS_HOST=[Jenkins controller hostname]
ssh -p $JENKINS_PORT $JENKINS_HOST declarative-linter < Jenkinsfile

There is a VS code extension that can be installed for linting on the editor itself. You can install the extention from vs marketplace. Jenkins Pipeline Linter Connector and you need to configure below things in the extension.

# Source: https://www.jenkins.io/doc/book/pipeline/development/#visualstudio-code-jenkins-pipeline-linter-connector
jenkins.pipeline.linter.connector.url is the endpoint at which your Jenkins Server expects the POST request, containing your Jenkinsfile which you want to validate. Typically this points to <your_jenkins_server:port>/pipeline-model-converter/validate.
jenkins.pipeline.linter.connector.user allows you to specify your Jenkins username.
jenkins.pipeline.linter.connector.pass allows you to specify your Jenkins password.
jenkins.pipeline.linter.connector.crumbUrl has to be specified if your Jenkins Server has CRSF protection enabled. Typically this points to <your_jenkins_server:port>/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,%22:%22,//crumb).

Unit Test your JenkinsFile

To gain more confidence in your pipeline files, you can also add unit tests with the help of Pipeline Unittesting Framework. — JenkinsPipelineUnit. Functions can be mocked, for example, reading from a file, or running a sh command.

Testing in real environment

We can gain more confidence by testing our patchset in real environment without mocking anything. Add an extra string parameter on your pipeline, with name your_awesome_repo_refspec and description as “give the refspec for the patchset”. Now, in your pipeline, when you are using gitscm to clone the repo, update the below settings:

Repositories > Advanced > Name: Leave it Empty

Repositories > Advanced > Refspec: $your_awesome_repo_refspec

Branches to build > Branch specifier > FETCH_HEAD

Now, whenever the job is running with the empty value for the refspec , it will clone the git fetch origin and pull the latest changes that are done on any branch on the server (assuming we have only master branch and working on the patchsets) then we have latest changes cloned and pipeline runs normally.

With a refspec provided value, it will clone using the refspec and the FETCH_HEAD will point to the latest patchset. Hence, while testing your change, by providing this value you can test your changes in real environment.

Thank you for reading.