Make DDB Collection names insensitive to the zAppbuild (build.groovy) --application parameter / name of Git Repositories

[FALLAI-Denis]

Hi,

DBB uses Collections to store metadata related to builds.
zAppbuild (build.groovy) determines the name of the Collections and passes them to DBB.
Currently the name of the Collection is that of --application <arg>, for us the name / path of the Git Repository used, and the name of the Git branch used.

The name of the Git Repository is also used for references to dependencies, (reference of copybooks used by COBOL programs, wich are imported form external Git Repositories).

Any change of name / path of the Git Repository (--application <arg>) or Git branch is harmful to the operation of zAppbuild...
And we've just forcibly undergone a change in the Git Repository naming / path standard on our site...

Even if zAppbuild is only a build application model, (aka Gilles P. from IBM ;-) ), we want to stay as close as possible to this model and not to drift too much to be able to benefit from the evolutions therein are brought.

We ask that the determination of the names of DBB Collections and the inverse function which makes it possible to find an application name (a Git Repository) from the name of a Collection be outsourced from the build. Groovy script and move to a "site" script to be adapted to the need and constraint of the site, so with two functions which could be something like:

• collectionName= getCollectionNamefromApplicationNameAndBranchName(applicationName, optional branchName)
• (applicationName, branchName) = getApplicationNameAndBranchNameFromColletionName(collectionName)

Thus we could no longer have a direct dependency between the name of the Application (path of the Git Repository) and the name of the Collection, but this relationship would be calculated.

Thanks.

[dennis-behm]

Hi @FALLAI-Denis ,

thank you for opening this idea. I am agreeing with it, but would like to keep application' but change about how zAppBuild is treating the application name and the configuration (branch) reference. In the below section of build.groovy`, zAppBuild is trying to automatically calculate these names.

dbb-zappbuild/build.groovy

Lines 439 to 452 in 5a649f0

	// set calculated properties
	if (!props.userBuild) {
	def gitDir = buildUtils.getAbsolutePath(props.application)
	if ( gitUtils.isGitDetachedHEAD(gitDir) )
	props.applicationCurrentBranch = gitUtils.getCurrentGitDetachedBranch(gitDir)
	else
	props.applicationCurrentBranch = gitUtils.getCurrentGitBranch(gitDir)
	}
	props.topicBranchBuild = (props.applicationCurrentBranch.equals(props.mainBuildBranch)) ? null : 'true'
	props.applicationBuildGroup = ((props.applicationCurrentBranch) ? "${props.application}-${props.applicationCurrentBranch}" : "${props.application}") as String
	props.applicationBuildLabel = ("build." + ( (props.buildOutputTSformat) ? startTime.format("${props.buildOutputTSformat}") : "${props.startTime}" ) ) as String
	props.applicationCollectionName = ((props.applicationCurrentBranch) ? "${props.application}-${props.applicationCurrentBranch}" : "${props.application}") as String
	props.applicationOutputsCollectionName = "${props.applicationCollectionName}-outputs" as String

We have seen (#143) that this might not be always correct. Additionally, what I have observed when analysing this, we are actually doing hard-coded defaults around the application-conf directory as well:

dbb-zappbuild/build.groovy

Lines 334 to 339 in 5a649f0

	String appConfRootDir = props.applicationConfRootDir ?: props.workspace
	if (!appConfRootDir.endsWith('/'))
	appConfRootDir = "${appConfRootDir}/"
	String appConf = "${appConfRootDir}${props.application}/application-conf"
	if (opts.v) println "** appConf = ${appConf}"

The automated calculation of the configuration which is used in the naming for the build group and the DBB collections, which is based on the git branch, can be error prone and might too much restrict users.

My ideas are to:

1. Move the location where you specify application-conf into the property itself and specify it there. So, the applicationConfRootDir needs to specify the absolute path, where zAppBuild should read the application configuration for the build framework. This should make it much more transparent where zAppBuild is locating the configuration.
2. Introduce a new cli parameter: dbbBuildGroup. This new parameter, is used to specify the state of the repository, which can be a branch name, git commit or git tag, depending what the pipeline orchestrator is passing in. This is resolving the linked issue and also allows a bit more flexibility.

So, with the second change, you specify the configuration and determine the build group and collections names from the CLI rather than having zAppBuild make some automated calculations.

Additionally to your scenario - You have the flexibility in applicationSrcDirs to specify a different folder instead of the application. For instance, you could specify applicationSrcDirs=src and use workspace to point to the cloned repository via the --workspace parm to be --workspace <ci-checkout-dir>/application . With this approach, the application parm is no longer a mandatory segment in the path and only is used to specify the name in the dbb metadatastore. (Some further investigation required).

What are your thoughts on this?

Dennis