This might be more an edge case, but let's assume the following build scenario:
Build 1: In an impact build scenario, a changed submodule (subpgm1.cbl) is detected. This submodule is included to a load through a link card (pgm1.lnk), which is correctly detected during impact analysis. While the build continues to process the build list, even when subpgm1 has a compile error, and pgm1.lnk is executed successfully, but now misses the subpgm1 obj, it updates the logical file for pgm1.lnk in the output collection through the saveStaticLinkDependencies method.
On the next build when fixing the compilation issue of subpgm1.cbl, impact resolution will not find the dependency to pgm1.lnk any more and will NOT add it to the build list.
Conclusion: Updating the output collection, should be conditional to the current state of the build execution, see props.error.
This might be more an edge case, but let's assume the following build scenario:
Build 1: In an impact build scenario, a changed submodule (subpgm1.cbl) is detected. This submodule is included to a load through a link card (pgm1.lnk), which is correctly detected during impact analysis. While the build continues to process the build list, even when subpgm1 has a compile error, and pgm1.lnk is executed successfully, but now misses the subpgm1 obj, it updates the logical file for pgm1.lnk in the output collection through the
saveStaticLinkDependencies
method.On the next build when fixing the compilation issue of subpgm1.cbl, impact resolution will not find the dependency to pgm1.lnk any more and will NOT add it to the build list.
Conclusion: Updating the output collection, should be conditional to the current state of the build execution, see
props.error
.https://github.com/IBM/dbb-zappbuild/blob/99624f601019ca6483023eb00c9d420535ced6d4/utilities/ImpactUtilities.groovy#L878-L896