Beta Thoughts....

OK - so I've been playing with TeamCity EAP for a little while now with the hope of moving my CruiseControl builds over.
I really like TeamCity - I really do want to migrate from CC onto something a little easier to configure. (And something
a little easier on the eye).

I hope one of you at JetBrains might find the time to respond to the following issues/requests and help me decide whether,
in the long term, TeamCity is going to be a viable solution for us.

1. Version Control Working Area

It would be nice to have the build agent do the vcn checkout for us, as it currently does, but to create a
proper 'working set' for the vcn in question. Currently, all .cvs or .svn directories don't make it to the
work area of the build agent. If I want to check in anything as part of the build (see below), I currently have to
perform the checkout myself in a separate ant target. With CC I only need to perform the initial checkout once manually
and then let my ant script perform the commits.

This isn't a major problem on it's own (I'm not adverse to writing an extra ant target), but when combined with point 2
below, we have a problem.

2. Version Control Ignore List:

Some of my builds commit config files back to version control. I need to have the 'vcn' triggered
build ignore these commits, and not start up another build cycle. CC has an ignore list as part of it's
'modificationset' tag. As it stands there is no way around this for me - short of writing my own ant task -
so it's a bit of a blocker.

3. Build Numbering:

A project can have several build configurations - but only one official build number. Some builds will need to
update the official build number (nightly/weekly/release) others won't (integration/vcs triggered). Each build
config would still need it's own number but there should be the concept of an 'official' or project build number.
I'm currently using a versions.properties file that is populated by CC via the 'build.label' ant property. Whenever,
a particular build cycle executes, I write to this file via ant's 'propertyfile' task and check the file back into vcs.

For TeamCity, I have been using the 'build.number' value passed in by the build agent but the only way I've found to
share this number across build configs is to remove the original 'btn.buildNumbers.properties' and create a symbolic
link (I'm on linux) to the other builds I want to link. It would be nice if this could be provided by default.

Essentially, I would like to be able to ditch the 'versions.properties' file and allow TeamCity to manage these multiple build
numbers automatically.

4. Build Dependency

I'd like to be able to only build project B if project A succeeds.

I realise this product is still in it's infancy, however it'd be good to know if you plan to add any of these features, or whether
they're basically just a 'will not fix' solution. That way, I'd know whether I'm going to be able to move away from CC or not.

Aplogies for the length of this post, however I suspect I'm not the only current CC user with these questions.

Thanks

Paul

3 comments
Comment actions Permalink

Some of my builds commit config files back to version control. I need
to have the 'vcn' triggered
build ignore these commits, and not start up another build cycle. CC
has an ignore list as part of it's
'modificationset' tag. As it stands there is no way around this for
me - short of writing my own ant task -
so it's a bit of a blocker.


Thanks for your feedback!

I filed feature request, you can watch the issue:
http://www.jetbrains.net/jira/browse/TW-667

"Paul Brooks" <no_reply@jetbrains.com> wrote in message
news:4744235.1154461835704.JavaMail.itn@is.intellij.net...

OK - so I've been playing with TeamCity EAP for a little while now with
the hope of moving my CruiseControl builds over.
I really like TeamCity - I really do want to migrate from CC onto
something a little easier to configure. (And something
a little easier on the eye).

>

I hope one of you at JetBrains might find the time to respond to the
following issues/requests and help me decide whether,
in the long term, TeamCity is going to be a viable solution for us.

>

1. Version Control Working Area

>

It would be nice to have the build agent do the vcn checkout for us, as
it currently does, but to create a
proper 'working set' for the vcn in question. Currently, all .cvs or
.svn directories don't make it to the
work area of the build agent. If I want to check in anything as part
of the build (see below), I currently have to
perform the checkout myself in a separate ant target. With CC I only
need to perform the initial checkout once manually
and then let my ant script perform the commits.

>

This isn't a major problem on it's own (I'm not adverse to writing an
extra ant target), but when combined with point 2
below, we have a problem.

>

2. Version Control Ignore List:

>

Some of my builds commit config files back to version control. I need
to have the 'vcn' triggered
build ignore these commits, and not start up another build cycle. CC
has an ignore list as part of it's
'modificationset' tag. As it stands there is no way around this for
me - short of writing my own ant task -
so it's a bit of a blocker.

>

3. Build Numbering:

>

A project can have several build configurations - but only one official
build number. Some builds will need to
update the official build number (nightly/weekly/release) others won't
(integration/vcs triggered). Each build
config would still need it's own number but there should be the concept
of an 'official' or project build number.
I'm currently using a versions.properties file that is populated by CC
via the 'build.label' ant property. Whenever,
a particular build cycle executes, I write to this file via ant's
'propertyfile' task and check the file back into vcs.

>

For TeamCity, I have been using the 'build.number' value passed in by
the build agent but the only way I've found to
share this number across build configs is to remove the original
'btn.buildNumbers.properties' and create a symbolic
link (I'm on linux) to the other builds I want to link. It would be
nice if this could be provided by default.

>

Essentially, I would like to be able to ditch the 'versions.properties'
file and allow TeamCity to manage these multiple build
numbers automatically.

>

4. Build Dependency

>

I'd like to be able to only build project B if project A succeeds.

>

I realise this product is still in it's infancy, however it'd be good to
know if you plan to add any of these features, or whether
they're basically just a 'will not fix' solution. That way, I'd know
whether I'm going to be able to move away from CC or not.

>

Aplogies for the length of this post, however I suspect I'm not the only
current CC user with these questions.

>

Thanks

>

Paul



0
Comment actions Permalink

Paul Brooks wrote:

4. Build Dependency

I'd like to be able to only build project B if project A succeeds.



Please watch http://www.jetbrains.net/jira/browse/TW-669

Kind regards,
KIR


--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"

0

Please sign in to leave a comment.