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
