Re: Git plugin trigger of downstream is not building same branch
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 kirjoitti 20.8.2012 kello 18.16: > On Sun, Aug 19, 2012 at 1:11 PM, Sami Tikka 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 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 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 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 >>
Re: Git plugin trigger of downstream is not building same branch
On Sun, Aug 19, 2012 at 1:11 PM, Sami Tikka 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 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 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 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 >>> >
Re: Git plugin trigger of downstream is not building same branch
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. 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 -- Sami Allen Bierbaum 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 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 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 >>
RE: Git plugin trigger of downstream is not building same branch
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 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 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 >
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 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 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 >
Re: Git plugin trigger of downstream is not building same branch
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 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
Git plugin trigger of downstream is not building same branch
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
