Build Configuration - Publish + Test in separate configs.

My current project setup is as such:

- Software Project
- Test Project

Right now we have two build configurations:

- Software Build and Test (builds both projects and tests)
- Software Test (Builds 2nd project and tests)

Currently I use NANT to do all the tasks required for testing.

Now we use in-browser testing, which can be awfully picky, and can involve lots of revisions, what I'd like to do is remove test from the first project and make a build trigger on the test (easy enough) to run when the software build is done.

However, I would like the test results that were explicitly run after the software build configuration ran to show up in the software build status, that way the 10-15 rapid changes to the test suite to get it to properly run certain browser events doesn't get crammed into the main report for the software build configuration.

Any ideas? It's more of a preference thing so if I can't get reports to be pushed to the software build configuration I'll probably just set them up seperate and just track them some other way.

It would be nice because I'm only really interested in the most recent test run against the most current software build, but there isn't really a way to link them up.

Comment actions Permalink

Hi William

When you split compilation and tests into separate configurations, then each step does its own job.
So, the test configuration indicates that both parts of a build process completed successfully or not.

Please take a look at TW-2576, it seems simillar to your request.

A workaround for now, is to include both VCS roots in test configuration.


Comment actions Permalink

After looking at the example TeamCity config on the JetBrains site and working my configurations as Trunk/Test for the past few days I've realized my request is quite unnessicary and having them seperate configurations with triggers works great.

Looking at the ticket though, it seems to be sort of the opposite of what I want, when trying to do build/test as a single config, I'll end up with a handful of changes in the software's main trunk, and pages of changes fighting with our in-browser testing (hmm, that's saying something that probably should be fixed with our testing, huh? And yeah, pre-commit testing would be nice, but we're stuck on Visual Source Safe), I wanted to split the two configs, but wanted the testing report related to the build number of the primary project.

As it is right now, build 1.0.15 could relate to test 65, 66, 67, etc. but there is no way to tell which tests were triggered by which build number of the primary project, I wonder if we can auto-tag/comment based on a build finish trigger?

However, if tests fail we receive e-mails, and we can tell that the test has been run against the most current build at the time, tag as we need to, and move on, so not really needed so much.


Comment actions Permalink

I would suggest to link the configurations by Snapshot Dependency, not a Finish Build Trigger. It helps to synchronize source revisions in started builds.
Also, you can change test build numbers to additionally include a number of used application build. See at Dependencies Properties for details.


Comment actions Permalink

The only issue I have with that is that the test could recompile the main trunk, which I may not want it to do (as I said, in-browser testing can be finicky, I know with unit testing dependencies seem to make a lot more sense). Last thing I want to be doing is waiting on a main trunk compile so I can fix minor bugs in our testing.

Unless my understanding/configuration of snapshot dependencies are wrong.

Comment actions Permalink

It will be recomplied only if sources are changed from the last build.
If you change test code only, then artifacts from last application build are reused.


Please sign in to leave a comment.