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 [email protected]. 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.
