Trigger filter by file present in branch
Hi,
Is it possible to filter a VCS trigger to branches that have a specific file?
I'm asking this as a perceived solution to the following problem:
We are adding a new solution to be built in an existing branch. The repo is old and there are multiple releases and old releases are actively supported so there are many task branches. The new solution is only being added to the newest release branch.
If I add a VCS root that triggers on all branches, then builds for older branches fail as the file does not exist. I cannot see a branch naming convention I can use.
I see that filters can ignore files, but I do not see a filter to enable the trigger only on branches that have this new solution file.
Ideas?
Please sign in to leave a comment.
This is a classic problem of introducing CI to a legacy repo or changing the build system on an a repo ... anybody got ideas?
Hi Robert,
The first thing to recommend would likely be to have a separate build configuration for each release (or more accurately, for each different build process that you need to maintain). This would ease the task at some level through the use of VCS Checkout rules: https://confluence.jetbrains.com/display/TCD10/VCS+Checkout+Rules. Using this rules, you can simply exclude (or explicitly include) all the folders that you need for each solution, then the builds will only trigger on changes on those folders, which are those you are looking for.
Regarding branch naming conventions, branches such as old-1.2/fix_for_security_bug, current-2.1/add_small_change, or dev-3.0/shiny_new_feature could be simply filtered by adding to the trigger all branches that are like "old-1.0/*". I don't know how many releases of the exact same product you are maintaining at the same time, but it's likely that this number should be manageable, 3 or 4 is the most common scenario I've seen, with any number of branches for each different release. In this example, you can also exclude the "old-" etc prefixes, and simply go with the numbering version, and the suffix must not be after a "/", although it's likely helpful. It would also make it much clearer when reviewing the logs of the VCS, a simple glance will tell you which branch belongs to which release, without having to track it down. Obviously this would be an issue to manage older branches, although if newer ones followed a similar models, that would make them easier to exclude from the older configurations.
By having the different build configurations, old branches would only be triggered on the old ones, thus not failing, while new ones would trigger the new build procedures. I guess this is your intention, but would like to point it out in case it helps.
There is also the option to filter on *changes* in specific files: https://confluence.jetbrains.com/display/TCD10/Configuring+VCS+Triggers#ConfiguringVCSTriggers-VCSTriggerRules but this is unlikely to filter triggers on branches if said file is not present. You could add a filter for all the folders of the new solution but that wouldn't be a surefire solution, as branches might make small changes in other files, just not the solution, and that would still trigger.
Hope any of this helps
Hi Denis,
Thank you for your good response. I did not give enough information in my question.
Separate build configurations
Dead right. We do have separate build configurations for each build. The code folders are the same for all releases in the repo. All builds typically build the same files in the same folders, albiet different versions of the files. So excluding folders does not help.
Branch naming
Yes you see the issue. But alas I cannot change the branch naming convention. So a branch bug/abc could be for a bug in any release.
Perfectly sensible suggestion but alas I cannot.
Changes in specific files
I'm with you but 99% of the files are common to all releases. The 'new' build files would only exist in the latest release branch.
Hence, in order to introduce a new build approach in a legacy systems as I described ... the only approach I can think of is to filter by the new build files being present ... which I cannot do ... darn!
Any more ideas?
Hi Robert,
I've been asking around just to make sure I hadn't missed anything. I'm afraid that this scenario is not directly supported yet, so here are some possibilities, not mutually exclusive:
-Add a first build step to your build configuration that checks whether it should be run or not. If not, you can send a service message to force the build to stop: https://confluence.jetbrains.com/display/TCD10/Build+Script+Interaction+with+TeamCity
-Write your own trigger which will make this filtering on your side: https://confluence.jetbrains.com/display/TCD10/Custom+Build+Trigger
-Send us a feature request for this to be added as an option: https://youtrack.jetbrains.com/issues/TW
If you have a number of build configurations, adding the build step might be accomplished by having a build template or a meta runner, so you don't need to configure it manually for every single build configuration, just configure it once, add it to all that need it. It would require some maintenance overhead, but as of now there aren't many other options.
Hi Denis,
I appreciate your detailed response. The first option (service message) is attractive if I can stop the build without a fail ... a cancel would be great. I'm using service messages but apart from failing the build (which would send out fail notifications to people working on old releases) I do not see an appropriate message. Which message would you recommend?
Own trigger - very interesting. I will check that out. Thank you.
I may end up raising a feature request.
Thank you.