Interrogating what has changed in VCS

I am not sure if what I want to do is possible so I guess I am asking can I do this and if I can how?

I have a Team City server with 4 build agents across multiple machines. I am using git with feature and develop branches and a split of unit and integration tests all run using gradle. So my unit test task in gradle is called unitTest (quel suprise :-) ) and my integration test is called, you guessed it, integrationTest.

Everytime a feature branch is checked in I want to run the unitTest task for all projects (this is a multi-project gradle build), however if a particular project has changed then I want to run the integrationTest task.

As mentioned this is a multi-project gradle build with a single build for a feature branch. When a change is integrated into develop I have split each project into single builds so I have that scenario covered.

I was wondering it there is any way to identify which projects within the repository has changed and then dynamically setting the task in Team City, the task is already driven by a parameter so if someone uses the elipses to run a build they can alter the task run. Lets say that parameter is called task and we have the following project structure:

root
|-> projectA
|-> projectB
\-> projectC

a commit to any project would leave the task parameter at the default unitTest setting, however if projectB changed I could override the task parameter to be unitTest :projectB:IntegrationTest

I just don't know if it is possible to identify that projectB is the one that has changes. I do not want to break this out to run each project independently because I want gradle to handle the dependencies for me, that is what it is good at and I also want the artifacts from projectA to be used by the projectB build and we have many feature branches.

Thanks for any help.

Simon

3 comments
Comment actions Permalink

Hi Simon,

It is not a good practice to change the logic of the build inside build script. In this case it will be difficult to interpret the results of the build and also the statistics of the builds (for example average build time) will be uninformative.
You can create two separate build configurations, each one consists of all three projects. The first one will trigger if you commit to any project, the second one - if you commit to project B. You can use trigger rules to perform it, and build configuration templates to simplify the setup.

0
Comment actions Permalink

But that rather misses the point, I want a single build where gradle manages the dependencies, I do not want to create multiple builds for each project. I know exactly how to create multiple builds, one per project. I  realise the run statistics will not work and I cannot now put a failure condition on run time with any solution that changes the tasks that are executed.

I have managed to work out a way of doing this by using a grep on the generated changed files file.

0
Comment actions Permalink

Simon,

>I know exactly how to create multiple builds, one per project.
I mean to create two build configurations, both consist of three projects, not one per project.

  1. Build configuration A (root: projectA, projectB, projectC). Trigger if commit to any project. Run the unitTest.
  2. Build configuration B (root: projectA, projectB, projectC). Trigger if commit to project B. Run the integrationTest.
0

Please sign in to leave a comment.