I'm curious what the intended behavior for the variable %system.teamcity.build.changedFiles.file% is when you re-run a build. I'm integrating with enterprise github, in case that affects it.
If I click "Run" from the project console, I fully expect that file to be empty since no changes have occurred. However, suppose I change some file "x.txt." What I've noticed is that if my build fails, re-running the build from the build history "Run build with this change..." option will NOT populate the changedFiles file.
Does this seem correct? To me it certainly feels counter-intuitive (if not an actual bug). I did expect 'run with change' to repopulate the file like it did the first time. I dug around a bit, and I also tried enabling "Clean build" though that didn't repopulate the file.
I'm storing multiple AWS lambda functions in a single git repository. When I update one lambda function, there is no need to deploy all of them - just the changed one. chagnedFiles.file provided a convenient mechanism to determine which items actually need to be dropped into my output artifacts. Unfortunately, if the build fails, I lose the ability to re-inspect the committed files that would normally be in %system.teamcity.build.changedFiles.file%
Short of putting each lambda function into it's own repository, please also share if you have an alternative suggestion for reducing unnecessary re-deployment? I'm open to anything (e.g. would a VCS trigger using a path wildcard do this instead of my for-each-folder-in-repo approach).
Thanks in advance.