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 >
