Trigger build on changes in snapshot dependencies which have git sparse checkout pattern
Completed
Project B has an artifact and snapshot dependency on Project A. Project B has no attached VCS root, Project A is attached to a VCS root with a git sparse checkout pattern.
When setting the VCS trigger at the end of the chain (B, although B is not attached to VCS root) and setting the option *Triggers a build on changes in snapshot dependencies* I would expect that B is triggered when changes are detected in the VCS root of A (in the respective tree defined by the sparse checkout pattern).
In fact, the build is not triggered.
How should I setup the triggers/dependencies so that B is triggered?
Please sign in to leave a comment.
I have just tried to reproduce this setup; build configuration A is linked to VCS root and has single subpath allowed in VCS checkout rules, build configuration B has A as a snapshot dependency and triggers on changes in snapshot dependencies. On adding a commit which removed a file under the aforementioned subpath, whole chain was triggered as expected.
First of all, do you see any pending changes under build configuration A? (Pending Changes tab)
If no changes are displayed even though there are some on repo side:
What are the checkout rules you have set up? Could you please provide me with an example of commit which was made into one of the tracked branches and fits to sparse checkout pattern set up?
Could you please also let me know what version of TeamCity are you using?
We are using TeamCity 2019.2.1. Thank you very much for your support.
The pending changes are another issue, but probably the problems are related to each other. Build Types that had VCS sparse checkout pattern on other top-level directories (all checkout patterns are based on our top-level directories in the mono-repo) showed pending changes in directories that they are not assigned to (according to the sparse checkout rule). Let me be more precise: they showed pending changes for other non-tracked directories in the "Pending Changes" tab including commit message, but when expanding the changed file drop down, zero files were shown.
The details (with a bit more expanded example that comes closer to our situation):
Root Project
Contains VCS root definition with default branch `refs/heads/master` and a few branch specifications like `+:refs/heads/(master)` and `+:refs/heads/(develop-*)`
Project A1
Is linked to the VCS root above with sparse checkout pattern `+:ProjectA1`. ProjectA1 has no trigger.
Project A2
Is linked to the VCS root above with sparse checkout pattern `+:ProjectA2` and has a snapshot and artifact dependency on Project A1. ProjectA2 has no trigger
Project B1
Is not linked to VCS but has artifact and snapshot dependency on ProjectA1. It has a VCS trigger (although the project is not attached to a VCS root) that has "Trigger a build on changes in snapshot dependencies" set to true and a branch filter on `+:master`
Project B2
Is not linked to VCS but has artifact and snapshot dependency on ProjectA2. Trigger settings same as B1.
Having this setup and according to my understanding, a change in `.\ProjectA1\foo.txt` should trigger a build in Project B1 and B2 with their dependencies:
Unfortunately the build chain is not triggered, but pending changes are shown (as described above).
Which role plays the setting "Show changes from snapshot dependencies" with respect to VCS trigger execution in the projects above? The question is not related to schedule trigger and not related to the visibility of changes in the UI.
First of all, I have ran a few samples to provide a better picture on how TeamCity would process Git data. I`ve stayed with a minimal setup of build A linked to VCS, master branch, checkout rule "+:src/game", and B having a snapshot dependency on A with trigger on snapshot changes.
The first test was a conflicting merge from develop branch to master branch. Parent revisions were as following:
master:
src/game/affecting.txt (added, empty)
src/unaffecting.txt (added, 1 line: "testline1")
develop:
src/game/affecting.txt (added, empty)
src/unaffecting.txt (added, 1 line: "testline2")
For the both branches, these changes came as a single commit, and develop branch was based off the master before the conflicting commit. Now, while for the purposes of checkout rule nothing was changed between two revisions, merge commit reports that both of the parent revisions had changed the affecting.txt - and while this change will be shown as zero-file one, it will still trigger a build.
The second test is essentially the same as first, except that I did not create a conflict with unaffecting.txt:
master:
src/game/affecting.txt (removed)
develop:
src/game/affecting.txt (removed)The result is the same; there is, in fact, no difference file-wise between these branches, yet merge commit reports the full list of files affected by parent revisions. This merge will also be reported as a zero-file change, and will trigger a build.
A similar issue could arise if for some reason tracked branch was force-pushed into; if TeamCity revision chain would be broken (i.e. there is no way to backtrack origin revisions to the ones stored on TC side), a first of the new revisions would be picked (regardless of whether this revision includes any diff on sparse pattern-tracked folders). After this, next revision which lists changes to the tracked paths would be picked as usual.
Speaking of the "Show changes from snapshot dependencies" relation to VCS trigger, I have just confirmed with devs this option does not affect VCS trigger execution anyhow.
In regards to the build chain not triggering with pending changes available - may I ask you to provide me with:
1) screenshot of VCS trigger settings for B1 project (if there are any trigger rules, please do list them too);
2) an example of A1 change list and graph screenshot for a case when non-tracked files show up on the changes list?
You could do so via "Submit a request" button which allows to upload private file attachments.
I could make the vcs triggers work by removing the branch filter.
Could the VCS root default branch and branch specification be a problem for this? The default branch is now master (before it was refs/heads/master). In the branch spec I also have
I also have the master there, because I assume that this way I can use it as a logical branch name.
The branch specification on the trigger was "+:master" But that way it never triggered. I now removed the branch filter and it triggers successfully. I expect it to be triggered now on all branches (what I would like to avoid).
Should the branch filter be "+:master" or should it be "+:refs/heads/master"?
This settings look fine now and works as expected:
VCS configuration:
default Branch: refs/heads/master
branch specification: +:refs/heads/(develop-*)
But no branch spec that defines a logical branch name for the master branch (like +:refs/heads/(master)).
The branch filter is now "+:<default>" instead of ":+master". It looks like that the system could somehow not resolve the branch filter?
If it is not recommended to add a branch spec (for the purpose of logical name "master") I think the documentation should point that you (more). I now refer to the logical branch name "master" with the placeholder "<default>".
Hello Daniel,
I have double-checked the filter configuration and was able to reproduce the issue (i.e. changes listed as pending but filter preventing the build from starting) - my apologies for not checking that earlier. While expected behaviour would indeed be that filter +:master should capture a logical name defined in branch specification, the actual behaviour is different. (usage of <default> in filter fixes the branch mapping discrepancy)
On a closer look, this issue has already been reported as https://youtrack.jetbrains.com/issue/TW-42163; I have just reached out to devs in scope of this issue. Thank you for all the details - it is really appreciated!
Thank you too! Well done. :)