Open FALLAI-Denis opened 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 of
build.groovy`, zAppBuild is trying to automatically calculate these names.
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:
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:
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.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
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.