DEV Community

What Tools Do You Use To Validate Jenkins Pipeline Syntax

Thomas H Jones II on September 13, 2018

One of the customers I do work for recently decided that, in addition to supplying native deployment-automation code targeting their desired cloud-...
Read full post
Collapse
 
dmfay profile image
Dian Fay •

I've always just run them until they work. I'm not sure there's another way to validate the whole thing unless they've made adding exceptions to the script security defaults easier recently.

Collapse
 
cvega profile image
Casey Vega •

Adding your code to a global shared library assumes the code is "trusted" meaning you should not have to validate each and every call outside of the sandbox.

jenkins.io/doc/book/pipeline/share...

"These libraries are considered "trusted:" they can run any methods in Java, Groovy, Jenkins internal APIs, Jenkins plugins, or third-party libraries. This allows you to define libraries which encapsulate individually unsafe APIs in a higher-level wrapper safe for use from any Pipeline"

Collapse
 
dmfay profile image
Dian Fay •

That looks new! The Jenkins instance I was working with was a couple years old and I don't remember seeing anything like that functionality.

Collapse
 
ferricoxide profile image
Thomas H Jones II •

Yeah. I'd been doing similar. However, as we've added new people to this particular project and have more "never used Jenkins" people on the team writing Jenkins jobs, more in the way of simple mistakes have been happening.

Always nice to get a green from Travis saying that at least the syntax of something is correct.

Collapse
 
cvega profile image
Casey Vega •

I'd recommend the following:

  • use a git pre-commit hook that invokes linting via shell/curl
    • do this for all of your code, prevent bad commits whenever possible
  • use a branch to update your pipeline where possible (multibranch/organization job type)
  • use if statements for scripted and when blocks for declarative to develop safely when dealing with prod systems
  • define a PR strategy and code review changes
Thread Thread
 
ferricoxide profile image
Thomas H Jones II •
  • use a git pre-commit hook that invokes linting via shell/curl
    • do this for all of your code, prevent bad commits whenever possible

We generally just define tests within our ..yml files. With the various versions of git clients in use, it's more reliable than hoping that a given user's git client is - or can even be - configured to use standardized pre-commit hooks.

  • use a branch to update your pipeline where possible (multibranch/organization job type)

Our overall model is "work in a branch of your own fork, then PR back to the appropriate branch of the root project".

  • use if statements for scripted and when blocks for declarative to develop safely when dealing with prod systems

This is what I'm looking for. Happen to have any examples? As mentioned above, when using things like GitLab's built-in CI tool or tools like Travis, we've mostly been just handing off tests by way of file-extensions (.json files going through jq; .sh files going through ShellCheck; etc.). I'd been hoping there was a similar linter tool out there to hand off to. If we had to go the "roll your own route" (as your above seems to hint at), would be super helpful to have something to steal from use as a reference.

Collapse
 
june07t profile image
667 • • Edited

github.com/june07/sublime-Jenkinsf...

Sublime Text is my goto so I wrote that plugin to leverage Jenkins' own declarative linter.

Uploading the Jenkinsfile and running the pipeline on each edit was definitely a broken workflow and took loads of time.