VCS Trigger Rule not working

Hi,

But I also want anything else that does not have an explicit rule to be triggering.

For example, edits on files “file1.sh” and “dev/file2.sh” must trigger a build. And I don't want to specify them all one by one. That is why a general inclusion rule should do, but maybe not like I did.

Is the order of inclusions/exclusions relevant?

Hi,

Rules are sorted according to path specificity. For example, if you have an explicit inclusion rule for /some/path, and an exclusion rule -:user=some_user:. for all paths, commits to the /some/path from some_user will be included unless you add a specific exclusion rule for this user and this path at once, like -:user=some_user:/some/path/**.

In your scenario, I think that explicitly excluding pro/proB/** from the first trigger rule and vice versa for the second one will work. Please let me know if this configuration is suitable.

Best regards,
Anton

Hi Anton,

It is not optimal, because under pro/ there could be always new files or folders being added by the team and I would need to change the rule every time this happens.

Based on the path specificity, I thought that

• by explicitly excluding pro/** (more specific than .), this would exclude everything from there
• by explicitly including pro/proA/** (more specific than pro/), this would include just pro/proA/ directory contents (and not other ones from pro/)

I thought that was the meaning of: For each file in a change the most specific rule is found (the rule matching the longest file path). The build is triggered if there is at least one file with a matching "include" rule or a file with no matching "exclude" rules.

Could you please assist?

I tried the following on the last build of project A:

+:.
-:**.md
-:comment=NOCI:**
-:dev/config_management/**
-:dev/terraform/**
-:teamcity_tools/**
-:pro/proB/**
-:pro/proC/**
-:pro/proD/**
-:pro/proE/**
+:pro/proA/**

Now, when something changes in pro/proA/,  all other project builds are triggered as well.

Hi Anton,

Nothing comes to my mind. Those builds with triggers are in a build chain that triggers the other build configurations of the same project.

So build A, build B etc. trigger builds all other builds in the respective project (A, B etc.), in a sequence (implemented with snapshot dependencies). But also every project triggers builds from a common project (let's call it project α): the first build config of e.g. project A has snapshot dependency on last build of project α. Also project α has builds running in a sequence (implemented with snapshot dependencies).

So basically if there is an edit in pro/proB/, this should trigger all builds from project α first and project B next (and no other project).

If there is an edit in a file test.txt in the root dir, this should trigger all builds from project α first and all project builds in parallel (project A, B etc.).

Please let me know if this can have something to do with this behavior.

I created a minimal example of the issue and actually found the cause of the issue which might be a bug in TeamCity or us not having read the documentation well.

So here is the setup. There are 2 projects:

Project A (with the following triggers)

VCS trigger rules:
+:.
+:pro/project_a/**
-:pro/**
Branch filter: +:*

Project B (with the following triggers)
+:.
+:pro/project_b/**
-:pro/**
Branch filter: +:*

There exist no dependencies in the projects.

And now the root of the issue:
We use one checkout rule. Same rule for both project which is:
+:. => base/sub

If this checkout rule exists then if you commit into pro/project_a then both projects are triggered even though that only “Project A” should be triggered. If the checkout rule is removed then everything works as expected. Then if you commit into pro/project_a then only “Project A” is triggered.

I exported my minimal example and uploaded it. It can be downloaded via this ID:
Upload id: 2024_03_25_2AX7hY2h3QeAHnvuNC54We (file: TeamCity_TeamcityExperiments_20240325_133510.zip)

Ok so after further experimentation I found out that if one uses a checkout rule:
+:. => base/sub

Then in the VCS trigger rules this path has to be prepended to all rules so in our case it needs to be:

Project A (with the following triggers)
+:.
+:base/sub/pro/project_a/**
-:base/sub/pro/**

Project B (with the following triggers)
+:.
+:base/sub/pro/project_b/**
-:base/sub/pro/**

Is this the intended behavior? Did I overlook this in the documentation or does this info not exist?