DSTY - jenkins-std-lib (Shared Library) - Interact with files/directories using Groovy!

DontShaveTheYak is proud to be bring to you a Path class in v0.9.0 to make working working with the filesystem in your Pipelines much easier.

The feature is currently not released yet and will be in preview for the next week or two. The steps to add jenkins-std-lib to your Jenkins can be found here. Now you can test the Path feature by declaring in your pipeline:




The Path class allows you to do the following:

  • Create files/directories
  • Rename files/directories
  • Move files/directories
  • Copy files/directories
  • Read/Modify files/directories permissions
  • Delete files
  • Delete directories, there contents or both
  • Create tar/zips of files/directories
  • Unzip/untar files
  • Read/Write files
  • Create temporary directories
  • Create temporary files
  • Get free, total and usable disk space.

Checkout the example job here, which demonstrates most of the features. Hosted javadoc documentation will be available when it’s released but can be built locally if you want it.

If you are using the vscode IDE, then I highly recommend my Jenkins Extension Pack which gives you auto completion and javadoc comments directly in your IDE.

1 Like

Nice one! Looks like the new library functionality overlaps with the Pipeline Utility Steps Plugin: https://plugins.jenkins.io/pipeline-utility-steps/ . Did you consider moving some of this logic there so that there is native implementation available out of the box?

I knew there were some steps that provided some filesystem functionality but I didn’t really look into it for a couple of reasons.

  • I’m not familiar with Java development, which means I struggle to contribute to Jenkins plugins. I have tried the guides and I still fail. Even if I get the skeleton plugin up and running, I don’t know how to implement my feature and find the documentation lacking.

  • One of the hidden features of jenkins-std-lib is that it doesn’t rely on plugins and so it works on any Jenkins server. This portability is important to me, because as a consultant, I work with many clients and it can be difficult to get them to install or upgrade plugins on their Jenkins server. Adding a shared library is easy and it doesn’t risk breaking existing pipelines.

  • I like being able to dynamically configure the version from inside the job. This means I can set the commit or tag in the Pipeline and I know it will always work, even if I make breaking changes in the future. I can also upgrade specific jobs to use never versions if they need the newer features, something a plugin can’t do.

  • My time is precious to me, I built and released this functionality in roughly 4ish half days. Even less if you dont count all of the social media posting. Judging by lots of PR’s on existing plugins, my PR would have been merged anywhere from months to years.

  • I plan to continue to build onto the library. The things I’m creating now like bash, scm, http, logging and os are just building blocks to create more advanced functionality for interacting with terraform, python or GitHub actions etc. While I could probably build those things using other plugins, that means having to pass in the workflow script and not having the rich IDE support I currently have.

1 Like

Thanks for the clarification! I definitely agree with such an approach if it is good for your developer experience. In fact, I recommend Pipeline libraries as one of the ways to extend Jenkins. And it’s quite efficient way. We should do more on promoting it more, e.g. by creating a Pipeline library marketplace where contributors can publish their reusable libraries. I have a PoC fr that somewhere

Judging by lots of PR’s on existing plugins, my PR would have been merged anywhere from months to years.

Sadly it is likely to be a case. @batmat @megathaum are aware about of the situation with Pipeline maintenance.

Over the weekend I added some static methods to retrieve common directories.

Path workspace = Path.workspace()

Path homeDir = Path.userHome()

Path jenkinsHome = Path.jenkinsHome()

Things are looking really good. Plan to release 0.9 later this week.