Git PullRequest job failed. Couldn't find any revision to build. Verify the repository and branch configuration for this job

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}^{co         


        

Answer 1

According to this Github branch default name was changed from "master" to "main".

So, when creating new jobs for newly repositories you have to set "main" as the branch name instead of "master".

Note that github has way to set "master" (or any other name of your convenience) as default branch name.

Answer 2

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 3

Whenever we don't specify a correct branch to pull, the git will look for all the branches that repository has and end up throwing an error saying "Couldn't find any revision to build. Verify the repository and branch configuration for this job."

I had faced the same issue with my git pull and i was using jenkins to specify the configuration.

If we leave it to blank, it would get the files from master branch, but if something is wrong or a typo is there, it would look for all branches and throw error saying branch not found.

Answer 4

I came across the same issue and spent 4 hours into it but finally got it resolved.

In my case, error was because of wrong Git exe. Inside Jenkins, while setting Git exe path on windows, set the path under cmd folder

In my case it was C:\Program Files\Git\cmd\git.exe

It resolved my issue.

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.