Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-20427

Build Parameter variable in branch name causes polling to detect false changes in GIT

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.537
      Jenkins GIT Plugin 2.0
      Jenkins Multiple SCM Plugin 0.2
    • Similar Issues:

      Description

      Create a Job with a parameter:
      branch

      In GIT configuration set branch to:
      ${branch}
      or
      */${branch}

      This causes polling to keep detecting changes, even when there are none.

      Everything is fine when I hardcode branch name like so:
      */master

        Attachments

          Activity

          m_a_r_k_y Mark Espiritu created issue -
          Hide
          m_a_r_k_y Mark Espiritu added a comment -

          Not sure if related to JENKINS-19569.

          Show
          m_a_r_k_y Mark Espiritu added a comment - Not sure if related to JENKINS-19569 .
          Hide
          lan_wu Lan Wu added a comment -

          This is broken for us too when we upgraded from Git 1.4 to 2.0. I think it's related to this fix:
          https://issues.jenkins-ci.org/browse/JENKINS-7411

          Our parameterized build was working fine before.

          We had to go back to 1.4 to make things work.

          I'd suggest that this is not a minor bug, should be much higher.

          Show
          lan_wu Lan Wu added a comment - This is broken for us too when we upgraded from Git 1.4 to 2.0. I think it's related to this fix: https://issues.jenkins-ci.org/browse/JENKINS-7411 Our parameterized build was working fine before. We had to go back to 1.4 to make things work. I'd suggest that this is not a minor bug, should be much higher.
          Hide
          markewaite Mark Waite added a comment -

          Based on the testing of JENKINS-20969, this is fixed in git-client-plugin 1.6.2 and git-plugin 2.0.1

          Show
          markewaite Mark Waite added a comment - Based on the testing of JENKINS-20969 , this is fixed in git-client-plugin 1.6.2 and git-plugin 2.0.1
          markewaite Mark Waite made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          metyl Maciej Matys added a comment - - edited

          It still doesn't work if you specify ** or leave blank job ${branch} parameter

          Show
          metyl Maciej Matys added a comment - - edited It still doesn't work if you specify ** or leave blank job ${branch} parameter
          Hide
          markewaite Mark Waite added a comment -

          I'll need more information about your configuration (upload a copy of the job definition) and a copy of the git polling log in order to understand why it doesn't work in your case and does work in other cases. Can you upload that information?

          Show
          markewaite Mark Waite added a comment - I'll need more information about your configuration (upload a copy of the job definition) and a copy of the git polling log in order to understand why it doesn't work in your case and does work in other cases. Can you upload that information?
          Hide
          metyl Maciej Matys added a comment - - edited

          Mark,
          No problem I can upload my config tell me how do it and from where get it, generally speaking it like JENKINS-20969 I have a build parameter (string parameter) - branch name to build , which is passed to the git "Branches to build" setting. When this parameter is set to *, **, or is empty, the code checkout in last build gets built again and again instead of an updated branches. I have a trigger to poll scm.
          What I want from this job is to monitor changes in all branches and also to be run against specified branch defined by build parameter manually. Moreover then this job is trigged by upstream job or manually with branch to build parameter set to * or ** or left blank I want to rebuild all branches.

          Show
          metyl Maciej Matys added a comment - - edited Mark, No problem I can upload my config tell me how do it and from where get it, generally speaking it like JENKINS-20969 I have a build parameter (string parameter) - branch name to build , which is passed to the git "Branches to build" setting. When this parameter is set to *, **, or is empty, the code checkout in last build gets built again and again instead of an updated branches. I have a trigger to poll scm. What I want from this job is to monitor changes in all branches and also to be run against specified branch defined by build parameter manually. Moreover then this job is trigged by upstream job or manually with branch to build parameter set to * or ** or left blank I want to rebuild all branches.
          Hide
          markewaite Mark Waite added a comment -

          The config file can be downloaded to your web browser by appending /config.xml to the end of the URL of your Jenkins job. For example, I have a job named "git-client-plugin-multi". I download the job configuration file from http://localhost:8080/git-client-plugin-multi/config.xml . Once you've downloaded, then you can use the "More Actions" -> "Attach Files" operation on the bug report to attach a file.

          I believe the bug that a branch name parameter is not correctly handled by polling has already been reported, and is not yet fixed.

          I believe that your intended use model will mostly work, except for the assumption that if the build parameter is the wild card it should rebuild all branches. I think that there is no way with the git plugin to force multiple builds of unchanged branches if they've been built before. I may be wrong on that, but I've not found a way to force a rebuild of all branches when the branches had not changed since the last time they were built.

          Show
          markewaite Mark Waite added a comment - The config file can be downloaded to your web browser by appending /config.xml to the end of the URL of your Jenkins job. For example, I have a job named "git-client-plugin-multi". I download the job configuration file from http://localhost:8080/git-client-plugin-multi/config.xml . Once you've downloaded, then you can use the "More Actions" -> "Attach Files" operation on the bug report to attach a file. I believe the bug that a branch name parameter is not correctly handled by polling has already been reported, and is not yet fixed. I believe that your intended use model will mostly work, except for the assumption that if the build parameter is the wild card it should rebuild all branches. I think that there is no way with the git plugin to force multiple builds of unchanged branches if they've been built before. I may be wrong on that, but I've not found a way to force a rebuild of all branches when the branches had not changed since the last time they were built.
          Hide
          stormtau Jason Miller added a comment -

          I don't think this is fixed, or else there's been a regression (Jenkins 1.565).

          If I have a simple build that uses a BRANCH parameter that defaults to 'master', it will always trigger when notified to look for changes by Stash (via the /git/notifyCommit api), even if there's no changes.

          Git polling log looks like this:

          Started on Jun 23, 2014 2:01:35 PM
          Using strategy: Default
          [poll] Last Built Revision: Revision f22fe57691485df88098480c2e56c4e51a68ad67 (origin/master)
          using GIT_SSH to set credentials 
           > git ls-remote -h ssh://git@stash.domain.com/project/repository.git ${BRANCH}
          Done. Took 0.45 sec
          Changes found
          

          We're not using wildcards, it's just a simple string parameter with a default setting.

          Versions:
          Jenkins 1.565
          Git client plugin 1.9.1
          Git plugin 2.2.1

          Show
          stormtau Jason Miller added a comment - I don't think this is fixed, or else there's been a regression (Jenkins 1.565). If I have a simple build that uses a BRANCH parameter that defaults to 'master', it will always trigger when notified to look for changes by Stash (via the /git/notifyCommit api), even if there's no changes. Git polling log looks like this: Started on Jun 23, 2014 2:01:35 PM Using strategy: Default [poll] Last Built Revision: Revision f22fe57691485df88098480c2e56c4e51a68ad67 (origin/master) using GIT_SSH to set credentials > git ls-remote -h ssh://git@stash.domain.com/project/repository.git ${BRANCH} Done. Took 0.45 sec Changes found We're not using wildcards, it's just a simple string parameter with a default setting. Versions: Jenkins 1.565 Git client plugin 1.9.1 Git plugin 2.2.1
          Hide
          antibaconmachine Ollie Edwards added a comment - - edited

          Confirm this is still reproducible on Jenkins 1.570, git 2.2.2, git-client 1.9.1

          I've tested just a plain string

           ${BRANCH} 

          parameter which defaults to 'develop'

          If I push to another branch I see

          Started on Jul 1, 2014 1:40:05 PM
          Using strategy: Default
          [poll] Last Built Revision: Revision 582ed36314b3df24d849a92065bc2f997bebeb3e (origin/develop)
          using GIT_SSH to set credentials 
           > git ls-remote -h servicejenkins@vmrepos01:git/mfoMobileClient.git ${BRANCH}
          Done. Took 0.72 sec
          Changes found
          
          Show
          antibaconmachine Ollie Edwards added a comment - - edited Confirm this is still reproducible on Jenkins 1.570, git 2.2.2, git-client 1.9.1 I've tested just a plain string ${BRANCH} parameter which defaults to 'develop' If I push to another branch I see Started on Jul 1, 2014 1:40:05 PM Using strategy: Default [poll] Last Built Revision: Revision 582ed36314b3df24d849a92065bc2f997bebeb3e (origin/develop) using GIT_SSH to set credentials > git ls-remote -h servicejenkins@vmrepos01:git/mfoMobileClient.git ${BRANCH} Done. Took 0.72 sec Changes found
          antibaconmachine Ollie Edwards made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          drdt Don Ross added a comment - - edited

          I am seeing this same behavior after upgrading from 1.1.21 to 2.2.2.

          I noticed that the default is now to always use 'Fast remote polling'; in my production environment I have this option turned off. So, I enabled 'Force polling using workspace', and I am now seeing a different message (but the same behavior of false changes being found), as follows:

          Started on Jul 14, 2014 1:16:38 PM
          Polling SCM changes on slave-host-name
          Using strategy: Default
          [poll] Last Built Revision: Revision 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f (origin/release_branch)
           > git rev-parse --is-inside-work-tree
          Fetching changes from the remote Git repositories
           > git config remote.origin.url ssh://build@gitserver/git/product.git
          Fetching upstream changes from ssh://build@gitserver/git/product.git
           > git --version
           > git fetch --tags --progress ssh://build@gitserver/git/product.git +refs/heads/*:refs/remotes/origin/*
          Polling for changes in
           > git rev-parse "origin/release_branch^{commit}"
           > git rev-parse "release_branch^{commit}"
           > git log --full-history --no-abbrev --format=raw -M -m --raw 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f..9f74e3057c7fb30d2c001f886e394d5bea0271a
          Done. Took 1.8 sec
          Changes found
          

          It is interesting to me that the '9f74e3' commit ID in that git log command is the commit immediately before the '44bfcc7' commit. I would have expected the parameters to be in the other order.

          Show
          drdt Don Ross added a comment - - edited I am seeing this same behavior after upgrading from 1.1.21 to 2.2.2. I noticed that the default is now to always use 'Fast remote polling'; in my production environment I have this option turned off. So, I enabled 'Force polling using workspace', and I am now seeing a different message (but the same behavior of false changes being found), as follows: Started on Jul 14, 2014 1:16:38 PM Polling SCM changes on slave-host-name Using strategy: Default [poll] Last Built Revision: Revision 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f (origin/release_branch) > git rev-parse --is-inside-work-tree Fetching changes from the remote Git repositories > git config remote.origin.url ssh: //build@gitserver/git/product.git Fetching upstream changes from ssh: //build@gitserver/git/product.git > git --version > git fetch --tags --progress ssh: //build@gitserver/git/product.git +refs/heads/*:refs/remotes/origin/* Polling for changes in > git rev-parse "origin/release_branch^{commit}" > git rev-parse "release_branch^{commit}" > git log --full-history --no-abbrev --format=raw -M -m --raw 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f..9f74e3057c7fb30d2c001f886e394d5bea0271a Done. Took 1.8 sec Changes found It is interesting to me that the '9f74e3' commit ID in that git log command is the commit immediately before the '44bfcc7' commit. I would have expected the parameters to be in the other order.
          Hide
          drdt Don Ross added a comment -

          I ran these two commands on my slave and got the same results:
          > git rev-parse "origin/release_branch^

          {commit}"
          44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f
          > git rev-parse "release_branch^{commit}

          "
          9f74e3057c7fb30d2c001f886e394d5bea0271a

          It looks like the local branch is not being updated to match the remote.

          Which is not a surprise to me, since behavior in 1.1 was to check out detached, and never even create a local branch.

          Show
          drdt Don Ross added a comment - I ran these two commands on my slave and got the same results: > git rev-parse "origin/release_branch^ {commit}" 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f > git rev-parse "release_branch^{commit} " 9f74e3057c7fb30d2c001f886e394d5bea0271a It looks like the local branch is not being updated to match the remote. Which is not a surprise to me, since behavior in 1.1 was to check out detached, and never even create a local branch.
          Hide
          drdt Don Ross added a comment -

          After some fiddling and testing, I got this to work. I had to delete the local instance of the branch, at which point Jenkins started recognizing changes. So, it appears that using non-fast polling (ie, 'Force polling using workspace') is an effective workaround if you have a build parameter in the branch name.

          HOWEVER, if you have a local instance of the branch in the workspace, then non-fast polling seems to always think there are changes, irrespective of whether you have a variable or not. I will do some more testing and submit a bug report if I can get it to reproduce consistently.

          Show
          drdt Don Ross added a comment - After some fiddling and testing, I got this to work. I had to delete the local instance of the branch, at which point Jenkins started recognizing changes. So, it appears that using non-fast polling (ie, 'Force polling using workspace') is an effective workaround if you have a build parameter in the branch name. HOWEVER, if you have a local instance of the branch in the workspace, then non-fast polling seems to always think there are changes, irrespective of whether you have a variable or not. I will do some more testing and submit a bug report if I can get it to reproduce consistently.
          Hide
          daniviga Daniele Vigano added a comment -

          I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration:

          Started on Jul 17, 2014 10:50:00 AM
          Using strategy: Default
          [poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master)
          > git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch
          Done. Took 0.54 sec
          No changes

          If we disable the parametrized buildand just set 'master' as branch it works.

          Show
          daniviga Daniele Vigano added a comment - I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration: Started on Jul 17, 2014 10:50:00 AM Using strategy: Default [poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master) > git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch Done. Took 0.54 sec No changes If we disable the parametrized buildand just set 'master' as branch it works.
          Hide
          solarfly73 Derek Douville added a comment - - edited

          I've been struggling with the same problem all week.

          What I've determined is that the git plugin is either ignoring any variables created in Parameterized Build, or they are not getting passed. However, Parameterized Build can override variables the Git Plugin cares about.

          Environment:

          • Use separate directories for workspace set to $GIT_BRANCH/src
          • Delete workspace & Force Clone
          • Git Plugin: 2.2.2
          • Git Client Plugin: 1.10
          • GitHub API Plugin: 1.55
          • GitHub Plugin: 1.90

          Test Case 1: Override GIT_BRANCH
          If you create a GIT_BRANCH parameter and run a build with garbage text, you can see the github plugin use that text (by the way, overriding GIT_BRANCH is bad, because it will override all of your automatic github push triggers too). This test shows that Parameterized Build at least runs before the git plugin uses its GIT_BRANCH variable.

          Test Case 2: Create a new variable "MYBRANCH", specify $MYBRANCH as the branch to build.
          If you now run a paramarized build and set this with some garbage (eg. not a real branch), the git clone should fail. But $MYBRANCH is treated as whitespace because it doesn't exist to the git plugin, thus performing default build behavior and building the last branch to get an update.

          Test Case 3: Wrap MYBRANCH with curly braces ${MYBRANCH}
          No difference

          Test Case 4: Put garbage directly into the branch to build path
          Type "asdasd" into the branch to build and see the build fail.

          I also then added the EnvInject plugin and attempted to set the GIT_BRANCH variable from there, based on another variable's value, to no success.

          My conclusion is that the Git plugin is not evaluating any environment variables passed into the branch specifications. This basically means parameterized builds are useless.

          Show
          solarfly73 Derek Douville added a comment - - edited I've been struggling with the same problem all week. What I've determined is that the git plugin is either ignoring any variables created in Parameterized Build, or they are not getting passed. However, Parameterized Build can override variables the Git Plugin cares about. Environment: Use separate directories for workspace set to $GIT_BRANCH/src Delete workspace & Force Clone Git Plugin: 2.2.2 Git Client Plugin: 1.10 GitHub API Plugin: 1.55 GitHub Plugin: 1.90 Test Case 1: Override GIT_BRANCH If you create a GIT_BRANCH parameter and run a build with garbage text, you can see the github plugin use that text (by the way, overriding GIT_BRANCH is bad, because it will override all of your automatic github push triggers too). This test shows that Parameterized Build at least runs before the git plugin uses its GIT_BRANCH variable. Test Case 2: Create a new variable "MYBRANCH", specify $MYBRANCH as the branch to build. If you now run a paramarized build and set this with some garbage (eg. not a real branch), the git clone should fail. But $MYBRANCH is treated as whitespace because it doesn't exist to the git plugin, thus performing default build behavior and building the last branch to get an update. Test Case 3: Wrap MYBRANCH with curly braces ${MYBRANCH} No difference Test Case 4: Put garbage directly into the branch to build path Type "asdasd" into the branch to build and see the build fail. I also then added the EnvInject plugin and attempted to set the GIT_BRANCH variable from there, based on another variable's value, to no success. My conclusion is that the Git plugin is not evaluating any environment variables passed into the branch specifications. This basically means parameterized builds are useless.
          Hide
          davidm2005 David McWhorter added a comment -

          same issue for me, ${BRANCH} in Branch Specifier is ignored

          Show
          davidm2005 David McWhorter added a comment - same issue for me, ${BRANCH} in Branch Specifier is ignored
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/ea62814db213b41b0e8fe99dbca6898aa369da97
          Log:
          [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/ea62814db213b41b0e8fe99dbca6898aa369da97 Log: [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling
          Hide
          markewaite Mark Waite added a comment -

          Fixed in git plugin 2.2.7, available from update center.

          Show
          markewaite Mark Waite added a comment - Fixed in git plugin 2.2.7, available from update center.
          markewaite Mark Waite made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          markewaite Mark Waite added a comment -

          Fix included in git plugin 2.3.1, released 29 Nov 2014

          Show
          markewaite Mark Waite added a comment - Fix included in git plugin 2.3.1, released 29 Nov 2014
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04
          Log:
          [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04 Log: [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling
          Hide
          yk4ever Konstantin Yegupov added a comment -

          I'm observing the bug again, Jenkins 2.7, Git plugin 2.5.2 (see also JENKINS-29896)

          Show
          yk4ever Konstantin Yegupov added a comment - I'm observing the bug again, Jenkins 2.7, Git plugin 2.5.2 (see also JENKINS-29896 )
          Hide
          markewaite Mark Waite added a comment -

          Konstantin Yegupov can you provide more details on the case where you're seeing the problem?

          I can't duplicate the problem on my Jenkins 2.7.1 with Git plugin 2.5.2 and git client plugin 1.19.6.

          Show
          markewaite Mark Waite added a comment - Konstantin Yegupov can you provide more details on the case where you're seeing the problem? I can't duplicate the problem on my Jenkins 2.7.1 with Git plugin 2.5.2 and git client plugin 1.19.6.
          Hide
          yk4ever Konstantin Yegupov added a comment -

          So, I'm updating the Jenkins config like this:
          http://imgur.com/0H945kK

          The polling log before the change (extracted from a build, so ends with "changes found", but doesn't have to):
          http://pastebin.com/3Mv3HUQd

          The polling log after the change:
          http://pastebin.com/igztfdwu
          ...and then it starts to rebuild the same branch 495 it has just built before (not 1205).

          So, apparently, the behavior is very different depending on whether you specify BranchSpec directly as "*" or via a variable that should have the value of "*"

          Show
          yk4ever Konstantin Yegupov added a comment - So, I'm updating the Jenkins config like this: http://imgur.com/0H945kK The polling log before the change (extracted from a build, so ends with "changes found", but doesn't have to): http://pastebin.com/3Mv3HUQd The polling log after the change: http://pastebin.com/igztfdwu ...and then it starts to rebuild the same branch 495 it has just built before (not 1205). So, apparently, the behavior is very different depending on whether you specify BranchSpec directly as "* " or via a variable that should have the value of " *"
          Hide
          yk4ever Konstantin Yegupov added a comment -

          (bold unintended, should have been double asterisks)

          Show
          yk4ever Konstantin Yegupov added a comment - (bold unintended, should have been double asterisks)
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 151951 ] JNJira + In-Review [ 207118 ]
          puneeth_n Puneeth Nanjundaswamy made changes -
          Priority Minor [ 4 ] Major [ 3 ]
          Hide
          puneeth_n Puneeth Nanjundaswamy added a comment -

          @Nicolas De Loof Any updates on this? This is is a major issue for us as sometimes builds fail because of network issue and when we try to rerun, the job picks up some random branch!

          Show
          puneeth_n Puneeth Nanjundaswamy added a comment - @Nicolas De Loof Any updates on this? This is is a major issue for us as sometimes builds fail because of network issue and when we try to rerun, the job picks up some random branch!
          Hide
          markewaite Mark Waite added a comment -

          Puneeth Nanjundaswamy, Nicolas De Loof is no longer a maintainer of the git plugin. I was unable to duplicate the problem in my most recent attempt. Can you provide step by step instructions which show the failure on an "out of the box" Jenkins installation? Even better is to provide those step by step instructions and a docker image (like a bug verification job as a pull request to my lts-with-plugins docker instance).

          Every time I need to guess what a user is doing it is more time that I could have spent helping in other ways (like fixing other bugs, reviewing proposals, etc.)

          Show
          markewaite Mark Waite added a comment - Puneeth Nanjundaswamy , Nicolas De Loof is no longer a maintainer of the git plugin. I was unable to duplicate the problem in my most recent attempt. Can you provide step by step instructions which show the failure on an "out of the box" Jenkins installation? Even better is to provide those step by step instructions and a docker image (like a bug verification job as a pull request to my lts-with-plugins docker instance ). Every time I need to guess what a user is doing it is more time that I could have spent helping in other ways (like fixing other bugs, reviewing proposals, etc.)
          Hide
          puneeth_n Puneeth Nanjundaswamy added a comment -

          Mark Waite Thanks for the response. I have created a seperate JIRA ticket with all details. Here is the link: https://issues.jenkins-ci.org/browse/JENKINS-38406

          Let me know in case of more info

          Show
          puneeth_n Puneeth Nanjundaswamy added a comment - Mark Waite Thanks for the response. I have created a seperate JIRA ticket with all details. Here is the link: https://issues.jenkins-ci.org/browse/JENKINS-38406 Let me know in case of more info
          Hide
          stephen_rufle Stephen Rufle added a comment -

          I have seen this same issue with the TFS plugin used in Jenkins Multiple SCM plugin 0.5

          Show
          stephen_rufle Stephen Rufle added a comment - I have seen this same issue with the TFS plugin used in Jenkins Multiple SCM plugin 0.5
          Hide
          ataylor Alex Taylor added a comment -

          Mark Waite- I was finally able to reproduce this issue 100% if you have access to bitbucket.

          1. Have Bitbucket repository with at least 10 branches

          2. Create a freestyle job and configure it to use the git plugin but connect to a Bitbucket repository at `$BITBUCKET_URL/git/$PROJECT/$REPO.git`

          3. Add a parameter called BRANCH and has the default value of **

          4. Use that parameter in the `Branches to build` section

          5. Add a poll for changes of `* * * * *` so that it will build every minute

          6. Add a shell step of something like "echo hello"

          7. Run one build

           

          This will then launch a new build for every branch and then once that is done you will see it build every minute seeing changes.

           

          Let me know if that does not work for you because it has worked 2x for me so far.

          Show
          ataylor Alex Taylor added a comment - Mark Waite - I was finally able to reproduce this issue 100% if you have access to bitbucket. 1. Have Bitbucket repository with at least 10 branches 2. Create a freestyle job and configure it to use the git plugin but connect to a Bitbucket repository at `$BITBUCKET_URL/git/$PROJECT/$REPO.git` 3. Add a parameter called BRANCH and has the default value of ** 4. Use that parameter in the `Branches to build` section 5. Add a poll for changes of `* * * * *` so that it will build every minute 6. Add a shell step of something like "echo hello" 7. Run one build   This will then launch a new build for every branch and then once that is done you will see it build every minute seeing changes.   Let me know if that does not work for you because it has worked 2x for me so far.
          Hide
          ataylor Alex Taylor added a comment -

          See my last comment since I think it is still an issue

          Show
          ataylor Alex Taylor added a comment - See my last comment since I think it is still an issue
          ataylor Alex Taylor made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          ataylor Alex Taylor made changes -
          Assignee Nicolas De Loof [ ndeloof ] Mark Waite [ markewaite ]
          markewaite Mark Waite made changes -
          Assignee Mark Waite [ markewaite ]
          markewaite Mark Waite made changes -
          Status Reopened [ 4 ] Open [ 1 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              m_a_r_k_y Mark Espiritu
            • Votes:
              11 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated: