search

IBM / dbb-zappbuild

zAppBuild is a generic build solution for building z/OS applications using Apache Groovy build scripts and IBM Dependency Based Build (DBB) APIs.
Apache License 2.0
40 stars 140 forks source link

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

Open FALLAI-Denis opened 1 year ago

FALLAI-Denis commented 1 year ago

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:

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 commented 1 year ago

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 ofbuild.groovy`, zAppBuild is trying to automatically calculate these names.

https://github.com/IBM/dbb-zappbuild/blob/5a649f0a591625be0bfe39dd880ef1d43ba8272f/build.groovy#L439-L452

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:

https://github.com/IBM/dbb-zappbuild/blob/5a649f0a591625be0bfe39dd880ef1d43ba8272f/build.groovy#L334-L339

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