Exclude specific paths during triggering TFS team build

0
votes

I'm configuring continuous integration with TFS 2012. I have one problem need solve. I need to exclude some paths from triggering builds.

For e.g. I have:

  1. $/Project1
  2. $/Project2

And I want that after each check-in of $/Project1 - build has been triggered. And it must build both $/Project1 and $/Project2. But after checking in $/Project2 I don't want to trigger a build for that Build Definition.

In Source Settings of Build Definition are only functions "Active" and "Cloaked", but it isn't what I need.

Thanks a lot in advance.

P.S. The worth solution is to add the comment ***NO_CI*** on check-in. It will be great if there is some other way.

1
tfsbuildcontinuous-integration
Why do you have two dependant project folders? Should they not be part of the same solution? - MrHinsh - Martin Hinshelwood
create 2 builds, build 1 for project 1 which then triggers build 2 for project 2 when it completes? - Just TFS
@MrHinsh, What would be changed if theses projects are under the same team project or the same solution? The problem remains. I need TFS to ignore check-ins from certain path/project and not trigger a build. But not cloaked. I need it to be built with the other projects, when they(other project) are checked-in. - Grish Meliksetyan
@JustTFS , is it possible in TFS native continuous integration tool? As far as I know there's no any dependency between TFS build definitions. Each build definition is independent item, which has it's own workflow. I know how to do it e.g. in Jenkins or Team City, but not in TFS. But if you know such a method, I'd like you share it with me. I would be highly appreciated. - Grish Meliksetyan
If in the same solution then they will both be built if needed on demand in the correct order. Then you need not care about the issue. - MrHinsh - Martin Hinshelwood

1 Answers

1
votes

Based on the comments, this boils down to an X-Y problem. You can't do what you want to do, but the reason you want to do it is because you're trying to solve the wrong problem.

You're running the UI tests at the wrong point in your dev-test cycle. UI tests should not run during a build, they should run after a release. A change to your test project should absolutely result in a build.

Someone is developing UI tests against code that's not yet in source control, which makes no sense. If someone is writing tests against code, the code should be source controlled.

I'm guessing that someone is manually pushing uncommitted code out to a dev server, which is being used by someone else to write tests. Don't do this. Use a real release management solution so that as developers write code, each check-in is automatically deployed to a dev/QA environment. Then the folks writing the UI tests will have something to test against. What's the point in writing tests against code that's in such a state of flux that the developer responsible for it isn't even sure it's worth being source controlled? That just results in spending a lot of time rewriting tests as the code evolves.

Assuming you set everything up properly, every commit of the application code will result in the current set of tests being run against the latest commit. Every commit of the test code will result in the new set of tests being run against the existing application code. The two things (application code and test code) should be coupled, and should always build together.

And one last thing, mostly opinion: UI tests are awful and serve very little utility. They are brittle, slow, and hard to maintain. I have never seen a comprehensive UI test suite actually provide value. UI tests are best served as a small set of post-release smoke tests. Business logic should be primarily unit tested, with a smaller suite of integration tests to back it up.