Sometimes, when working on Jenkins jobs, I find myself stuck in this cycle of committing the Jenkinsfile, pushing it, and running the job over and over again. I have to admit it gets old real fast. Working on the pipeline code is time consuming as it is, especially if your build time is inherently long, and any added overhead can be agonizing. Oh, and as an added bonus, my git history gets filled with junk commits (I wrote a post about how to get read of them).

There is something awkward with working on pipeline code, especially with Jenkins: * The DSL keeps changing. * A Jenkinsfile may become a mix of groovy and other scripting languages. * Plugins are missing * If you are like me, moving between clients, each installation will have different versions of Jenkins so Goto point #1 * It’s very hard to test locally

What if you could work on your Jenkinsfile in a “sandbox” and test the Jenkinsfile live on the system? There is a neat little feature that allows you to modify the Jenkins file and rerun the job. You can do it over and over until you are happy with the results and can commit working code without breaking anything.

The Jenkins Replay Button

For a long while, I ignored that little button on the job dashboard, which in retrospect, could have saved me hours.

It is somewhat similar to the Rebuild button but allows you to edit the Jenkinsfile just before running the job.

Jut inline edit the code and click the run button.

Where it falls short

The replay feature works well, but because you have access to the Jenkinsfile alone, it’s not very helpful if you are using libraries. You may also want to create a copy of the job if you don’t want a messy build log.

Jenkins giving you a rought time?

I know, working with Jenkins may lead to headaches. Trust me. I’ve been there. So if you want to chat, let off some steam, or need a little help, feel free to reach out here.