Pre-tested check-in and direct project dependencies

Hi,

I have some problems understanding depency mechanism combined with pre-tested check-in:

Let's assume we physically have project A and B: In project A there is a util class with a method that returns a boolean. There is also a unit test that checks the returned value in the same project.

Besides that there is also a test in project B that uses this util class and also checks the return value. Project B is dependent on project A.

If I decide to change the return value in the util class, let's say it returns false instead of true, the pre-tested commit fails as expected because the corresponding test in the same project fails.

After that I corrected the test in the same project and the commit succeeds. The only problem is, that there is still a test in project B that should fail but isn't considered at all.

My question now is: How can I achieve, that commits only succeed if the tests of the own project and all it's child projects that do have direct dependencies are successful? In our case we have one huge applications that has many sub projects with direct dependencies.

Thanks for your answers in advance,

u6f6o

6 comments

Could you please describe these dependencies? Do you use TeamCity snapshot dependencies for them?

0

Sure:

Project A:


Util class:

public class ArtificialUtils {
     public static boolean returnBoolean(){
           return true;
     }
}

Test class:

public class ArtificialUtilsTest {
     @Test
     public void testReturnBoolean() {
           AssertJunit.assertTrue(ArtificialUtils.returnBoolean());
     }
}

Project B:


Test class:

public class ArtificialUtilsInOtherProjectTest {
     @Test
     public void testReturnBoolean() {
           AssertJunit.assertTrue(ArtificialUtils.returnBoolean());
     }
}


Let's assume that's the current code in the repository. Both tests are valid and successful . What I want to achieve: If someone now decides to change ArtificialUtils#returnBoolean() to return false instead of true and also modifieds ArtificialUtilsTest in same project, tests of Project A will be successful but nevertheless the modifications should not be commited to the repository since the test from Project B should fail:

Project A:


Util class:

public class ArtificialUtils {
     public static boolean returnBoolean(){
           return false;
     }
}

Test class:

public class ArtificialUtilsTest {
     @Test
     public void testReturnBoolean() {
           AssertJunit.assertFalse(ArtificialUtils.returnBoolean()); // fine
     }
}

Project B:


Test class:

public class ArtificialUtilsInOtherProjectTest {
     @Test
     public void testReturnBoolean() {
           AssertJunit.assertTrue(ArtificialUtils.returnBoolean()); // should fail
     }
}

I tried to achieve this by using build trigger dependencies: Thus adding a build trigger in Project B that executes building of Project B if build of Project A is successful. In general this works and Project B fails but nevertheless my modifications where committed to the repository since the tests of Project A were successful. I played around with snapshot dependencies a bit but didn't achieve my goal so far.

Hope that helps, let me know if you need any further information

0

Well, it is better to use snapshot dependencies here (i.e. Project B must depend on Project A by snapshot dependency) because it guarantees sources synchronization. While build A is running, more changes can be committed to both B and A projects. With build trigger dependency build of B project will take all detected changes. With snapshot dependency it will take same sources which were used to build A (or if VCS roots are different, the sources on the same date are used).

But in case of snapshot dependencies remote run builds must be started in Project B. In this case TC will create remote runs for B and A, B will wait till A finishes, then B will start and fail and commit will not be done.

0

Thanks for you answer and advise, but nevertheless I don't see how to achieve the goal: We want to use the Eclipse TeamCity Plugin to manage (pre-tested) commits. If I understand you right, we would have to manually trigger builds on Project B if we modify source code in Project A that also has influences on Project B because otherwise the project dependencies receive no attention?

Maybe I don't see the point, but my assumption was that we simply have to run the tests for the current commit remotely with the help of the Eclipse plugin and that the source code is only commited to the repository if all tests of the "hosting" project and it's dependants succeed?

Following the examples from above, this would look like:

1. Modifications in Project a "commited" with help of Eclipse TeamCity plugin
2. Project A and Project B are in the build chain because Project B depends on Project A
3. Build on Project A is executed
4. Build on Project B is executed if build of Project A succeded
5. If the both builds succeed, the source code is commited to the repository

Can we do this as mentioned or do you recommend some other approach?

0

Ulf,

Pavel is out of the office now, so I will take over.

As I understand, you want both build configuration A and B to verify your change before the commit. If both build configuraitons get the util class from the version control and compile it, you can check both A and B when you send a pre-tested commit from Eclipse and the change will be committed only when both builds succeed.

If B obtains the class file from artifact dependency, you have an option to snapshot-depend B from A and in thie case you can mark only B to verify the change when you send remote run, as A will be run automatically.

The 1-5 steps you described look fine if you use snapshot dependency.

0

Thanks for your response! Regretfully I didn't have the time to test this on my sample projects at home but I'll get back to you as soon as I set up the test environment.

0

Please sign in to leave a comment.