I have a setup where I have a compile job auto-triggering for two branches (master/compile), with multiple projects marking that build as a dependency (e.g. DEV/STAGE/LIVE). I have a parameterized default.branch with a shared vcs root for all jobs. The DEV/LIVE projects have different default branches set, and STAGE has its default branch change depending on where we are in the release cycle. I use reverse.dep.*.default.branch on the parent projects to set the default branch. Here are some issues I'm running into.
- Why do I need to use reverse.dep.*.default.branch at all if I have "enforce revision synchronization" enabled on the dependency. Without the reverse.dep set, a default branch will trigger the parent build for LIVE under the master branch, and the compile job using the develop branch, even though I have "enforce revision synchronization set." I understand the logic of what teamcity is trying to do (you selected the default branch, so let's use the default branch for all jobs), but revision synchronization should override this behavior and standardize the branch/commit used even if the job is kicked off using the default configuration and dependencies have different default branches.
- I'd like to avoid having multiple vcs roots or multiple copies of the dependent compile job. I know duplicating the compile job and setting a different default branch would fix this, but it seems unnecessary. Once I set reverse.dep.*.default.branch so the dependent job has the same default branch as the parent job, teamcity has issues reusing builds in certain cases. If I kick off a LIVE (master) build via the build chains UI, everything works fine. However, if I have the compile job run automatically with a trigger on both develop and master, both of these jobs are compiled with a teamcity default.branch setting of develop. Thus, a default run of a master deploy is not able to identify the master compile as a reusable candidate because because the parent uses a reverse.dep.*default.branch of master while the compile has a default branch of develop. As far as I know, there is no way to auto-trigger a compile job with different paramaters without having more than one compile job.
- It seems like all these issues would be resolved by duplicating the compile job so there's one with a default branch of master and one with develop. Duplicating the compile jobs for different branches makes the dependency tree more complex that it should be. I'd like to avoid this, but I don't see an alternative. I'd also be happy with completely disabling the default branch functionality, but a VCS root requires a default branch, so while you can disable builds in the default branch (not what i want), there's no way to disable the default run configuration and prompt the user to select a branch instead. Basically, the default branch is not a setting that will ever meaningfully change the output of a build, yet it precludes builds being reused when they're triggered using the default run button.
Any guidance here would be appreciated. Thanks.