Jenkins: Working with Credentials in your pipeline

Security is mandatory, and should always have been, so eventually, you’ll run into the requirement of having to pass credentials to a system in your pipelines.

It could be you trying to authenticate with your Binary Repository Manager (e.g. Nexus, Artifactory), your Source Code Management system (e.g. SVN, git, TFS) or an internal system like JIRA or a ChatOps-like application (Mattermost, Slack), but credentials are most likely necessary and mandatory.
Luckily, Jenkins knows the concept of a secret and calls it a credential. For more information on this topic, please see the documentation.

These credentials can also be used in your pipeline, and they are implemented as theĀ helper function credentials() in the environment block.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

In this post, I’ll try to show the usage of the helper function in your Jenkins Pipeline, and how to write tests to validate that.
Read More »

Jenkins: Testing conditional logic for stages in your pipeline

Some steps in your development or release process can only be executed when the conditions are right. An example of this is that releases to Production can only be done from the production branch, or that deployments to Acceptance can only occur when they are approved by a specific user.
This is where conditions shine, and they are implemented in Jenkins Pipelines as a when block.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

Whenever there’s logic involved in your code, one has to be extra careful that the behaviour of this code is both correct and consistent over time. Tests help with both.
Read More »

Jenkins: Testing with post conditions in your pipeline

The behaviour of your pipeline can be much more complex than the simple success/failure flow shown in the previous blog post.
The Jenkins declarative pipeline syntax has a lot more ways to decide whether to execute a step or not, and this also requires a proper test scenario.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

This post will focus on the post section, which is very much like a regular stage but is only executed when specific requirements are met.

Read More »

Jenkins: Validating the behaviour of your pipeline

The recent posts on this blog about Jenkins have been preparing us for this: validation of the behaviour of your Jenkins Pipeline in a test, in order to be able to check what the impact is of any changes you make to this pipeline, before it lands on your live instance and possibly influences the teams that are working with it.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

So far, we’ve seen how to set up your project in your IDE, how to run a pipeline from your Shared Library, and how to write your first (simple) test for this pipeline.

Read More »

Jenkins: Testing a full declarative pipeline in your Shared Library

In the previous posts, I’ve shown how to set up your Jenkins Shared Library, create Custom Pipeline Steps in it, set up the test frameworks, run complete pipelines from your Library and write tests for your Custom Pipeline Steps. Now the time has come to test the full declarative pipelines!

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

Remember why we are going through all this trouble? We want to have as little issues as possible during the development of functionality in pipelines and steps, and want to achieve this through:

  • Documenting the behaviour of pipelines/steps in tests
  • Validating the current implementation of pipelines/steps
  • Removing the need for a ‘live’ environment through mocking
  • Enabling the possibility for debugging the code in an IDE

Read More »

Jenkins: Preparing your Shared Library for tests

After explaining how to set up your Shared Library, how to build it and how to run complete pipelines from this Library, it is time to create tests for the behaviour of the Library itself.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

As I’ve detailed before, being able to test the behaviour of your Library is instrumental in running Jenkins at scale. You just do not want to have to ‘test’ any changes in your pipelines or underlying code on a live production system. Ever.
The code which is being developed by the team(s) is usually held to very high standards by implementing a strict development process with multiple checks and quality gates: why should the code for your development process be treated differently?

Read More »

Jenkins: Running a declarative pipeline from your Shared Library

As shown in the previous blog post, Jenkins enables you to write your own pipeline code, which can be shared among all pipelines in your Jenkins instance.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

Where we’ve focussed on custom steps previously, I’ll now demonstrate how to create and use full declarative pipelines from your Shared Library.
This way you can minimize the amount of duplicated code in your projects by getting nearly all pipeline configuration from a central location.

Read More »

Jenkins: Creating a custom pipeline step in your library

Pipelines in Jenkins, especially the declarative kind, can be very powerful and expressive at the same time.
As a caveat, it is also very easy to get overly verbose by (mis)using the script-tag to write all business logic not provided by Jenkins by default or by a plugin.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

The Jenkins Shared Library has a solution for this, by enabling you to write your own custom pipeline steps, without creating a plugin.

Read More »

Jenkins: Using Gradle to build your Shared Library

Being able to test your Jenkins pipeline Shared Library code, and therefore minimising the risk of pushing new pipelines or functionality to your Production instance, is vital for organisations using Jenkins at scale. Having your teams impeded by a ‘simple’ change in your Jenkins Shared Library is simply unacceptable in many cases, and even more so if it can be avoided altogether.

There is always a certain risk attached to pushing code to Production, but any effort to minimize this risk is welcomed as it will save the organisation real money in the long run.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

The first part of being able to run tests on your Shared Library is being able to ‘run’ the code, and with the Library being Groovy, code Gradle is the logical choice.

Read More »

Jenkins: Setting up a Shared Library for your pipelines

When you’re using a system with multiple teams/users, there is always a trade-off between having a shared codebase and the ability to override certain parts for a specific need.
Using Jenkins and the modern scripted or declarative pipelines with multiple users or teams is no exception to this, as there will always be an edge case which differs subtly from the norm. It might differ for any reason, even if it is just the stubbornness of a certain individual or a team.

Please note this does not apply to the more traditional Freestyle jobs, as they do not rely on code to run, but are defined in XML files on the Jenkins Master.

This post is part of a Series in which I elaborate on my best practices for running Jenkins at scale which might benefit Agile teams and CI/CD efforts.

So, we have at least two criteria for our Jenkins set up:

  • Having a shared code base for your declarative or scripted pipelines
  • Being able to override behaviour as needed

Read More »