Shared libraries "vars" folder structure - can I add subfolders?

Question

From Extending with Shared Libraries - Directory structure I created a shared library where I have multiple *.groovy files implementing global variables in the vars folder.

Can I add subfolders to vars to organize better my files? I tried, with no luck at the moment of consuming the global variable. Is there a specific syntax I need to use to reference a file in a subfolder? or subfolder are just not supported?

Tauten

If you find yourself needing to create subfolders inside your global vars, then you probably need to migrate that functionality to a shared library. Global vars are more or less for interfacing between a Jenkinsfile and a shared library, or for self-contained methods. – Acrodont

@MattSchuchard I take from your suggestion that most of my logic should be on the src folder as objects? I'm finding myself having most of the code in the vars and not that much in the src – Tauten

Wording it a different way: if you are implementing complexity and sophistication to the degree that you find yourself needing to organize the code beyond a single file, then it motivates that migration. The motivation/rationale behind whether something is a global var or a shared library is confusing at first for sure. – Acrodont

You come to the point, where you probably want to make your vars files becoming just "switches" for further class based structure of code organized in src/main/groovy/... according to a configuration you passed. The simpler the Jenkinsfile, vars file and more decoupled the src code is, the better(easier) you may apply testing with spock, junit o.e. – Virtu

Answer 1

Unfortunately, no, you cannot. There is a declined improvement request at Jenkins' issue tracker. The given reason is that filenames are mapped directly to variable names.

Other approaches typical in Groovy like

evaluate(new File("../tools/Tools.groovy"))

do not work as well, because the Jenkins global vars files are not native Groovy code but processed.

However, there is something you can use to better organize helper functions for those which are not custom pipeline steps.

I have an includes.groovy file containing different functions like

def doSomething() {
}

def doSomethingElse() {
}

In a customPipelineStep.groovy file I can then access them with

def call() {
  includes.doSomethingElse()
}

So includes works somehow like a namespace, and you could have multiple such utility files. They are no folders, but help organizing stuff.

Instead of defining custom steps in individual files, you could also group them together in files, but then you would have to wrap them in a script block within your pipeline to access them, as pointed out in the documentation. In the same way, include-functions are also publicly available in script-blocks, so be aware that they are not private.

Desertion

Answer 2

While we cannot add subdirectories because of the predictable folder structure requirement, we can always put each shared library into a separate git branch within the same repository:

• branch sharedlib1:

/vars/sharedlib1.groovy
/resources/sharedlib1-script.sh

• branch sharedlib2:

/vars/sharedlib2.groovy
/resources/sharedlib2-script.sh

etc.

Maggy