-
Bug
-
Resolution: Duplicate
-
Critical
-
None
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.
- duplicates
-
JENKINS-27332 git-plugin no longer detects changes of branch with /
-
- Closed
-