Интеграция Github с Хадсон CI - PullRequest
2 голосов
/ 26 июля 2011

В духе открытости, я новичок в Гудзоне CI и Github, так что, пожалуйста, поговорите со мной об этом.Вот что я сделал до сих пор.

  • Развертывание сервера tomcat6.0 на c: \ www
  • Скачал и развернул Hudson.war в c: \ www \ webappsпапка
  • Установлен плагин Github
  • Создан личный репозиторий на Github
  • На сервере, с установленным hudson, сгенерированы ssh-ключи.
  • Переменная среды%HOME% имеет значение c: \ Documents and settings [имя пользователя] (там находится каталог .ssh с ключами)
  • Переменная среды% HUDSON_HOME% установлена ​​в c: \ www \ webapps \ hudson
  • В hudson у меня есть следующие конфигурации:
    • Проект Github: https://github.com/[my организация] / [имя проекта]
    • Управление исходным кодом: Git
    • URL-адресРепозиторий: git@github.com: [моя организация] / [название проекта] .git
    • Спецификатор филиала: **
    • Браузер репозитория: (Авто)

Когда я запускаю сборку и щелкаю ссылку на вывод консоли, я вижу это -

Started by user anonymous
Checkout:workspace / C:\www\webapps\hudson\jobs\[project name] (git)\workspace - hudson.remoting.LocalChannel@2e8f6d20
Using strategy: Default
Checkout:workspace / C:\www\webapps\hudson\jobs\[project name] (git)\workspace - hudson.remoting.LocalChannel@2e8f6d20
Fetching changes from the remote Git repository
Fetching upstream changes from git@github.com:[organization name]/[project name].git

... в этот моментэто висит.Когда я отменяю сборку, добавляется следующее -

ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
ERROR:  (Underlying report) : Error performing command: git.exe fetch -t git@github.com:[organization name]/[project name].git +refs/heads/*:refs/remotes/origin/*
null
ERROR: Could not fetch from any repository
FATAL: Could not fetch from any repository
hudson.plugins.git.GitException: Could not fetch from any repository
    at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:796)
    at hudson.plugins.git.GitSCM$3.invoke(GitSCM.java:754)
    at hudson.FilePath.act(FilePath.java:756)
    at hudson.FilePath.act(FilePath.java:738)
    at hudson.plugins.git.GitSCM.gerRevisionToBuild(GitSCM.java:754)
    at hudson.plugins.git.GitSCM.checkout(GitSCM.java:540)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:1180)
    at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:506)
    at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:422)
    at hudson.model.Run.run(Run.java:1362)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
    at hudson.model.ResourceController.execute(ResourceController.java:88)
    at hudson.model.Executor.run(Executor.java:145)

Может кто-нибудь помочь?

Ответы [ 2 ]

2 голосов
/ 27 июля 2011

Прежде всего, поскольку вы начинаете с нового экземпляра CI, я настоятельно рекомендую вместо этого установить Jenkins (поскольку он активно поддерживается большинством первоначальных разработчиков Hudson).

Во-вторых, установите плагин DumpInfo Wrapper и снова запустите сборку.Этот плагин печатает системные свойства и переменные среды, действующие во время сборки, и позволяет вам проверять их.

Обновление:

Этот плагин должен регистрировать системные свойства и переменные среды, я вас удивляюне вижу их.Что касается ключевой фразы, я предлагаю вам сгенерировать отдельный закрытый ключ (из вашей существующей пары), который вместо этого не защищен парольной фразой, в противном случае вам может потребоваться рассмотреть решение, предлагаемое для: Почему git не может вспомнить мою парольную фразу вWindows .Я проверил, что это работает (когда я настраивал свой собственный CI на окнах), но я не чувствую, что это стоит того (есть и другие нюансы, включая установку и запуск экземпляра tomcat от имени вошедшего в систему пользователя, а НЕ каклокальный сервис, так что зрелище будет работать с ним должным образом), поэтому я бы порекомендовал первый вариант.

0 голосов
/ 12 марта 2012

В моем случае это была проблема с клиентом Git: я использовал v1.6.0, который вызывал сообщение об ошибке

fatal: https://github.com/dmak/jaxb-xew-plugin.git/info/refs download error - The requested URL returned error: 403

в Гудзоне.Сначала это выглядело как эта проблема , но strace анализ прогона git показал, что это был Nginx WebServer (на котором работает GitHub), возвращающий 403, а не прокси.

Когда я 'мы обновились до v1.7.3 проблема исчезла.Так что общий совет: не используйте старые клиенты с GitHub.

PS Я протестировал клонирование как с "Specifier Branch (по умолчанию пусто): origin / master" в конфигурации задания Hudson, так и с пустым (по умолчанию)): в обоих случаях Git смог правильно обнаружить ветку master (origin / master) и использовал ее для клонирования.

...