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? -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8b9a76e8-79df-4fb8-806d-718c4e5f2bb2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
