Задание 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} не было ничего. Когда я вставляю абсолютный путь для создания запроса, например, pr/341/merge вместо ${sha1}, сборка работает. Что это может быть?
Git Client Plugin 1.9.0
Плагин GitHub API 1.44
21 ответ
Я провел много времени на этом. Приведенный выше комментарий "если я оставлю это поле пустым" работал как шарм. В СКМ:
1) выберите Git
2) Имя: origin
3) Refspec: +refs/pull/*:refs/remotes/origin/pr/*
4) Филиалы для построения: оставить пустым
Это решило вышеуказанную ошибку.
В соответствии с этим название ветки Github по умолчанию было изменено с "master" на "main".
Итак, при создании новых заданий для новых репозиториев вы должны установить "main" в качестве имени ветки вместо "master".
Обратите внимание, что в github есть способ установить "master" (или любое другое удобное имя) в качестве имени ветки по умолчанию.
Я также трачу время на поиск решения. Через какое-то время я понял, что названия веток разные, поэтому не берется.
Решение в моем репо является основным и пытается с мастером. Это ошибка
Изменено как здесь
Вам нужно определить имя ветки, потому что Jenkins по умолчанию перехватывает мастер, а в GitHub нет мастера, теперь он основной, поэтому в случае GitHub вам также нужно передать имя ветки.
git branch: 'main', credentialsId: 'GithubCred', url: 'Your-Repo-URL'
Это решило мою проблему
Как указано здесь, если вы хотите создать задание вручную, в настройке задания установите флажок Эта сборка параметризуется и добавьте строковый параметр с именем sha1 со значением по умолчанию master, При запуске сборки укажите идентификатор фиксации параметра sha1, который вы хотите создать или переименуйте (например: origin/pr/9/head).
Я исправил это же сообщение об ошибке, используя 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
Так же "?" Справочная документация рядом с полем "Спецификатор ветвления" также поддерживает этот ответ как самый безопасный вариант для указания спецификатора ветвления, чтобы убедиться, что ожидаемая ветвь однозначна:
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.
это сработало для меня:
stage ('Git Checkout') {
steps {
git branch: 'main', url: 'https://<token>@github.com/username/repoName.git'
}
}
Иногда это происходит, если "Спецификатор ветви" не установлен должным образом. Я исправил спецификатор, и он работал для меня.
*/release/release4.5.0
или же
*/fetaure/myfeature
После долгих исследований и поломки головы. Я получал ту же ошибку и обнаружил, что эта ошибка также возникает, если вы используете другой путь git. Убедитесь, что у вас есть правильный путь. Например, я заменил C:\Program Files\Git\git-bash.exe на C:\Program Files\Git\bin\git.exe, и это решило проблему.
Недавно я столкнулся с этой же ошибкой, и ничего из вышеперечисленного не помогло мне, так как я хотел, чтобы Дженкинс проверял конкретную ветку моего кода. Для имени ветки было задано значение ${BRANCH}, которое было параметром Jenkins, который я создал в том же задании.
Если бы я использовал другую ветку, все работало нормально. На отладку у меня ушло много времени, так как он работал везде. Я мог бы клонировать репо и самостоятельно проверить эту ветку локально без проблем. Но только Дженкинс, похоже, сообщил об этой ошибке.
Наконец, после долгих исследований я понял, что значение по умолчанию, которое я установил для параметра BRANCH в этом задании Jenkins, было скопировано мной из более раннего запуска того же задания из раздела "Параметры". Похоже, что если мы копируем из этого раздела, добавляется скрытый специальный символ, и именно поэтому, хотя это выглядело как та же ветка, которую я хотел проверить в журналах Jenkins, она каким-то образом имела дополнительный скрытый символ и, следовательно, каждый раз терпела неудачу. Я удалил значение по умолчанию из этого параметра и повторно набрал это значение как значение по умолчанию вручную в конфигурации задания, и после этого он работал нормально.
У меня такая же проблема. В моем случае причина заключалась в том, что я использовал репозиторий github, который был зеркалом репозитория svn (потому что svn должным образом не поддерживается SonarCloud). По умолчанию в Jenkins было */master. Решение (найденное Гэвином Макдональдом из Apache INFRA) заключалось в использовании*/trunk. Другая проблема - это ".git" в URL-адресе, который не следует использовать.
В конфигурации вашего задания Jenkins в разделе Pipeline SCM снимите отметку с «Lightweight checkout» и нажмите «Сохранить». Также убедитесь, что вы правильно назвали свою ветку, как упоминали другие.
Я столкнулся с аналогичной проблемой, ошибка была в имени ветки, вам нужно указать исходный репозиторий в именах веток, чтобы убедиться, что изменения сохранены. Так, например, origin /feature/branch_name
В моем случае я решил проблему, изменив имя ветки Jenkins Default с « /master» на « / Master». Я использую облако Bitbucket и ветку Master.
Я столкнулся с той же самой проблемой и провел 4 часа в этом, но наконец получил, что это решено.
В моем случае ошибка была из-за неправильного Git exe. Внутри Jenkins при настройке Git exe path для windows установите путь в папке cmd
В моем случае это был C:\Program Files\Git\cmd\git.exe
Это решило мою проблему.
Всякий раз, когда мы не указываем правильную ветку для извлечения, git будет искать все ветки, которые есть в репозитории, и в конечном итоге выдаст ошибку: "Не удалось найти ревизию для сборки. Проверьте репозиторий и конфигурацию ветки для этого задания."
Я столкнулся с той же проблемой с моим git pull, и я использовал jenkins для указания конфигурации.
Если мы оставим это поле пустым, он получит файлы из главной ветки, но если что-то не так или есть опечатка, он будет искать все ветки и выдавать ошибку, говоря, что ветка не найдена.
Вопрос - ОШИБКА: не удалось найти версию для сборки. Проверьте конфигурацию репозитория и ветви для этого задания. Привет, ребята. Пожалуйста, проверьте имя ветки, на которое нацелена сборка jenkins. Оно должно быть одинаковым с обеих сторон (git и jenkins)
Оставление пустым в указателе ветвей в Jenkins сработало для меня SourceCodeManagement>Branch to build>Branch Specifier по умолчанию будет */master удалить значение по умолчанию
В моем случае ниже двух значений не было. Внутри конвейера ==> Определение ==> SCM ==> Дополнительно ==>
Имя = происхождение
Ссылка =
+refs/pull/${ghprbPullId}/*:refs/remotes/origin/pr/${ghprbPullId}/*
я использовал
Иногда имя ветки, указанное в jenkins и репозитории, отличается. В моем случае jenkins установил Master как ветку по умолчанию в jenkins. Но моя настоящая ветка - главная. На идентификацию у меня уходит более двух часов. Я не менял его, поскольку Дженкинс устанавливает его по умолчанию. Errormain Но это ошибка. Поэтому сначала проверьте имя ветки в вашем репозитории и имя ветки в jenkins, если вы получите эту ошибку.