Multiple default application properties.

[mhardin18]

Scenario: Client has 2 Endevor systems on 2 lpars. We are migrating both to Gitlab/DBB/UCD implementations. However, the applications within each system are also subject to only being compiled/built on one lpar or the other.

For DBB/zApp, I want to have a standard zApp implementation so that there is only one zApp repository that is cloned for either build system. Ultimately, I want the solution to be ambiguous as possible to which system it is executing on. However, this isn't entirely possible due to things like linklib concat and other nuisances.

Now, for both systems, if you look at it from just a specific implementation for that system, then I just follow the pattern already there and use the default Application properties, only overriding at application.properties when necessary.

But what I really need is 2 "default" application properties, again only overriding at the application.properties level.

So my question is, what would be the best way to achieve this?

Ideas I have:

• Have the build.properties file reside somewhere static, such as /etc/dbb (where we put the toolkit configs in). Then adjust those properties for that system/environment. This would require some changes to build.groovy to pick up that build.properties file. Specifically in the populateBuildProperties method I think.

• Have a separate repository for the configurations. Not sure how to configure this to work, but I could see it.

• What I'm trying to avoid, but have separate branches of zApp for each system.

[mhardin18]

The more I think about it.

I need to be able to tell zApp where the build-conf directory is.

But this needs to work for user builds without having the user add this to the command line options.

[mhardin18]

@dennis-behm
@M-DLB

Can you please review this and give me your thoughts?

[dennis-behm]

@mhardin18

Providing advice is difficult because it depends what you want to override.

There are some settings that need to sit in zAppBuilds build-conf directory, because it is controlling the loading of the core properties. Have a look here:

dbb-zappbuild/build.groovy

Lines 369 to 372 in a719842

	// load build.properties
	def buildConf = "${zAppBuildDir}/build-conf"
	if (opts.v) println "** Loading property file ${buildConf}/build.properties"
	buildUtils.loadBuildProperties("${buildConf}/build.properties")

An idea is to slightly change the way zAppBuild is populating the build properties in the above section and have something like the below and prefix environment/LPAR specific properties files with ${SYS}/. The LPAR specific settings then need to be in subfolders, e.q. LPAR1/dataset.properties and LPAR2/dataset.properties. This would be a sample for all the properties sitting in build-conf: e.q.:

#
buildPropFiles=${SYS}/dependencyReport.properties,${SYS}/Assembler.properties,${SYS}/BMS.properties,\
${SYS}/MFS.properties,${SYS}/PSBgen.properties,${SYS}/DBDgen.properties,${SYS}/ACBgen.properties,${SYS}/Cobol.properties,\
${SYS}/LinkEdit.properties,${SYS}/PLI.properties,${SYS}/REXX.properties,${SYS}/ZunitConfig.properties,${SYS}/Transfer.properties,\
${SYS}/CRB.properties,${SYS}/zCEE3.properties,${SYS}/zCEE2.properties

To direct the build into the right "SYS" subfolder depending on which LPAR your build runs on, you can evaluate an environment variable dbb.environment (that can be any name) that need to be defined in the environment which then populates the dbb build property 'SYS' - before you start loading build.properties . You need to add something like the below before loading build.properties .

lparEnv = System.getProperty("dbb.environment")
props.add("SYS", lparEnv)

So, with the above approach, you will only have to maintain a single zAppBuild, can run builds on different LPARs with slightly different configurations, and developers don't need to pass any specific parameter.

I just would like to remind you that zAppBuild also has the ability to dynamically override settings via --propFiles that can be computed by the CI tool .

Let us know, if this is what you are looking for.

[mhardin18]

Thanks Dennis. This is very helpful. Gave me some useful ideas I had not thought about.

One issue with dynamically overriding via a command line setting is that this has to work with user builds without having to instruct the users to add an additional property. Don't judge.

[dennis-behm]

@mhardin18 YW. I understand the requirement that this has to be transparent to the developer.

You can tackle the --propFiles overrides also via environment variables. And have them add --propFiles /etc/dbb/conf/build_${dbb.environment}.properties and have ${dbb.environment} defined for instance in the profiles of the machine or dbb.env. (but this does not work to override build.properties, which is hard-coded in the initialisation process of zAppBuild).

You might see, that I am fan of environment variables, but don't carry it to excess.

[BoRa-SEB]

I had a similar problem when I wanted to use the ZAppBuild code base in our Sandbox as our production environment.
I did a small change to build.groovy and added one extra build parameter (zAppEnv).
In the zAppBuild repo I have the normal build-conf directory and then cloned that into the name I want to use for the other environment, example build-conf-sandbox, in there I can define other options that are specific for the sandbox environment.
And in build.groovy changed to

 // load build.properties
def envPath = ""
if (opts.zAppEnv) {
   envPath = "-${opts.zAppEnv}"
}
def buildConf = "${zAppBuildDir}/build-conf${envPath}"
props.load(new File("${buildConf}/build.properties"))

// load additional build property files
if (props.buildPropFiles) {
	String[] buildPropFiles = props.buildPropFiles.split(',')
	buildPropFiles.each { propFile ->
		if (!propFile.startsWith('/'))
			propFile = "${buildConf}/${propFile}"

		if (opts.v) println "** Loading property file ${propFile}"
		props.load(new File(propFile))
	}
}         

[mhardin18]

This was extremely helpful. Made a few modifications to your snippet to meet my specific needs, but in general this will do it for anyone needing to do something similar. Thanks