I think the git plugin sets GIT_BRANCH environment variable, so you could e.g. write it to a .properties file and use parameterized trigger to pass it to another build.
-- Sami Allen Bierbaum <abierb...@gmail.com> kirjoitti 20.8.2012 kello 18.16: > On Sun, Aug 19, 2012 at 1:11 PM, Sami Tikka <sjti...@gmail.com> wrote: >> I think it depends on how you have configured the two jobs. Jenkins does not >> carry any sort of hidden message about git branch from build to another >> build. >> > > That was the key piece of information I needed. I think I need to use > the parameterized trigger plugin so I can pass the git commit to use > from one build to the other. This causes a bit of an issue because it > means the GIT_BRANCH won't be passed from build A to build B; meaning > the build name and some of the build scripts won't have the correct > branch information. I will try to find a way to work around this > though. > >> Maybe you could share the job configurations with the list? Could you put >> them up on pastebin or gist for us to see? You can get the job configuration >> by downloading $JENKINS_URL/job/JOBNAME/config.xml >> > > I think I have the information I need for now. I will keep it in mind > for future questions though and post this information. > > Thanks for your help with my questions. It has been very helpful. > > -Allen > > >> -- Sami >> >> Allen Bierbaum <abierb...@gmail.com> kirjoitti 19.8.2012 kello 15.36: >> >>> I had the same thought but was hoping for something more concrete to >>> track down or fix. >>> >>> Just to be clear then, if a build using git triggers a downstream >>> build using "Build other projects" as a post build action then the >>> downstream build should build the same branch as the upstream? >>> >>> -Allen >>> >>> >>> On Sat, Aug 18, 2012 at 2:58 PM, Sami Tikka <sjti...@gmail.com> wrote: >>>> Maybe something has changed? Someone upgraded some Jenkins plugin or >>>> installed a new one or changed something in the job configuration. >>>> >>>> I happen to know if you install the Workspace Cleanup plugin and configure >>>> a job to use it, it deletes the workspace and that somehow causes git >>>> plugin to get confused about which changes it has already seen and often >>>> it starts building the wrong branch. >>>> >>>> -- Sami >>>> >>>> Allen Bierbaum <abierb...@gmail.com> kirjoitti 18.8.2012 kello 14.42: >>>> >>>>> Our jenkins build process has been stable and working with no problems >>>>> for the last 6 months or so. We have a build monitor job that polls >>>>> our git repository looking for changes and then triggers downstream >>>>> jobs to build the given branch (using "Build other projects" post >>>>> build action). This allows us to queue up multiple build jobs run >>>>> against the same git branch at the same time. We do it this way to >>>>> work around this known issue >>>>> (https://issues.jenkins-ci.org/browse/JENKINS-7423) and to make sure >>>>> we get all the builds we need. >>>>> >>>>> This has been working well, but sometime in the last 2 weeks it >>>>> stopped working. What we are seeing now is that the monitoring job >>>>> sees a change on a branch (ex: dev/new_featureA) but when it triggers >>>>> the downstream job, that job normally picks up a different branch to >>>>> build (ex: dev/new_featureB). >>>>> >>>>> Has anyone else seen this behavior? Is it expected? >>>>> >>>>> Note we have also tried using the parameterized trigger plugin to pass >>>>> the exact SHA hash to the downstream build. This does force the >>>>> correct commit to build, but it uses a detached HEAD, so we don't end >>>>> up with a valid GIT_BRANCH environment variable during the build. We >>>>> use the branch name as part of our build process (and as part of our >>>>> build name) so this doesn't work well for us either. If there was a >>>>> way to have the parameterized trigger pass along the correct >>>>> GIT_BRANCH environment variable then this option would probably work >>>>> great. >>>>> >>>>> -Allen >>>> >>
