Unexpected %system.teamcity.build.changedFiles.file% behavior when re-running a build



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.

more details:

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.

1 comment
Comment actions Permalink

Hi Christopher,

This is a know issue in TeamCity https://youtrack.jetbrains.com/issue/TW-44789. Please vote for the request and watch to get status updates.

This behavior (not to provide changes files list) was implemented as "as designed" behavior with a thought that the build is special and it's changes were already included into another build.

As current workaround you can use REST API to get the list of changed files.

Another option is to create separate build configurations (based on templates) and use checkout rules. Will it work for you?


Please sign in to leave a comment.