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

kicking off of build via curl command not working in 1.16.1 version of plugin

    XMLWordPrintable

Details

    Description

      We are migrating our old Jenkins instance to a new machine so we are moving from Jenkins 1.538 to 1.605. Our Jenkins plugin is moving from 1.5 to the latest release. We have been using a git hook to run the curl command to fire off a polling task for years now without problem. This no longer works.

      In our older version 1.3.0 we see the polling output of the job looking like (not the same job so don't take it as it doesn't work in the old one either):

      Started on Mar 18, 2015 3:38:19 PM
      Using strategy: Default
      [poll] Last Built Revision: Revision 27dca5ecda6278ef52534e2237c8875c6bcb46ff (remotes/origin/rel-5.3.7.0)
      Done. Took 1 sec
      Changes found
      

      New Instance with git 1.8.0.6 and git client 1.16.1

      Started on Mar 18, 2015 2:28:23 PM
      Using strategy: Default
      [poll] Last Built Revision: Revision 742f5171deb7fcb7a80d00174003f5ffb9b1e396 (refs/remotes/origin/release_team1)
       > /usr/local/bin/git --version # timeout=10
       > /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git # timeout=10
      Done. Took 1.6 sec
      No changes
      

      Now in the second instance there were changes and the job was imported from our old instance. We are not sure why the job is never fired off. The output "refs/remotes..." is different between the old job and the new one and not sure if that might be the issue or not.

      We have tried tweaking the branch specifier to various things but nothing seems to work.

      If I run the ls-remote by hand the output shows the sha1 changed:

      -bash-4.1$ /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git |grep release_team
      fff407f54ce3c97de851d9ba5cda1ce98ae3d931        refs/heads/release_team1
      

      We have tried doing the polling on the slaves but we don't keep our workspaces around after we build so this doesn't work if we don't already have a workspace waiting for the next poll.

      Attachments

        1. git.jpg
          git.jpg
          53 kB
        2. git2.jpg
          git2.jpg
          36 kB

        Issue Links

          Activity

            peter_kline Peter Kline created issue -
            peter_kline Peter Kline made changes -
            Field Original Value New Value
            Priority Minor [ 4 ] Critical [ 2 ]
            peter_kline Peter Kline made changes -
            Description We are migrating our old Jenkins instance to a new machine so we are moving from Jenkins 1.538 to 1.605. Our Jenkins plugin is moving from 1.5 to the latest release. We have been using a git hook to run the curl command to fire off a polling task for years now without problem. This no longer works.

            In our older version 1.5 we see the polling output of the job looking like (not the same job so don't take it as it doesn't work in the old one either):
            {code}
            Started on Mar 18, 2015 2:25:58 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 27dca5ecda6278ef52534e2237c8875c6bcb46ff (remotes/origin/rel-5.3.7.0)
            Done. Took 1.1 sec
            No changes
            {code}


            New Instance with git 1.8.0.6 and git client 1.16.1
            {code}
            Started on Mar 18, 2015 2:28:23 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 742f5171deb7fcb7a80d00174003f5ffb9b1e396 (refs/remotes/origin/release_team1)
             > /usr/local/bin/git --version # timeout=10
             > /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git # timeout=10
            Done. Took 1.6 sec
            No changes
            {code}

            Now in the second instance there were changes and the job was imported from our old instance. We are not sure why the job is never fired off. The output "refs/remotes..." is different between the old job and the new one and not sure if that might be the issue or not.

            We have tried tweaking the branch specifier to various things but nothing seems to work.

            If I run the ls-remote by hand the output shows the sha1 changed:
            {code}
            -bash-4.1$ /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git |grep release_team
            fff407f54ce3c97de851d9ba5cda1ce98ae3d931 refs/heads/release_team1
            {code}

            We are migrating our old Jenkins instance to a new machine so we are moving from Jenkins 1.538 to 1.605. Our Jenkins plugin is moving from 1.5 to the latest release. We have been using a git hook to run the curl command to fire off a polling task for years now without problem. This no longer works.

            In our older version 1.3.0 we see the polling output of the job looking like (not the same job so don't take it as it doesn't work in the old one either):
            {code}
            Started on Mar 18, 2015 2:25:58 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 27dca5ecda6278ef52534e2237c8875c6bcb46ff (remotes/origin/rel-5.3.7.0)
            Done. Took 1.1 sec
            No changes
            {code}


            New Instance with git 1.8.0.6 and git client 1.16.1
            {code}
            Started on Mar 18, 2015 2:28:23 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 742f5171deb7fcb7a80d00174003f5ffb9b1e396 (refs/remotes/origin/release_team1)
             > /usr/local/bin/git --version # timeout=10
             > /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git # timeout=10
            Done. Took 1.6 sec
            No changes
            {code}

            Now in the second instance there were changes and the job was imported from our old instance. We are not sure why the job is never fired off. The output "refs/remotes..." is different between the old job and the new one and not sure if that might be the issue or not.

            We have tried tweaking the branch specifier to various things but nothing seems to work.

            If I run the ls-remote by hand the output shows the sha1 changed:
            {code}
            -bash-4.1$ /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git |grep release_team
            fff407f54ce3c97de851d9ba5cda1ce98ae3d931 refs/heads/release_team1
            {code}

            peter_kline Peter Kline made changes -
            Summary kicking off of build via curl command not working in 2.2 version of plugin kicking off of build via curl command not working in 1.16.1 version of plugin
            peter_kline Peter Kline made changes -
            Description We are migrating our old Jenkins instance to a new machine so we are moving from Jenkins 1.538 to 1.605. Our Jenkins plugin is moving from 1.5 to the latest release. We have been using a git hook to run the curl command to fire off a polling task for years now without problem. This no longer works.

            In our older version 1.3.0 we see the polling output of the job looking like (not the same job so don't take it as it doesn't work in the old one either):
            {code}
            Started on Mar 18, 2015 2:25:58 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 27dca5ecda6278ef52534e2237c8875c6bcb46ff (remotes/origin/rel-5.3.7.0)
            Done. Took 1.1 sec
            No changes
            {code}


            New Instance with git 1.8.0.6 and git client 1.16.1
            {code}
            Started on Mar 18, 2015 2:28:23 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 742f5171deb7fcb7a80d00174003f5ffb9b1e396 (refs/remotes/origin/release_team1)
             > /usr/local/bin/git --version # timeout=10
             > /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git # timeout=10
            Done. Took 1.6 sec
            No changes
            {code}

            Now in the second instance there were changes and the job was imported from our old instance. We are not sure why the job is never fired off. The output "refs/remotes..." is different between the old job and the new one and not sure if that might be the issue or not.

            We have tried tweaking the branch specifier to various things but nothing seems to work.

            If I run the ls-remote by hand the output shows the sha1 changed:
            {code}
            -bash-4.1$ /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git |grep release_team
            fff407f54ce3c97de851d9ba5cda1ce98ae3d931 refs/heads/release_team1
            {code}

            We are migrating our old Jenkins instance to a new machine so we are moving from Jenkins 1.538 to 1.605. Our Jenkins plugin is moving from 1.5 to the latest release. We have been using a git hook to run the curl command to fire off a polling task for years now without problem. This no longer works.

            In our older version 1.3.0 we see the polling output of the job looking like (not the same job so don't take it as it doesn't work in the old one either):
            {code}
            Started on Mar 18, 2015 3:38:19 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 27dca5ecda6278ef52534e2237c8875c6bcb46ff (remotes/origin/rel-5.3.7.0)
            Done. Took 1 sec
            Changes found
            {code}


            New Instance with git 1.8.0.6 and git client 1.16.1
            {code}
            Started on Mar 18, 2015 2:28:23 PM
            Using strategy: Default
            [poll] Last Built Revision: Revision 742f5171deb7fcb7a80d00174003f5ffb9b1e396 (refs/remotes/origin/release_team1)
             > /usr/local/bin/git --version # timeout=10
             > /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git # timeout=10
            Done. Took 1.6 sec
            No changes
            {code}

            Now in the second instance there were changes and the job was imported from our old instance. We are not sure why the job is never fired off. The output "refs/remotes..." is different between the old job and the new one and not sure if that might be the issue or not.

            We have tried tweaking the branch specifier to various things but nothing seems to work.

            If I run the ls-remote by hand the output shows the sha1 changed:
            {code}
            -bash-4.1$ /usr/local/bin/git -c core.askpass=true ls-remote -h git@thoroughbred:flt/root.git |grep release_team
            fff407f54ce3c97de851d9ba5cda1ce98ae3d931 refs/heads/release_team1
            {code}

            We have tried doing the polling on the slaves but we don't keep our workspaces around after we build so this doesn't work if we don't already have a workspace waiting for the next poll.
            peter_kline Peter Kline made changes -
            Attachment git.jpg [ 28782 ]
            peter_kline Peter Kline made changes -
            Attachment git2.jpg [ 28783 ]
            peter_kline Peter Kline made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            markewaite Mark Waite made changes -
            Link This issue duplicates JENKINS-27332 [ JENKINS-27332 ]
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 161700 ] JNJira + In-Review [ 208545 ]

            People

              ndeloof Nicolas De Loof
              peter_kline Peter Kline
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: