It would all depend on how your workspace us setup. If you haven't setup a custom workspace, then yes the code should be whatever was cloned in the preceding build step. The downstream jobs, unless you have done something yourself, don't really know about the scm, except through the upstream relationship (which only really comes into play if there are dependencies). That was a lot of typing and not a ton of information, but hopefully it helps.
Slide Sent from my Windows Phone From: Allen Bierbaum Sent: 8/19/2012 5:36 AM To: jenkinsci-users@googlegroups.com Subject: Re: Git plugin trigger of downstream is not building same branch 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 >
