best practice (or any practice) on build/artifact dependencies

This seems like a silly question, but I have trolled this list and the FAQs and TeamCity doc and am either just missing it or not getting it....

So, we have a relatively large project and I would like to create the following build configurations:

1. source build
2. unit test execution
3. code coverage
4. code inspections

What I have done to date is to create the source build configuration, copy that and insert the property Unit Test patterns. Then I copied the Unit Test configuration and flipped on the code coverage checkbox. Then I copied the source build and changed the build runner to Code Inspections.

But there has to be a better way. The problem is that if I make a change to the source build configuration I have to run around doing that in all the configurations. It seems like I should be using dependencies -- artifact dependencies? -- to accomplish what I am trying to do here. i.e. the unit test execution build forces the source build to run and then executes the unit tests. The code coverage forces the unit test build which forces... etc. However, it is not at all clear to me how you would set up a 'unit test execution' configuration using artifacts. For example, in that case I don't want/need the code to be re-pulled and bulit. So, do I select "Do not checkout" and put a build dependency on the source build configuration? Is that the intent?

Why have these build configurations? Well, the project is large enough and we have enough tests, etc. where I don't (for example) want to run all the code coverage on every check-in. That is something to schedule for each night. Same with the code inspections. We only want to trend that information nightly.

Pretty sure the way I have set it up is not the best practice. Any pointers to documentation, examples or replies appreciated.

Comment actions Permalink

Perhaps I am misreading what you are trying to do but it sounds like might want to look at the Dependencies tab on the Build Triggers page. This allows you to have Configuration B fire off immediately after Configuration A successfully completes.


Comment actions Permalink

Well, 2 and 3 can be trivially combined. There's not much reason to run the same tests both with and without coverage enable. Personally, I do 1, 2, and 3 in a single build configuration, as I want the build to fail if the unit tests don't pass.

--Dave Griffith

Comment actions Permalink

While it is true, that one probably can combine steps without a problem in this case, the question persists:

How do we configure builds that depend on each others artifacts. This can be desireable, when the builds use a lot of resources, or special resources that are only available on some agents. To give a not completly fictional example consider this chain of builds

1. compile (lengthy due to heavy code generation through Annotation Processing)
2 all Test below should use the artifacts created by 1 in order to save resources.
2 a) run simple Unit Tests
2 b) run GUI tests (can't run on all agents since it would block manual usage of that machine)
2 c) run DB tests (can run only on special agents, that have a apropriate database setup)
3 produce a code coverage report combining the coverage information from 2a,2b,2c

Are build artifacts the correct way to do this?

kind regards

Comment actions Permalink


Yes, using build artifacts and artifact dependencies is a right usage for the task. There is one important limitation for the case, though.

TeamCity runs all the builds on the current (latest) sources. So, if further builds checkout sources, they can get newer sources then that used but previous builds. The workaround here is to use pack all sources/test data in the first build (compilation) and then use it in the following builds. This can be not convenient because of overhead and no ability to display changes between the builds (e.g. the "tests" ones). Another gotcha is that there is no guarantee each compilation build will result in corresponding tests build. (Builds can be reordered in the queue, etc.)

The good news are that we are currently working on the feature to allow depending one build on another noting that they should use the same sources version. This should also allow to combine the results of several builds in a single place, aka "composite build".

The feature will be available in one of the next EAP releases.

Best regards,

Yegor Yarko
Project Manager
JetBrains, Inc
"Develop with pleasure!"


Please sign in to leave a comment.