TeamCity missing git PR merge commits when calculating changes (and thus post-build labelling)
I am seeing something I can't quite figure out when TC is tracking changes on a branch. Our configuration has multiple build configurations for various platforms for the project, all sourced from the same repository https://github.com/keymanapp/keyman
For our problem build configuration:
- Our VCS root is configured to pull from https://github.com/keymanapp/keyman, beta branch, and sparse checkout only 3 folders to avoid seeing changes from unrelated projects (this is the only way we seem to be able to avoid spurious builds for commits unrelated to the project):
-:.
+:resources=>keyman/resources
+:web=>keyman/web
+:windows=>keyman/windows
The problem we have is that when we merge a pull request into the beta branch (not a squash merge), we see the individual commits from the PR in the change log for the build that is triggered, but we don't see the merge commit itself. However this is only true for the final PR merge before the build runs -- if there were multiple PRs merged in a day, the earlier ones show in the log. The VCS labelling post-build illustrates the selected commits:
$ git log --pretty=oneline --abbrev-commit windows-release-beta-10.0.1104.0...windows-release-beta-10.0.1105.0
42804bf6 (tag: windows-release-beta-10.0.1105.0, tag: web-release-beta-10.0.93) Fix missing Edge browser test
62eba201 Fixes #974. Platform statement no longer sneakily does version tests.
27c565b0 Reworked several aspects of platform constraints esp. regarding unknown constraints. Rewrote keyboard and spreadsheet to facilitate testing more reliably.
8649bd48 Renamed platformtest for Android
f8427c3f Add platformtest.js to Android test harness
ff8658ed Fixes #966. Platform tests are now more consistent for KeymanWeb
6291ad83 Fixes #968. Platform tests on Android now give correct results for hardware keyboard. Partial fix for #966 (hardware keyboard in Chrome emulator).
5a2e5297 Fixes #965. 'hardware' is now supported in Keyman Desktop on Windows platform test
Each of those commits are part of pull request #969, which was merged for release 10.0.1105.0. However the merge commit that references the pull request is shown only in the pending 1106 build:
$ git log --pretty=oneline --abbrev-commit windows-release-beta-10.0.1105.0...beta
fb430c2c (HEAD -> beta, tag: ios-release-beta-10.0.155, tag: android-release-beta-10.0.399, origin/beta) Merge pull request #969 from keymanapp/platform-fixes-965-966-968-896
023f06a4 Merge pull request #972 from keymanapp/android-info-page
9129e1b3 Fix PR number in history.md
931bcdd5 Consolidate "Info" views
66d0aeb7 Merge pull request #961 from keymanapp/ios-735-allow-update-for-kb-with-mismatched-lang-id
c16e8341 (tag: ios-release-beta-10.0.154) [Mac] #735 - Changed query to get bcp-47 language IDs
a00d3f25 (origin/ios-735-allow-update-for-kb-with-mismatched-lang-id) [iOS] #735 - Allow keyboard update even if languageID not in API results
What do we need to do so that we can ensure that the merge commits that reference the PRs are correctly labelled for the build in which they actually land?
Please sign in to leave a comment.
TeamCity binds a merge commit to a build configuration if it contains files matched by checkout rules or merges more than 1 branch with changes matched by checkout rules. Both conditions are not met for the merge commit of PR#696 (fb430c2c1abe50423aad2164fd2a1c316da2f34a).
The head of PR#696 is 42804bf63a9560df98f2fea45422ed403c390df3. Commits made in PR (git log --name-status 023f06a4eb1bc0c53fb1454b49a3c14cbb25407a..42804bf63a9560df98f2fea45422ed403c390df3) contain files matched by checkout rules.
Commits made in the beta branch (git log --name-status 023f06a4eb1bc0c53fb1454b49a3c14cbb25407a..42804bf63a9560df98f2fea45422ed403c390df3) do not. According to your checkout rules there is no difference between build on commit 42804bf63a9560df98f2fea45422ed403c390df3 and build on merge commit fb430c2c1abe50423aad2164fd2a1c316da2f34a.
Thank you for the reply and explanation. I think I'm following, but I'm not sure what to do about it. So I guess the next question is, how can we change our configuration so we do include the merge commits?
Maybe you can use the default checkout rules and specify trigger rules to avoid builds on unrelated commits?
That's the route we went originally -- but we found that the trigger rules just didn't stop unrelated commits from triggering a build. It's a little difficult to track now because we made the change long enough ago (July 2017) that the logs have been purged, but we would see pull requests that touch just one file in one folder triggering builds for projects in other folders which themselves had trigger rules to ignore the folder.
This was on an older version of TC, so I don't know if something has changed recently with TC build triggers that may change this?
There is number of known issues with VCS trigger rules when trigger runs redundant builds:
https://youtrack.jetbrains.com/issue/TW-46576, https://youtrack.jetbrains.com/issue/TW-24747.
It looks like squashing PR commits before the merge is the best workaround for your setup at the moment.
One thing you can try is to switch to trigger rules and add the teamcity.vcsTrigger.analyzeFullHistoryForMergeCommits=false parameter to a build configuration. It should reduce the number of redundant builds (more details in the issue: https://youtrack.jetbrains.com/issue/TW-24747#focus=streamItem-27-814689-0-0).
Okay, thanks, we'll look into those.