VCS Trigger unexpectedly triggers all environment builds regardless of file-specific trigger rules

[georgik98]

I'm experiencing an issue with TeamCity VCS triggers where changes to specific environment files are causing all environment builds to trigger, despite having configured file-specific trigger rules.

Current Setup:

• Multiple build configurations for different environments (prod-1, prod-2, dev-1, dev-2, staging)
• Each build configuration has specific file path triggers (e.g., /env/prod/prod-1/env.hcl)
• Using branch filter +:pull/* to include pull requests

Expected Behavior:

When a change is made to /env/prod/prod-1/env.hcl, only the prod-1 build should trigger. Similarly, when a change is made to /env/prod/prod-2/env.hcl, only the prod-2 build should trigger.

Actual Behavior:

When a change is made to any environment file (e.g., /env/prod/prod-1/env.hcl), all environment builds (prod-1, prod-2, dev-1, dev-2) are triggered. Only staging builds are correctly not triggering for some reason.

Investigation:

I've found that the branch filter +:pull/* seems to be overriding the file-specific trigger rules, causing any PR to trigger all build configurations regardless of which files were changed.
I've tried the following without success:

• Adding exclusion rules: -:/env/non-prod/dev-2/env.hcl -:/env/non-prod/dev-1/env.hcl
• Various combinations of include/exclude rules
• Removing wildcards and using exact paths

Question:

Is there a way to configure TeamCity to respect both branch filters and file-specific trigger rules, so that only the builds affected by specific file changes are triggered, even when those changes come from pull requests?

[aeisele]

Hi @georgik98, in such constellations we suggest using "checkout rules". They will ensure that TeamCity only "sees" changes for the given build configuration if they are done in an "interesting" path as according to the rules. There is a limitation to this when it comes to merge commits. Please see this ticket for more information: https://youtrack.jetbrains.com/issue/TW-24747.

As for support of pull requests, I would suggest setting up the pull requests build feature. This will add all detected pull requests to the branch spec. It will also allow you to have more control over branch filters depending on various aspects of the pull requests, then you don't need to relay on branch names for this.