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:
@Library('jenkins-std-lib@0.9.0-SNAPSHOT')
or
@Library('jenkins-std-lib@develop')
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.
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.
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.