Reputation: 30873
I have a git repo which contains a single .Net solution with several web applications (public site, internal site, public services) and a shared class library project. I want to deploy some of the projects based on the changes that were made. For example if I fixed a bug in public site I want to only deploy that site, if I fixed bug in public site and api I want to deploy both of them and so on. I can achieve it by creating different build configurations and using trigger rule and filter by Ant_like_wildcard folder path and deploy corresponding project.
The tricky case in when I make a change only in a shared class library but not in any of the web apps. In that case I have the following options:
Make a dummy change in the web apps which must be deployed
Include web projects which must be deployed in commit message and use VCS_comment_regexp for filtering triggers
Parse git commit message, set parameters using setParameter in build script and use those parameters in following steps.
I don't like any of the options because they seem hacky. Is there any better option for this case?
Upvotes: 1
Views: 702
Reputation: 141946
There are few options:
Use git hooks to "capture" the desired branch (folder/file/path whatever you need) and execute any build/deploy script that you want to execute. If you use git hub there are much more options. Git hub named those: webhooks
for example:
git diff-tree -r --name-only HEAD^1
will give you list of all modified files in the current commit. use it with grep to search for your required path.
Hope it helped you to solve your problem.
Upvotes: 0
Reputation: 1323115
If the shared class library project is referenced as a submodule of the three other webapps, that means each webapp can chose to update to the latest commit of that shared lib project repo.
That would cause the gitlink (the special entry in the index of a parent repo) to change, which would in turn make the parent repo register a new commit (referencing the new gitlink SHA1 of the submodule repo)
That would no longer be a "dummy change".
And that would be picked up by TeamCity as a webapp new change triggering the job.
Upvotes: 1