Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
None
Description
Hi,
I have a job which requires a param: to specify a branch name. Up to the version 1.1.20. In 1.2.11, when I do that. error happens like this:
Fetching changes from 1 remote Git repository
Fetching upstream changes from git@github.com:mycompany/myrepo.git
Pruning obsolete local branches
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
Recording fingerprints
An attempt to send an e-mail to empty list of recipients, ignored.
Email was triggered for: Failure
Sending email for trigger: Failure
An attempt to send an e-mail to empty list of recipients, ignored.
Notifying upstream projects of job completion
Finished: FAILURE
No clue why.
Downgrade to 1.1.20. The job back to normal.
Please see the attached files to see my config related to git
Thanks
Attachments
Issue Links
- is related to
-
-
- Closed
-
Activity
Bryan Jacobs
added a comment - 1.1.21 was broken for me as well. I created this patch, which appears to resolve the issue.
The git plugin is trying to be too smart about what the user intended - just use the branch name as given, please, and document which format it should follow in the Jenkins-UI help.
Bryan Jacobs
added a comment - 1.1.21 was broken for me as well. I created this patch, which appears to resolve the issue.
The git plugin is trying to be too smart about what the user intended - just use the branch name as given, please, and document which format it should follow in the Jenkins-UI help. 
Björn Steinbrink
added a comment - That patch looks almost right. I've been using the <remote>/<head> format shown in the UI help, e.g. origin/master, which would AFAICT not be fixed by your patch. Maybe checking whether "refs/remotes/" + singleBranch is a valid ref in addition to the refs/ prefix check could work?
Björn Steinbrink
added a comment - That patch looks almost right. I've been using the <remote>/<head> format shown in the UI help, e.g. origin/master , which would AFAICT not be fixed by your patch. Maybe checking whether "refs/remotes/" + singleBranch is a valid ref in addition to the refs/ prefix check could work? I just committed a fix to JENKINS-14480 that seems to fix this issue.
Any chance you build a snapshot an test this also fixes your issue ?
Bryan Jacobs
added a comment - That patch looks good, but upon applying it, I got the dreaded "ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job." message.
My repository looks like this:
remotes/target/HEAD -> target/master
remotes/target/changes/23/23/1
remotes/target/master
remotes/upstream/heads/master
The branch "target/changes/23/23/1" is supposed to be merged with "upstream/heads/master" before building. The repository got this way by specifying the same remote repo twice with two different refspecs.
I tried setting the "target branch" to "remotes/target/changes/23/23/1", "changes/23/23/1", and "refs/remotes/target/changes/23/23/1", and "target/changes/23/23/1". None worked.
Bryan Jacobs
added a comment - That patch looks good, but upon applying it, I got the dreaded "ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job." message.
My repository looks like this:
remotes/target/HEAD -> target/master
remotes/target/changes/23/23/1
remotes/target/master
remotes/upstream/heads/master
The branch "target/changes/23/23/1" is supposed to be merged with "upstream/heads/master" before building. The repository got this way by specifying the same remote repo twice with two different refspecs.
I tried setting the "target branch" to "remotes/target/changes/23/23/1", "changes/23/23/1", and "refs/remotes/target/changes/23/23/1", and "target/changes/23/23/1". None worked. Bryan Jacobs
added a comment - I've created another patch, based off 2283620895c888f5f02f06fcac2fb33f1def0691 .
Apparently, the problem is the use of a build parameter in the "branch to build" field. I have a series of jobs which should all run on the same target revision; the first one is kicked off by an automated system, and it passes the "revision to test" into the later ones as a parameter. This change punts along the environment and uses it to expand variables where necessary.
I am unsure why matching a pattern against an exactly equal string seems to fail, but I put in a direct .equals() check to handle that case. If you can figure out why it's necessary and fix it better, I'd appreciate it.
With this patch I have no further issues with the git-scm plugin.
Bryan Jacobs
added a comment - I've created another patch, based off 2283620895c888f5f02f06fcac2fb33f1def0691 .
Apparently, the problem is the use of a build parameter in the "branch to build" field. I have a series of jobs which should all run on the same target revision; the first one is kicked off by an automated system, and it passes the "revision to test" into the later ones as a parameter. This change punts along the environment and uses it to expand variables where necessary.
I am unsure why matching a pattern against an exactly equal string seems to fail, but I put in a direct .equals() check to handle that case. If you can figure out why it's necessary and fix it better, I'd appreciate it.
With this patch I have no further issues with the git-scm plugin. 
Rusty Gerard
added a comment - I'm also encountering this issue running Jenkins on RHEL 6 after upgrading the git plugin from 1.5.0 to 2.0.1. I've had to roll back to 1.5.0.
Rusty Gerard
added a comment - I'm also encountering this issue running Jenkins on RHEL 6 after upgrading the git plugin from 1.5.0 to 2.0.1. I've had to roll back to 1.5.0. 
Same thing happened to me (no job configuration changes); had to roll back.