Possible bug with %teamcity.build.branch% on Perforce?
Hi!
I'm working on a project that is mainly hosted on Perforce. We want to make it so that each stream gets synced to a separate folder, since right now we have files being carried over when the workspaces switch streams. Rather than clean every time, which would make builds take super long since they can't take advantage of build caches, syncing each stream to its unique folder achieves the same thing (albeit at the cost of disk space). I was trying to use the checkout rules for the buildType such that:
+:. => %teamcity.build.branch%
would hopefully map the Perforce checkout to a folder named the same as the stream. Unfortunately, for the main development stream, this variable gets resolved as "<default>" when used in the checkout rules. What I found does work is setting a custom checkout directory:
%teamcity.build.default.checkoutDir%/%teamcity.build.branch%
This resolves the stream name correctly for all streams. I would prefer to keep the checkout directory management completely automatic for TeamCity's sake, and it does feel like a bug that it works as a custom checkout directory but not a VCS checkout rule. Maybe the value just isn't initialized for VCS checkout rules, and hopefully it's an easy enough fix?
Thanks,
Iker
Please sign in to leave a comment.
Hi! TeamCity needs Checkout Rules when it collects changes from VCS. Before changes collection is complete, TeamCity can't resolve this parameter to anything else other than <Default> because it doesn't really "know" the actual name of the default branch. So the checkout rules "see" it as <Default>. In other words, it's a chicken and egg problem.
To avoid the clean checkout on the branch (stream) change, setting the Checkout Directory to a custom path containing %teamcity.build.branch% is arguably a somewhat cleaner approach (although it is not ideal either). That is because when the Checkout Rules are parametrized, the build working directory will change when the branch (stream) changes, so you might need to modify the build steps.
Cheers,
Anatoly
Hey Anatoly,
I imagined it might be a limitation. So far the custom checkout directory seems to be working fine in my sandboxed test project. I don't know if there could be a way for the initial idea for the solution to work, maybe by causing the hash of the VCS root to change per stream somehow? Or keeping the list of streams we want in a file next to the Kotlin DSL and generating BuildTypes per stream? If I run into problems resulting from the custom checkout directory approach I'll look into those options next, I guess.
Thank you for the help,
Iker
As for generating a BuildType for each pre-defined steam, you should be able to do it with Kotlin DSL if you want to.