Configurations and Code Synchronization

Is there a way in TeamCity 2.0 to have several build configurations of a project executed with the same codebase simultaneously? What I'm looking to do is have a project with several parallel configurations I'd like to run at the same time (i.e. 4 flavours of UNIX, NT, Java, .NET, etc. all building simultaneously), however all of these configurations would contribute to the overall full build of the product. As such, they'd all need to be using the exact same source code set (in our case, Subversion revision). Is there a way to have several configurations all dependent on each other and all running with the exact same revision?

9 comments

Allen,

You can configure TeamCity to builds on several platforms (agents), but for the time being there is no straightforward way to ensure exactly the same codebase is used in those builds.

Our initial plans for the next version (3.0) of TeamCity include addressing the cases like you describe: running builds on several platforms and reporting the combined result.

One of the possible approaches is enhancing build dependencies (build the same sources) and some sort of container build configurations that will represent the combined status of a build for all dependent configurations (that can run on different platforms).

BTW what would you prefer for your project: having one build configuration and some simple setting like "run on ]]>" or ability to fine-tune a build configuration for each platform individually?

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

I think the ability to fine tune on a per build config basis would be ideal, not all of our build processes are parallelizable. For instance, I don't want to build DLLs that share code on different platforms with the same codebase as that just duplicates CPU effort.

Is there any way to write a plugin to do this right now? I really like TeamCity's features however I don't think I'll be able to justify the cost if we can't get this working somehow.

0

What you can achieve now: create several build configurations with requirements set to let each run on a specific platform only, add VCS trigger to each configuration. This way you will usually get all build configurations started after each detected VCS change. There is no guarantee the configurations will use the same sources, but it will usually be so if you have enough agents and moderate checkin frequency.

If you need a guarantee, you will need to manage sources checkout process as part of the build procedure and use VCS checkout mode: "do not checkout files automatically". Then you will need to ensure relevant build configurations checks out and use the same sources.

As to presenting status of all the build configurations ran on the same sources in a single place, I am afraid there is no usable way to do it now with a legitimate plugin.

I hope TeamCity 3.0 will provide all capabilities to allow such configurations with due comfort to the users.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

I do not want to present the status in the same place, I'm fine with several build configurations reporting status seperately. I just want to implement a custom build listener that is dependent on another project and that tells TeamCity to check out the source at the other build's revision. Is there no way in a custom build listener to tell TeamCity which revision of the code to check out?

0

Also I guess I'm a little confused about the build configuration feature now. The point of the feature is to allow parts of a build to be broken up and distributed to multiple agents, which is exactly the functionality I want.

However, you're saying there's no way to ensure that the various parts of the build are consistent with each other? What's the point of distributing parts of a build if they're all built off of different source code?

0

I just want to implement a custom build listener that is dependent on another project
and that tells TeamCity to check out the source at the other build's revision.


For the time being there is no straightforward way to use specified sources revision for a build even from inside a plugin. This can be workarounded at various levels, but I am afraid it is hard to achieve solid functionality in the area with 2.0 version of TeamCity.

I hope TeamCity 3.0 will provide first-class support for such functionality.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

A build configuration is just a particular build "type" (see also http://www.jetbrains.net/confluence/display/TCD/Basic+Concepts#BasicConcepts-BuildConfiguration). It defines the build itself, not part of the build. Current TeamCity version uses multiple agents to run builds as solid blocks, at the same time allowing trigger and artifact dependencies between them.

Allowing parts of a build to be broken up will be one of the focuses of the next version.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

You can configure TeamCity to builds on several platforms (agents),
but for the time being there is no straightforward way to ensure exactly
the same codebase is used in those builds.

>

Our initial plans for the next version (3.0) of TeamCity include
addressing the cases like you describe: running builds on several
platforms and reporting the combined result.

>

One of the possible approaches is enhancing build dependencies
(build the same sources) and some sort of container build
configurations that will represent the combined status of a build
for all dependent configurations (that can run on different platforms).

>

BTW what would you prefer for your project: having one build
configuration and some simple setting like "run on <list of platforms>"
or ability to fine-tune a build configuration for each platform
individually?


Our project contains a number of different build configuration, such as
Java Components, VC 6.0, VC 7.1, GCC 3.4-64, GCC 3.4. These
components should ideally be built from the same revision. If building
succeeds then we wish to use the artefacts in dependent builds, e.g
install kit.

The best solution for us would be to have a container build configuration
that gathers the different component configurations. All components
within a container should build from the same revision. The install kit
build should be dependent on the container configuration.

Another solution would be that dependent builds automatically use the
same revision as the build they are depending on. That way you could
have a dummy trigger build that all components are dependent on.

/Mikael


0

I think what I'm going to try to do is write a custom VCS plugin to create a branch for my new build that includes all directories as svn:externals with the "-r" revision attribute specified. That way an update or checkout will guarantee all source at the same revision.

0

Please sign in to leave a comment.