How are env, currentBuild, etc. bound to vars in shared library

[Ken Petti]

Hello,

I'm developing a shared library for us across several business units. We want to have 1 repo that all BU's can use, but also want to separate functionality by business unit. Additionally, we want users to consume the latest non-breaking changes of the library. I'm experimenting with a name spacing approach. This is some example code:

// var/businessUnitA.groovy

def propertyMissing(String name) {

    return this.class.classLoader.("businessUnitA.v1.$name", true, false).newInstance()

}

// src/businessUnitA/v1/Notify.groovy

def sendSlackMessage(arg1, arg2, arg3) {

   // actual logic to send the slack message

}

// Jenkinsfile

businessUnitA.Notify.sendSlackMessage('a', 'b', 'c')

This approach allows us to think of the shared library more like a versioned API than a package that might have multiple long-lived major versions.

With this background, the problem I'm having is accessing the pipeline global variables like `env` in businessUnitA's `missingProperty` function. When I try to access `env` in `missingProperty`, it leads to infinite loops. I've also tried looking at this.getProperty('binding)  but the binding doesn't appear to have those global variables attached. I even tried checking out the class loaders to see if there was an existing instance I could access. Is there any way I could get at those global variables in the `missingProperty` function?

Thanks!

[Ken Petti]

It actually seems like I might have solved my issue. I created a singleton class that will store some user-provided configuration. Then, in my `missingProperty` function, I can access that singleton without triggering and endless loop. It seems to work great. Any thoughts about that approach?