| Priority |
Major |
| Type | Feature |
| State | Open |
| Assignee | Pavel Sher |
| Subsystem | Server |
| Affected versions |
Benares 3.1.1 (6828)
|
| Fix for |
Medium Priority Pool
|
|
|
Currently we r having 3 build configurations for a project.
1. Development Build Configuartion -
(would be used only by developers,to check emma, Junits, test cases, etc but would not label VCS)
It has one VCS root defined which just lets to checkout and thats all.
2. Test Release Build Configuartion -
(would be used by QA guys to perform a build, take a release,and perform a VCS label)
checkout Rules are +:trunk
VCS Labellng Rules are +:trunk=>tags
VCS labelling pattern PRJ_V_%minor%.%major%.%ReleaseComp%.%Build.uniqueNumber%
Remember that minor, major, ReleaseComp, Build.uniqueNumber, etc all are custom properties added to build conf.
and would be provided during "custom Build"
3. Deployment Release Build Configuartion -
(would be used for build a final release which could be handled to the client, an perform a VCS Label)
checkout Rules are +:trunk
VCS Labellng Rules are +:tags=>tags
VCS labelling pattern PRJ_V_%minor%.%major%.%ReleaseComp%.
Remember that minor, major, ReleaseComp, Build.uniqueNumber, etc all are custom properties added to build conf.
and would be provided during "custom Build".
Remember that Build.uniqueNumber is not present here.
Both 2 & 3 Build Configurations use a shared VCS Root, this VCS root is different from the VCS root used by 1st Build conf.
Problem is that
while performing a build for 3rd i.e deployment Release Build conf. we need to checkout from say PRJ_V_1.2.3.4 tag
but the values 1,2,3,4 are taken from user and needs to be passed to the checkout rules.
Is this possible?
if yes how else if no then is there any hope that it would be implemented in the future releases.
Thanks.
Scenario:
When a issue is raised in JIRA we are required to automatically pass the BUILD_TAG value into TeamCity and kickstart the build process using HTTP GET. We are successful in the integration butwere not able to configure VCS Roots to take in an environment/system variable that can be passed from external tools via HTTP GET.
I guess the requirement is pretty common and wonder how its not possible with TeamCity. :(
+:project/trunk => .
and checkout rules can contain parameters, thus in many cases you can parametrize how checkout is performed.
http://skepticalhumorist.blogspot.com/2010/02/release-builds-with-teamcity-selecting.html
Great solution by the way. Good job TeamCity team!
@James - unfortunately, the existing solution with templates woudn't work for Git yet :(
Please describe your need in detail. What use case do you need to cover and where exactly do you need properties to be supported?
Essentially, I feel like there is no need to have this separate set of configurations known as "VCS Roots" when there is barely a difference between the repositories and VCS's we use. It's all Mercurial, it's all under the same hg.website.com domain. The only variation on all of our VCS Roots is at $foo and $bar in hg.website.com/$foo/$bar. Seeing as how checkout rules do not work with Mercurial and the URL hg.website.com/ does not look like a repository to TeamCity's eyes, there is no way for us to set up a 1-Root-For-All-Configurations VCS Root.
If I could have just 1 VCS Root that took in the $foo and $bar variable from something that implemented the VCS Root (such as a single configuration's name or an entire project's name) then setting up a task would be a process as simple as Create From Template -> Name Properly. No need to go in and edit which VCS Roots to attach, no need to go into the VCS Root and specify the repo location. Just name the thing properly and we're done. The easier this process is, the less likely a small team of TeamCity experts has to manage things for a large team of devs. Instead we can just write the "2-easy-steps" instructions somewhere and trust our developers to manage their own tasks. As it is, however, TeamCity is too complicated and requires too much time to set up new tasks and we can't expect our developers to take the time to learn it all.
Thus why we need dynamic VCS roots.
We really thought that this would work with the checkout rules. If we could just get %BRANCH% to work in the checkout rules that would make TC a million times better.
Hudson and other CI systems have this ability, so this is a big minus for TC compared to them.
proxies:
you can probably define proxy in the default Subversion config (<os app settings directory>\Subversion\servers) and make sure it is used by the root. If you have issues with this, please open a new issue/new forum thread on that.
branches in checkout rules:
As David mentioned, you CAN specify property references in checkout rules (they are supported since 5.0).
Can you please describe what behavior do you expect when you specify parameters that affect checkout rules in the custom run build dialog?
Particularly, what do you want to see in the changes of the build?
Also, please describe the use cases that you need the feature for.
I can see the dilemma with tagging the changes for that build. For my purposes, all the changes to that branch would suffice. I don't think that makes sense in general, however. In reality, the ability to do this outweighs knowing the changes. Simply indicating that the the list of changes is not available would suffice for my needs personally. I can not think of a way reporting the changes correctly otherwise.
I'm asking for the same feature outlined in the initial request.
Here's a simple VCS root example (Perforce).
//depot/Paradigm/%version%/... //team-city-agent/build/%version%/Paradigm/...
I would then define %version% on the Properties and Environment Variables tab.
GT
specify the properties in the custom run build dialog, and:
...
This could be a good way to handle build of temporary branch & it is a nice way to handle patch/fix where only the path in the CVS differ with everything else is identical (why create a new configuration for those ?)