Forcing files to be built
In some cases, it’s not possible to have an automated discovery of impacted files in an impact build scenario. For instance, when your application is impacted by changes of external dependencies that are currently not managed in build scope (like in another repository) or dependencies that cannot be determined by the integrated DBB scanners.
In these scenarios, you would like to force a set of files to be part of the build list – without actually changing the source code.
When files are modified in an application, the build framework will find all the changed files and will calculate all the files impacted by these changes. This process in known as an impact build see BUILD.md and is selected build type for this recipe.
In a sample application, a set of files exists which the impact analysis can't find as impacted programs, because the dependencies are not obvious and could not be captured. This can happen in scenarios like:
- When calling a subroutine, a standard filler area is used as the communication area, but it is not defined in a copybook.
- An existing, external dependency to a file (not managed in git) within the application scope.
- On a build request, providing a list of additional files which must always be built/processed -for example for force processing all the test cases.
When building using the zAppBuild sample framework, you have the capability to use different build types. In this scenario, the --impactBuild option will be used to calculate all the changed source files and impacted files if the dependencies are registered in the DBB collections - in the defined build scope.
In addition to the build type controlling the automated impact analysis, a text file can be provided via the command line: it contains the list of source files you want to add to the build list. This feature is available today with the zAppBuild framework: an impact build can be requested for your application, while a defined list of necessary files is appended to the build list. The build framework will combine both options to calculate the build list.
Let's look at some sample invocations as next.
After having a good understanding of this recipe, checkout the external reporting capability in zAppBuild, which benefits also from this recipe to address rebuilding programs impacted by changes to external dependencies.
In this scenario, the MortgageApplication sample application provided with zAppBuild will be used. To illustrate this situation, we assume that a changed external dependency requires to rebuild the epscmrd.cbl and epsmlist.cbl programs. Instead of performing a dummy change on these program files, a text file in the cobol folder is created, containing the relative path to the files, which will be added to the build process.
For this demonstration, the copybook file epsnbrpm.cpy in MortgageApplication is changed and will be part of the build as well. On the build request, the --impactBuild option along with the path to the text file is provided. The additional build list file needs to be referenced as the last parameter to build.groovy:
$DBB_HOME/bin/groovyz /u/dds0690/userBuildRepo/zAppBuild/build.groovy --sourceDir /u/dds0690/gitlabRepo/dbb-zappbuild/samples --workDir /u/dds0690/gitlabRepo/work --hlq DDS0690.MORTGAGE --verbose --application MortgageApplication --impactBuild MortgageApplication/cobol/listFile.txt
Reviewing the console log, the script manages first the changed and impacted files and then adds the required files from the text file :
The final build list is printed to the console output, which now contains epscmrd.cbl and epsmlist.cbl as well:
epsmlist.cbl is added to the build list as it is impacted by the copybook change. At the same time, it is also one of the two files required to be built, passed via the listFile.txt. However, it appears only once in the final build list file.
Please note that if you run the build with the same options again, no changes would be found. However, the build framework would again add the two files from the text file to the final build list.
