web-dev-qa-db-ja.com

Git PullRequestジョブが失敗しました。ビルドするリビジョンが見つかりませんでした。このジョブのリポジトリとブランチ構成を確認します

昨日、pullrequestジョブは次の出力で失敗しました：

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.

調査したところ、プロパティ$ {sha1}には何もないことがわかりました。 $ {sha1}の代わりにpr/341/mergeのようなプルリクエストビルダーへの絶対パスを貼り付けると、ビルドが機能します。それは何ですか？

Gitクライアントプラグイン1.9.0

GitHub APIプラグイン1.44

gitgithubjenkinspull-request
18
Vladimir Voitekhovski

私はこれに長い時間を費やしました。上記のコメント「このフィールドを空白のままにした場合」は魅力的でした。 SCMの場合：
1）Gitを選択します
2）名前：Origin
3）参照仕様：+refs/pull/*:refs/remotes/Origin/pr/*
4）構築するブランチ：空白のままにします

これは上記のエラーを解決しました。

14
Tammytee

前述のように ここ 、手動でジョブをビルドする場合は、ジョブ設定チェックで[このビルドはparameterizedであり、文字列を追加します] sha1という名前のパラメーターで、デフォルト値はmasterです。ビルドを開始するときに、ビルドするsha1パラメータのコミットIDまたは参照名を指定します（例：Origin/pr/9/head）。

8
xialin

「ブランチ指定子」が正しく設定されていない場合に、これが発生することがあります。私は指定子を修正し、それは私のために働いた。

*/release/release4.5.0

または

*/fetaure/myfeature
2
Satish patil

同じ問題に遭遇し、4時間を費やしましたが、ようやく解決しました。

私の場合、エラーは間違ったGit exeが原因でした。 Jenkins内で、WindowsでGit exeパスを設定しながら、cmdフォルダーの下にパスを設定します

私の場合、それはC：\ Program Files\Git\cmd\git.exeでした

それは私の問題を解決しました。

0
Harsimran Singh

「ビルドするブランチ-ブランチ指定子」のrefs/heads/<branchName>構文を使用して]同じエラーメッセージを修正しました。

たとえば、Origin/masterの代わりに、ブランチ指定子としてrefs/remotes/Origin/masterを指定して、ジョブを修正しています。

（私の場合、以前はOrigin/masterだけをブランチ指定子として使用してジョブが正常に機能していたため、このエラーメッセージが表示された原因はわかりません。関連する更新または構成の変更である可能性があります... ）

git show-ref コマンドを使用して、ローカルリポジトリ内の参照を一覧表示できることに注意してください。

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

また、「？」 'Branch Specifier'フィールドの隣にあるヘルプドキュメントは、予期されるブランチが明確であることを確認するためにブランチ指定子を指定するための最も安全なオプションとして、この回答もサポートしています。

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

たくさんの研究と頭を壊した後。同じエラーが表示されましたが、別のgitパスを使用している場合にもこのエラーが発生することがわかりました。正しいパスがあることを確認してください。例：C：\ Program Files\Git\git-bash.exeをC：\ Program Files\Git\bin\git.exeに置き換えたところ、問題。

0
Daljeeth Singh

私も同じ問題を抱えていました。私の場合、原因はsvnリポジトリーのミラーであるgithubリポジトリーを使用したことです（svnはSonarCloudで適切にサポートされていないため）。 Jenkinsのデフォルトは*/master。解決策（ Apache INFRAのGavin McDonaldによって発見 ）は*/trunk。もう1つの問題は、URL内の「.git」です。これは使用しないでください。

0
Tilman Hausherr

プルする正しいブランチを指定しないと、gitはリポジトリにあるすべてのブランチを探し、「ビルドするリビジョンが見つかりませんでした。このジョブのリポジトリとブランチ構成を確認してください。 」

私はgit pullで同じ問題に直面しており、jenkinsを使用して構成を指定していました。

空白のままにすると、masterブランチからファイルが取得されますが、何かが間違っているか、タイプミスがあると、すべてのブランチが検索され、ブランチが見つからないというエラーがスローされます。

0
Elakya