Builds for the default branch skip triggering despite having file changes under the trigger rule
Hi,
I have a deployment template that has some file filter settings in the VCS trigger rules. It is used for changes in PR and in master (default) branch.
When developers commit their changes to the PR, this trigger works well and as it's supposed to work (it triggers only if the PR contains files that match the trigger rule).
But when this PR is merged to master, TeamCity ignores the merge commit with this record in the log:
[2024-08-09 09:55:27,648] INFO - uildServer.TRIGGERS.vcsTrigger - MyCompany_Docker_DeployFrontendProd: [<default>] There are new pending changes found, but none of them were matched by triggering rules: [+:/frontend/**, +:/frontend_static/**, +:/assets/**, +:/backoffice/frontend/**], skip triggeringBut as you can see, this commit does contain files in the frontend directory
This happens only for the default branch and works well for the merge branches.
Is this a bug or misconfiguration in my setup?
Please sign in to leave a comment.
Hi Ivan,
It appears that your issue is similar to the one described in this thread(https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360003487580-TeamCity-does-not-trigger-build-of-default-branch-build-after-a-merge).
Could you please try adding the parameter
teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranchto your build configuration and set it totrue?Best Regards,
Tom
Hi Tom,
Thank you for you response. I went to the Build configuration → Parameters → Configuration Parameters and added
teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch = true. Is that right?Unfortunately that didn't help. About ⅓ of the builds for master still skip their trigger.
Let me add some details.
We have a mono repository with, roughly speaking, three directories:
There are three templates in the Teamcity:
Each of these templates is attached to two builds:
+:refs/pull/(*)/merge. This is being limited on a VCS branch filter level, not on a trigger level)The problem is that with ~30% probability Backend and Frontend builds don't trigger on commits where PR are merged into master even if there are changes in the /backend/ or /frontend/ directories.
This is true for both builds: Staging and Prod. And there is no problem with Meta, where are no file filters.
As I understand, the
runBuildOnSameRevisionInEveryBranchcan have sense for the Staging builds (but it didn't helped though), but it is not relevant to the Production builds because they couldn't have same revisions in other branches, since they follow only one branch (master).I would appreciate any help with this. Please let me know if I can provide you with any additional information.
Kind regards,
Ivan
The core issue seems to be that the merges are fast-forward, with the commits having already been built on the default branch. Since the default branch is treated differently, the trigger doesn’t find any pending commits to build, as they’re already on the default branch.
One workaround is to set a different branch as the default to avoid this behavior. Alternatively, preventing fast-forward merges would ensure that the new merge commit is unique, forcing a build on the new state of the branch.
Hi Tom,
Thank you for your help. Much appreciated.
But judging by the logs, it does find pending changes. It just can't find files matching the triggering rule:
[<default>] There are new pending changes found, but none of them were matched by triggering rules: [+:/frontend/**, +:/frontend_static/**, +:/assets/**, +:/backoffice/frontend/**], skip triggeringAlso there is no issues with the Meta builds. And the only difference between Meta and Backend/Frontend build is that Meta doesn't have VCS file filters. They follow the same VCS with the same branch configuration.
And if I remove the filter from the Backend/Frontend build, they start working too.
Kind regards,
Ivan