DBB 2.0 Upgrade, testing a Deleted Artifact

[Todd0513]

I have a question on the DBB 2.0 upgrade...in my test project, I removed a source code but left the related copybooks because I still have other source using those copybooks. But when I change one of those copybooks to test the impact, it still attempts to pull in the source I removed.
To remove it, I simply deleted it from the project. Is there another process I should have done to have "properly" updated the impact data? And now that I have removed it, is there a way to clean-up the impact data?
Thanks!

[dennis-behm]

Hi @Todd0513 - apologies for the delay in picking up the discussion here.

Thanks for raising this question.

zAppBuild is supporting various repository layouts - and it depends on how you set the --workspace setting for build.groovy. For instance, you can have the application folder within the root level of your repo; another layout would be when the repository name is determining the application folder and the offset; and even a nested application - like the MortgageApplication shipped with zAppBuild - is supported. For good or bad.

Here is the challenging part: Within the DBB Metadatastore (especially the dependency information stored in the collections) we maintain data for the various files of the repository to drive impact analysis. The key for these entries (also known as the logical files) is the relative path of the build file in the build workspace.

When assembling the build list (which has to be a list of relative file paths) and running the git diff operation, we use a method in the BuildUtilities.groovy to determine the relative path, the offset, of the build file - this happens for the various actions that a user can perform against the git repo (add, change, delete). You find it as the fixGitDiffPath.

Unfortunately, when deleting a file, we cannot check if zAppBuild found the correct "mode". And you should have seen a message like in your (pure) delete scenario:

*! (ImpactUtilities.fixGitDiffPath) Mode could not be determined. Returning default.

My guess is, that the deletion actually has not removed the file from the DBB collection and therefore it could occur that the deleted build file could be detected in the impact analysis phase of impact build.

Please determine the correct mode, and update it here:

dbb-zappbuild/utilities/ImpactUtilities.groovy

Lines 402 to 403 in f3dfad6

	// Understand repository setup for offsets
	def mode = null

Please let us know if this is resolving your issue

[Todd0513]

Thanks Dennis! One of my engineers found where we could add a check for the physical file in the ImpactUtility.groovy and if not found, continue on. This got us past the error we were getting. We added if(impactFilepath.exists()) in the createImpactBuildList method.
We'll review your notes above and make sure we haven't missed anything.
Thanks!