Git PullRequest job failed. Couldn't find any

Question

Yesterday my pullrequest jobs failed with the following output:

11:07:41  > git rev-parse origin/${sha1}^{commit}
11:07:41  > git rev-parse ${sha1}^{commit}
11:07:41 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

I have made an investigation and saw that in property ${sha1} there was nothing. When i paste an absolute path to pull request builder like pr/341/merge instead of ${sha1} the build works. What it can be?

Git Client Plugin 1.9.0

GitHub API Plugin 1.44

Answer 1

sometimes this happens if "Branch Specifier" is not set properly. I corrected specifier and it worked for me.

*/release/release4.5.0

or

*/feature/myfeature

Answer 2

I had the same problem. TIn my case, the cause was that I used a github repository that was a mirror of an svn repository (because svn is not properly supported by SonarCloud). The default in Jenkins was */master. The solution (found by Gavin McDonald of Apache INFRA) was to use */trunk. Another problem is the ".git" in the URL, that should not be used.

Answer 3

After lots of research and head breaking. I was receiving the same error and I found out that this error also occurs if you are using a different git path. Make sure you have the correct path. For ex: I replaced C:\Program Files\Git\git-bash.exe with C:\Program Files\Git\bin\git.exe and this resolved the issue.

Answer 4

As stated here, If you want to manually build the job, in the job setting check This build is parameterized and add string parameter named sha1 with a default value of master. When starting build give the sha1 parameter commit id you want to build or refname (eg: origin/pr/9/head).

Answer 5

I fixed this same error message by using the refs/heads/<branchName> syntax in the "Branches to build - branch specifier".

For example, instead of origin/master, I put refs/remotes/origin/master as the branch specifier to fix the job.

(In my case, I'm not sure what caused this error message to appear, as the job was previously working fine with just origin/master as the branch specifier. It may have been a related update or configuration change...)

---

Note that you can use git show-ref command to list references in a local repository, e.g.

git show-ref master
28f1f186807d1316bf1c59631d6d8825a5087e27 refs/heads/master
28f1f186807d1316bf1c59631d6d8825a5087e27 refs/remotes/origin/master

Also, the "?" help documentation next to 'Branch Specifier' field also supports this answer as the safest option for specifying the branch specifier to make sure the expected branch is unambiguous:

Specify the branches if you'd like to track a specific branch in a repository. If left blank, all branches will be examined for changes and built.

The safest way is to use the refs/heads/<branchName> syntax. This way the expected branch is unambiguous.

Possible options:

<branchName>
Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one. Better use refs/heads/<branchName>.
E.g. master, feature1,...

refs/heads/<branchName>
Tracks/checks out the specified branch.
E.g. refs/heads/master, refs/heads/feature1/master,...

<remoteRepoName>/<branchName>
Tracks/checks out the specified branch. If ambiguous the first result is taken, which is not necessarily the expected one.
Better use refs/heads/<branchName>.
E.g. origin/master

remotes/<remoteRepoName>/<branchName>
Tracks/checks out the specified branch.
E.g. remotes/origin/master

refs/remotes/<remoteRepoName>/<branchName>
Tracks/checks out the specified branch.
E.g. refs/remotes/origin/master

<tagName>
This does not work since the tag will not be recognized as tag.
Use refs/tags/<tagName> instead.
E.g. git-2.3.0

refs/tags/<tagName>
Tracks/checks out the specified tag.
E.g. refs/tags/git-2.3.0

<commitId>
Checks out the specified commit.
E.g. 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...

${ENV_VARIABLE}
It is also possible to use environment variables. In this case the variables are evaluated and the result is used as described above.
E.g. ${TREEISH}, refs/tags/${TAGNAME},...

<Wildcards>
The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard, and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.

:<regular expression>
The syntax is of the form: :regexp. Regular expression syntax in branches to build will only build those branches whose names match the regular expression.

Answer 6

I spent a long time on this. The above comment "if I leave this field blank" worked like a charm. In SCM:
1) select Git
2) Name: origin
3) Refspec: +refs/pull/*:refs/remotes/origin/pr/*
4) Branches to build : leave blank

This solved the above error.