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

git-plugin no longer detects changes of branch with /

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Done
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.601
      GIT client plugin 1.16.1
      GIT plugin 2.3.5
    • Similar Issues:

      Description

      git-plugin does not detect changes and thus does not trigger builds

      Git plugin used to detect changes when the specified branch was "feature/abc" but no longer does.

      Does not detect:

      Started on Mar 10, 2015 4:13:00 PM
      Using strategy: Default
      [poll] Last Built Revision: Revision 5...9 (refs/remotes/origin/feature/abc)fhuberts
      using GIT_SSH to set credentials Git Credentials
      > git --version # timeout=10
      > git ls-remote -h ssh://myserver/myproject.git # timeout=10
      Done. Took 0.81 sec
      No changes

      Does detect:

      Started on Mar 10, 2015 4:16:00 PM
      Using strategy: Default
      [poll] Last Built Revision: Revision 1...e (origin/develop)
      > git --version # timeout=10
      > git ls-remote -h ssh://myserver/otherproject.git # timeout=10
      [poll] Latest remote head revision on origin/develop is: 1...e - already built by 81
      Done. Took 0.8 sec
      No changes

      Workaround:
      Revert to GIT Plugin 2.3.4

        Attachments

          Issue Links

            Activity

            thomassuckow Thomas Suckow created issue -
            Hide
            wliu Winston Liu added a comment -

            I can replicate this using /refs/heads/stable where stable is the branch name I want Jenkins to build against. The /refs/heads/ part is included because that's what's suggested in the documentation, but it doesn't seem to work . Something like */master does work though. This used to work until a few weeks ago.

            Not sure if this is the same bug (or if it's simply user error) because I'm not that proficient at Git. The fact that it used to work though led me to comment on this.

            Jenkins 1.602
            Git Client Plugin 1.16.1
            Git Plugin 2.3.5

            Show
            wliu Winston Liu added a comment - I can replicate this using /refs/heads/stable where stable is the branch name I want Jenkins to build against. The /refs/heads/ part is included because that's what's suggested in the documentation, but it doesn't seem to work . Something like */master does work though. This used to work until a few weeks ago. Not sure if this is the same bug (or if it's simply user error) because I'm not that proficient at Git. The fact that it used to work though led me to comment on this. Jenkins 1.602 Git Client Plugin 1.16.1 Git Plugin 2.3.5
            Hide
            dphilpot Dennis Philpot added a comment -

            Hi,

            i can confirm this issue, Downgrading Plugins should do as workaround.

            Downgrade to
            Git Client Plugin 1.15.0
            Git Plugin 2.3.4

            Show
            dphilpot Dennis Philpot added a comment - Hi, i can confirm this issue, Downgrading Plugins should do as workaround. Downgrade to Git Client Plugin 1.15.0 Git Plugin 2.3.4
            Hide
            alparras Albert Parra added a comment -

            Hi,

            To workaround this issue you must downgrade the Git Plugin to 2.3.4. Downgrading Git Client Plugin is not required.

            When i look at my polling log, the ls-remote command is missing the branch name, maybe that is causing the issue.

            Show
            alparras Albert Parra added a comment - Hi, To workaround this issue you must downgrade the Git Plugin to 2.3.4. Downgrading Git Client Plugin is not required. When i look at my polling log, the ls-remote command is missing the branch name, maybe that is causing the issue.
            Hide
            dphilpot Dennis Philpot added a comment -

            Confirmed, my bad only the Git Plugin ist needed.

            Show
            dphilpot Dennis Philpot added a comment - Confirmed, my bad only the Git Plugin ist needed.
            Hide
            alparras Albert Parra added a comment -

            I found a better workaround: you must add origin to your branch field in configuration.
            Previously i had "feature/jira-0000" and polling didn't work.
            Now i have "origin/feature/jira-000" and polling is working fine.

            I checked the source code and compareRemoteRevisionWithImpl is adding the remote name to the heads before doing the comparison against the configured branch but the pattern matcher is not checking if the branch is missing the origin (like it does with refs/ ).

            Show
            alparras Albert Parra added a comment - I found a better workaround: you must add origin to your branch field in configuration. Previously i had "feature/jira-0000" and polling didn't work. Now i have "origin/feature/jira-000" and polling is working fine. I checked the source code and compareRemoteRevisionWithImpl is adding the remote name to the heads before doing the comparison against the configured branch but the pattern matcher is not checking if the branch is missing the origin (like it does with refs/ ).
            Hide
            alparras Albert Parra added a comment - - edited

            Ok, finally i figure out what is happening.

            1. compareRemoteRevisionWithImpl adds remote name to each branch got from that remote (GitSCM.java:586)
            2. getPattern add */ to the branch name, if it doesn't contain * or /
            // if an unqualified branch was given add a "*/" so it will match branches
            // from remote repositories as the user probably intended
            In our case, our branch name contains /, then */ is not added. (BranchSpec.java:117)
            3. remoteName+remoteBranch is compared against our branchName, it doesn't match.

            Proposed fix:
            update line BranchSpec.java:126 to
            builder.append("(refs/heads/|refs/remotes/|remotes/|origin/)?");
            with that fix, i think that block from line 116 to 120 will be not longer needed.

            I'm working on a branch for this.

            Cheers

            Show
            alparras Albert Parra added a comment - - edited Ok, finally i figure out what is happening. 1. compareRemoteRevisionWithImpl adds remote name to each branch got from that remote (GitSCM.java:586) 2. getPattern add */ to the branch name, if it doesn't contain * or / // if an unqualified branch was given add a "*/" so it will match branches // from remote repositories as the user probably intended In our case, our branch name contains /, then */ is not added. (BranchSpec.java:117) 3. remoteName+remoteBranch is compared against our branchName, it doesn't match. Proposed fix: update line BranchSpec.java:126 to builder.append("(refs/heads/|refs/remotes/|remotes/|origin/)?"); with that fix, i think that block from line 116 to 120 will be not longer needed. I'm working on a branch for this. Cheers
            markewaite Mark Waite made changes -
            Field Original Value New Value
            Link This issue is duplicated by JENKINS-27491 [ JENKINS-27491 ]
            Hide
            exodus Oleksandr Chyrkov added a comment -

            We use job trigger by post-receive hook and try to retrieve source from "feature/test" branch.
            There was same issue with changes. Albert's advise help. origin/feature/test works fine.

            Show
            exodus Oleksandr Chyrkov added a comment - We use job trigger by post-receive hook and try to retrieve source from "feature/test" branch. There was same issue with changes. Albert's advise help. origin/feature/test works fine.
            Hide
            thomassuckow Thomas Suckow added a comment -

            JENKINS-28506 has a regression in 2.3.5 that breaks /refs/heads/foo/bar syntax. I believe foo/bar should also work.

            Nicolas, this issue should probably be marked resolved. Do you agree?

            Show
            thomassuckow Thomas Suckow added a comment - JENKINS-28506 has a regression in 2.3.5 that breaks /refs/heads/foo/bar syntax. I believe foo/bar should also work. Nicolas, this issue should probably be marked resolved. Do you agree?
            Hide
            holsky Holger Schmeisky added a comment -

            Albert Parra are you still working on this? If not I can prepare the branch too

            Show
            holsky Holger Schmeisky added a comment - Albert Parra are you still working on this? If not I can prepare the branch too
            Hide
            markewaite Mark Waite added a comment - - edited

            Rather than preparing a proposed fix, would you be willing to evaluate the current changes which are on the master branch?

            The git plugin and git client plugin are being tested in hopes of releasing new versions before the end of June. If you're willing to assist with the testing, please download and install a pre-release build of the git client plugin and the git plugin. Problems detected in the pre-release should be e-mailed to Mark Waite and Nicolas De Loof.

            I wrote some test ideas if you would like suggestions of areas that need testing. The git plugin supports many different use cases and its automated tests only evaluate a very few of those use cases.

            Show
            markewaite Mark Waite added a comment - - edited Rather than preparing a proposed fix, would you be willing to evaluate the current changes which are on the master branch? The git plugin and git client plugin are being tested in hopes of releasing new versions before the end of June. If you're willing to assist with the testing, please download and install a pre-release build of the git client plugin and the git plugin . Problems detected in the pre-release should be e-mailed to Mark Waite and Nicolas De Loof . I wrote some test ideas if you would like suggestions of areas that need testing. The git plugin supports many different use cases and its automated tests only evaluate a very few of those use cases.
            Hide
            alparras Albert Parra added a comment -

            i prepared a fix, and used it on my server, but in the current version (1.17.1) the problem is "solved".
            "solved" because the feature/xxx branches are working at polling, but now the "remotes/origin/xxx" branches are failing to catch the updates on polling step.
            Now i'm using the official release, but i'll send the unit test i wrote for this to Mark.

            Show
            alparras Albert Parra added a comment - i prepared a fix, and used it on my server, but in the current version (1.17.1) the problem is "solved". "solved" because the feature/xxx branches are working at polling, but now the "remotes/origin/xxx" branches are failing to catch the updates on polling step. Now i'm using the official release, but i'll send the unit test i wrote for this to Mark.
            gustave Gustave Laville made changes -
            Link This issue is related to JENKINS-28911 [ JENKINS-28911 ]
            bcooksley Ben Cooksley made changes -
            Priority Major [ 3 ] Blocker [ 1 ]
            Hide
            bcooksley Ben Cooksley added a comment -

            Can we please have an update on this? It is causing severe issues for the KDE project, as it breaks our commit hook which our current iteration of Jenkins relies upon.

            Simply forcing builds to occur when pushes are done is incredibly inefficient, and not particularly possible as it wastes precious system resources. Please correct this as soon as possible.

            See https://build.kde.org/

            Show
            bcooksley Ben Cooksley added a comment - Can we please have an update on this? It is causing severe issues for the KDE project, as it breaks our commit hook which our current iteration of Jenkins relies upon. Simply forcing builds to occur when pushes are done is incredibly inefficient, and not particularly possible as it wastes precious system resources. Please correct this as soon as possible. See https://build.kde.org/
            Hide
            markewaite Mark Waite added a comment -

            Ben Cooksley did you revert to git plugin 2.3.4 and did that resolve the issue?

            Did you try the pre-release builds of the git plugin and git client plugin that are mentioned in the earlier comment?

            I believe the problem is resolved in the current development builds of the next release of the git plugin. It would be a great help to have others also confirm that the current pre-release build resolves the issue.

            Show
            markewaite Mark Waite added a comment - Ben Cooksley did you revert to git plugin 2.3.4 and did that resolve the issue? Did you try the pre-release builds of the git plugin and git client plugin that are mentioned in the earlier comment ? I believe the problem is resolved in the current development builds of the next release of the git plugin. It would be a great help to have others also confirm that the current pre-release build resolves the issue.
            Hide
            bcooksley Ben Cooksley added a comment -

            I can confirm the pre-release builds resolve the issue for me as far as I can tell at this stage.
            JIRA had automatically folded that comment out of my view for some reason
            Is there a timeline for when this will be fully released?

            Show
            bcooksley Ben Cooksley added a comment - I can confirm the pre-release builds resolve the issue for me as far as I can tell at this stage. JIRA had automatically folded that comment out of my view for some reason Is there a timeline for when this will be fully released?
            Hide
            markewaite Mark Waite added a comment -

            Very soon. I was hoping to release it by the end of June. I missed that date, but have since found a few more useful fixes for inclusion in the plugin. There is one more merge to be evaluated this weekend, then I'll deploy a pre-release copy into production at my work for a day or two. If there are no surprises from that pre-release deployment, then it release shortly after that.

            You can read more about the changes that have been evaluated in the git plugin test prioritization document that I have been using to track the work preparing for this release.

            Show
            markewaite Mark Waite added a comment - Very soon. I was hoping to release it by the end of June. I missed that date, but have since found a few more useful fixes for inclusion in the plugin. There is one more merge to be evaluated this weekend, then I'll deploy a pre-release copy into production at my work for a day or two. If there are no surprises from that pre-release deployment, then it release shortly after that. You can read more about the changes that have been evaluated in the git plugin test prioritization document that I have been using to track the work preparing for this release.
            Hide
            markewaite Mark Waite added a comment -

            Fix included in git plugin 2.4.0 released 18 July 2015

            Show
            markewaite Mark Waite added a comment - Fix included in git plugin 2.4.0 released 18 July 2015
            markewaite Mark Waite made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            Hide
            fhuberts Ferry Huberts added a comment -

            the problem seems to be back with 2.4.1

            Show
            fhuberts Ferry Huberts added a comment - the problem seems to be back with 2.4.1
            fhuberts Ferry Huberts made changes -
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            Hide
            fhuberts Ferry Huberts added a comment -

            Nuance: my jenkins with 2.4.1 does detect changes at all

            Show
            fhuberts Ferry Huberts added a comment - Nuance: my jenkins with 2.4.1 does detect changes at all
            Hide
            markewaite Mark Waite added a comment -

            Ferry Huberts I'm sorry to hear it is not working for you. I have a test case job on my Jenkins server with git plugin 2.4.1 and git client plugin 1.19.1 and it definitely responds to the post-receive trigger on the feature/abc branch when I push a commit to that branch. I also confirmed that the job monitoring the master branch on the same repository correctly is not executed when the commit is pushed to feature/abc.

            Can you provide more details to duplicate the specific problem you're seeing?

            Show
            markewaite Mark Waite added a comment - Ferry Huberts I'm sorry to hear it is not working for you. I have a test case job on my Jenkins server with git plugin 2.4.1 and git client plugin 1.19.1 and it definitely responds to the post-receive trigger on the feature/abc branch when I push a commit to that branch. I also confirmed that the job monitoring the master branch on the same repository correctly is not executed when the commit is pushed to feature/abc. Can you provide more details to duplicate the specific problem you're seeing?
            markewaite Mark Waite made changes -
            Description git-plugin does not detect changes and thus does not trigger builds

            Git plugin used to detect changes when the specified branch was "feature/abc" but no longer does.

            Does not detect:

            Started on Mar 10, 2015 4:13:00 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 5...9 (refs/remotes/origin/feature/abc)
            using GIT_SSH to set credentials Git Credentials
             > git --version # timeout=10
             > git ls-remote -h ssh://myserver/myproject.git # timeout=10
            Done. Took 0.81 sec
            No changes

            Does detect:

            Started on Mar 10, 2015 4:16:00 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 1...e (origin/develop)
             > git --version # timeout=10
             > git ls-remote -h ssh://myserver/otherproject.git # timeout=10
            [poll] Latest remote head revision on origin/develop is: 1...e - already built by 81
            Done. Took 0.8 sec
            No changes




            Workaround:
            Revert to GIT Plugin 2.3.4
            git-plugin does not detect changes and thus does not trigger builds

            Git plugin used to detect changes when the specified branch was "feature/abc" but no longer does.

            Does not detect:

            Started on Mar 10, 2015 4:13:00 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 5...9 (refs/remotes/origin/feature/abc)fhuberts
            using GIT_SSH to set credentials Git Credentials
             > git --version # timeout=10
             > git ls-remote -h ssh://myserver/myproject.git # timeout=10
            Done. Took 0.81 sec
            No changes

            Does detect:

            Started on Mar 10, 2015 4:16:00 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 1...e (origin/develop)
             > git --version # timeout=10
             > git ls-remote -h ssh://myserver/otherproject.git # timeout=10
            [poll] Latest remote head revision on origin/develop is: 1...e - already built by 81
            Done. Took 0.8 sec
            No changes




            Workaround:
            Revert to GIT Plugin 2.3.4
            Hide
            fhuberts Ferry Huberts added a comment -

            Ah I think I'm on the wrong issue here.
            My problem is that 'Recent Changes' doesn't work.
            The trigger works properly.
            Sorry for the noise, please close the issue

            Show
            fhuberts Ferry Huberts added a comment - Ah I think I'm on the wrong issue here. My problem is that 'Recent Changes' doesn't work. The trigger works properly. Sorry for the noise, please close the issue
            markewaite Mark Waite made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Done [ 10000 ]
            Hide
            jperrin James Perrin added a comment -

            Same problem here. Though git-plugin docs mention fast-remote has an issue if you don't have a master branch which I do it does explain that the old method of checking out to a workspace is a workaround which does work for me.

            https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-FastRemotePolling

            Show
            jperrin James Perrin added a comment - Same problem here. Though git-plugin docs mention fast-remote has an issue if you don't have a master branch which I do it does explain that the old method of checking out to a workspace is a workaround which does work for me. https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-FastRemotePolling
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 161537 ] JNJira + In-Review [ 196789 ]
            Hide
            rknla Kevin Nelson added a comment -

            I'm experiencing similar symptoms to the original post of this issue, leading me to think that the issue is still here in version 3.0.5.

            Particularly: Pushing a new branch named `foo/whatever` triggers correctly, but any subsequent pushes to the same branch do not get picked up and triggered.

            Branches that don't have slashes in them appear to behave just fine.

            Show
            rknla Kevin Nelson added a comment - I'm experiencing similar symptoms to the original post of this issue, leading me to think that the issue is still here in version 3.0.5. Particularly: Pushing a new branch named `foo/whatever` triggers correctly, but any subsequent pushes to the same branch do not get picked up and triggered. Branches that don't have slashes in them appear to behave just fine.
            Hide
            markewaite Mark Waite added a comment -

            Kevin Nelson can you provide more precise details to duplicate your problem? I just confirmed that the Jenkins jobs in my Docker instance correctly respond to the notifyCommit when a commit arrives on a branch whose name contains a "/".

            Steps I took while attempting to duplicate the problem:

            1. Clone, build, and run the docker instance
                $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-27332
                $ cd JENKINS-27332
                $ git lfs fetch origin origin/lts-with-plugins
                $ git checkout -b lts-with-plugins -t origin/lts-with-plugins
                $ docker build -t jenkins:JENKINS-27332 .
                $ docker run -i --rm --publish 8080:8080 jenkins:JENKINS-27332
              
            2. Connect a web browser to that docker instance (http://localhost:8080)
            3. Open the "Bugs - Individual Checks"
            4. Click "Poll Now" in the "JENKINS-29796-multi-refspec-ignored-on-poll" job
            5. Confirm in the workspace that it performed a checkout of "develop/JENKINS-29796"
            6. Commit a change to "develop/JENKINS-29796" in a repo which has a notifyCommit post-receive hook pointed at my Jenkins instance
            7. Confirm that the job ran when that notifyCommit hook was received
            Show
            markewaite Mark Waite added a comment - Kevin Nelson can you provide more precise details to duplicate your problem? I just confirmed that the Jenkins jobs in my Docker instance correctly respond to the notifyCommit when a commit arrives on a branch whose name contains a "/". Steps I took while attempting to duplicate the problem: Clone, build, and run the docker instance $ git lfs clone https: //github.com/MarkEWaite/docker-lfs JENKINS-27332 $ cd JENKINS-27332 $ git lfs fetch origin origin/lts-with-plugins $ git checkout -b lts-with-plugins -t origin/lts-with-plugins $ docker build -t jenkins:JENKINS-27332 . $ docker run -i --rm --publish 8080:8080 jenkins:JENKINS-27332 Connect a web browser to that docker instance ( http://localhost:8080 ) Open the "Bugs - Individual Checks" Click "Poll Now" in the " JENKINS-29796 -multi-refspec-ignored-on-poll" job Confirm in the workspace that it performed a checkout of "develop/ JENKINS-29796 " Commit a change to "develop/ JENKINS-29796 " in a repo which has a notifyCommit post-receive hook pointed at my Jenkins instance Confirm that the job ran when that notifyCommit hook was received
            Hide
            rknla Kevin Nelson added a comment -

            Mark Waite I'm not 100% sure where the issue is, but here is roughly what I have set up:

            1. Existing setup running Jenkins 2.32.1, Git Client 2.3.0, Git Plugin 3.0.5, GitHub Plugin 1.26.1, GitHub Branch Source Plugin 2.0.3, and a bunch of other, seemingly unrelated plugins installed (apologies that this isn't a minimal setup to reproduce – I don't have enough existing knowledge of setting up Jenkins for that to be a simple task)
            2. Create "New Item" with a GitHub Organization project type
            3. Set up the repository sources (private GitHub organization, proper credentials).. Despite what the instructions [here](https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin) say, there is no checkbox for "Build when a change is pushed to GitHub"
            4. After Saving the repository source, the organization scans, and the relevant repository also scans. During the scan, branches with a slash in them are picked up just fine. Everything gets triggered the first time.
            5. Create a new branch in the repo with a slash (for example, `feature/testing-slashes`), make a whitespace change somewhere, and push a commit
            6. Observe that this very first push does trigger a test properly.
            7. Make another whitespace change to the new branch, and commit and push that change
            8. The branch update does not trigger a test.

            I can see in the "All logs" that the GitHub webhook is arriving to Jenkins correctly for the update push, but I don't see any indication in the logs of what happens after the webhook is received.

            Another thing that I've observed is that if I navigate to the specific repository and then click on "Scan Repository", then click on "Events", I can see a "CREATED" event in response to the original push of the `feature/test-branch`, which successfully triggers the build, but there is no indication of the UPDATED event for the second push. When I update another branch that doesn't have a slash in it, I do see an UPDATED event that does successfully trigger a build.

            Hopefully this helps some. Let me know if there's any other info that I can provide (and preferably how to collect the info, since I'm still fairly new to Jenkins).

            Thanks!

            Show
            rknla Kevin Nelson added a comment - Mark Waite I'm not 100% sure where the issue is, but here is roughly what I have set up: 1. Existing setup running Jenkins 2.32.1, Git Client 2.3.0, Git Plugin 3.0.5, GitHub Plugin 1.26.1, GitHub Branch Source Plugin 2.0.3, and a bunch of other, seemingly unrelated plugins installed (apologies that this isn't a minimal setup to reproduce – I don't have enough existing knowledge of setting up Jenkins for that to be a simple task) 2. Create "New Item" with a GitHub Organization project type 3. Set up the repository sources (private GitHub organization, proper credentials).. Despite what the instructions [here] ( https://wiki.jenkins-ci.org/display/JENKINS/GitHub+Plugin ) say, there is no checkbox for "Build when a change is pushed to GitHub" 4. After Saving the repository source, the organization scans, and the relevant repository also scans. During the scan, branches with a slash in them are picked up just fine. Everything gets triggered the first time. 5. Create a new branch in the repo with a slash (for example, `feature/testing-slashes`), make a whitespace change somewhere, and push a commit 6. Observe that this very first push does trigger a test properly. 7. Make another whitespace change to the new branch, and commit and push that change 8. The branch update does not trigger a test. I can see in the "All logs" that the GitHub webhook is arriving to Jenkins correctly for the update push, but I don't see any indication in the logs of what happens after the webhook is received. Another thing that I've observed is that if I navigate to the specific repository and then click on "Scan Repository", then click on "Events", I can see a "CREATED" event in response to the original push of the `feature/test-branch`, which successfully triggers the build, but there is no indication of the UPDATED event for the second push. When I update another branch that doesn't have a slash in it, I do see an UPDATED event that does successfully trigger a build. Hopefully this helps some. Let me know if there's any other info that I can provide (and preferably how to collect the info, since I'm still fairly new to Jenkins). Thanks!
            Hide
            artem_zin Artem Zinnatullin added a comment -

            We're seeing this issue as well. We have polling setting "* * * * *" that polls repo each minute and when you push branch initially, it gets picked up in a minute. But further pushes to the branch will usually be picked up in something like 15-20 minutes which drives us crazy.

             

            This mainly happens when no other work is going on in the repo. If some other branches are changing, then chances that your already pushed branch will be picked up faster than 15-20 minutes are much higher.

             

            This looks like a state sharing + timing bug in Git Plugin. And yes, we also have "/" in branch pattern: `origin/pr/*/merge`.

            Show
            artem_zin Artem Zinnatullin added a comment - We're seeing this issue as well. We have polling setting "* * * * *" that polls repo each minute and when you push branch initially, it gets picked up in a minute. But further pushes to the branch will usually be picked up in something like 15-20 minutes which drives us crazy.   This mainly happens when no other work is going on in the repo. If some other branches are changing, then chances that your already pushed branch will be picked up faster than 15-20 minutes are much higher.   This looks like a state sharing + timing bug in Git Plugin. And yes, we also have "/" in branch pattern: `origin/pr/*/merge`.
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

              People

              • Assignee:
                ndeloof Nicolas De Loof
                Reporter:
                thomassuckow Thomas Suckow
              • Votes:
                5 Vote for this issue
                Watchers:
                18 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: