web-dev-qa-db-fra.com

La tâche Git PullRequest a échoué. Impossible de trouver une révision à construire. Vérifiez le référentiel et la configuration de la branche pour ce travail

Hier, mes jobs pullrequest ont échoué avec la sortie suivante:

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.

J'ai fait une enquête et j'ai vu que dans la propriété $ {sha1} il n'y avait rien. Lorsque je colle un chemin absolu pour extraire le générateur de demandes comme pr/341/merge au lieu de $ {sha1}, la construction fonctionne. Qu'est-ce que ça peut être?

Plugin client Git 1.9.0

Plugin API GitHub 1.44

gitgithubjenkinspull-request
18
Vladimir Voitekhovski

J'ai passé beaucoup de temps là-dessus. Le commentaire ci-dessus "si je laisse ce champ vide" a fonctionné comme un charme. Dans SCM:
1) sélectionnez Git
2) Nom: Origin
3) Refspec: +refs/pull/*:refs/remotes/Origin/pr/*
4) Branches à construire: laisser en blanc

Cela a résolu l'erreur ci-dessus.

14
Tammytee

Comme indiqué ici , si vous souhaitez créer manuellement le travail, dans la configuration du travail, vérifiez Cette construction est paramétrée et ajoutez une chaîne paramètre nommé sha1 avec une valeur par défaut de master. Au démarrage de la construction, donnez le paramètre de validation sha1 que vous voulez construire ou refname (par exemple: Origin/pr/9/head).

8
xialin

cela se produit parfois si "Branch Specifier" n'est pas défini correctement. J'ai corrigé le spécificateur et cela a fonctionné pour moi.

*/release/release4.5.0

ou

*/fetaure/myfeature
2
Satish patil

Je suis tombé sur le même problème et y ai passé 4 heures, mais j'ai finalement résolu le problème.

Dans mon cas, l'erreur était due à un mauvais exe Git. Dans Jenkins, tout en définissant le chemin Git exe sur Windows, définissez le chemin sous le dossier cmd

Dans mon cas, c'était C:\Program Files\Git\cmd\git.exe

Cela a résolu mon problème.

0
Harsimran Singh

J'ai corrigé ce même message d'erreur en en utilisant le refs/heads/<branchName> syntaxe dans "Branches à construire - spécificateur de branche" .

Par exemple, au lieu de Origin/master, Je mets refs/remotes/Origin/master comme spécificateur de branche pour corriger le travail.

(Dans mon cas, je ne sais pas ce qui a provoqué l'apparition de ce message d'erreur, car le travail fonctionnait correctement auparavant avec juste Origin/master comme spécificateur de branche. Il peut s'agir d'une mise à jour ou d'un changement de configuration connexe ...)

Notez que vous pouvez utiliser git show-ref commande pour répertorier les références dans un référentiel local, par exemple.

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

Également "?" la documentation d'aide à côté du champ "Spécificateur de branche" prend également en charge cette réponse comme l'option la plus sûre pour spécifier le spécificateur de branche pour vous assurer que la branche attendue est sans ambiguïté:

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.
0
sonny

Après beaucoup de recherches et de casse-tête. Je recevais la même erreur et j'ai découvert que cette erreur se produit également si vous utilisez un chemin git différent. Assurez-vous d'avoir le bon chemin. Par exemple: j'ai remplacé C:\Program Files\Git\git-bash.exe par C:\Program Files\Git\bin\git.exe et cela a résolu le problème.

0
Daljeeth Singh

J'ai eu le même problème. Dans mon cas, la cause était que j'ai utilisé un référentiel github qui était le miroir d'un référentiel svn (car svn n'est pas correctement supporté par SonarCloud). La valeur par défaut dans Jenkins était */master. La solution ( trouvée par Gavin McDonald d'Apache INFRA ) était d'utiliser */trunk. Un autre problème est le ".git" dans l'URL, qui ne devrait pas être utilisé.

0
Tilman Hausherr

Chaque fois que nous ne spécifions pas une branche correcte à extraire, le git recherchera toutes les branches du référentiel et finira par générer une erreur disant "Impossible de trouver une révision à construire. Vérifiez la configuration du référentiel et de la branche pour ce travail. "

J'avais rencontré le même problème avec mon git pull et j'utilisais jenkins pour spécifier la configuration.

Si nous le laissons vide, il obtiendrait les fichiers de la branche principale, mais si quelque chose ne va pas ou s'il y a une faute de frappe, il rechercherait toutes les branches et lancerait une erreur disant que la branche n'est pas trouvée.

0
Elakya