The repo layout wasn't my idea and it's something I have to accept. I'm trying to figure out how to deploy code for a bunch of modules that are grouped into one Git repository. Depending on what changed, I want to deploy the modules that were changed and not have to re-deploy ones that weren't changed. What I'm trying to avoid is creating a bunch of projects because we have threee environments that track three different branches in QA. BTW, the branches will change every other month so I prefer not to go this route.
I could create the five projects and use "Poll SCM," but I would need to create three set (one for each branch).
For example:
mymainrepo
- project1
- project2
- project3
- project4
- project5
What I have thus far is one master project that polls the branch I want to deploy. Technically, I would end up having 3 projects that poll three different branches (better than 15 projects). If there's a change, I would then fire off subsequent jobs against the 5 projects along with the branch name (build parameters) and have each project checkout and deploy the code. I'm stuck because I'm not sure how I can have each project only deploy code when file(s) in its folder have changed. I can get it to work as is but then all five projects would fire.
Is there a better way of handling this?