Jenkins CI использует неправильную версию svn для сборки

В настоящее время я работаю с Jenkins CI Server, и я хочу запустить работу/построить через svn post commit hook. Пока он работает так, как ожидалось, но сборка использует предыдущую ревизию svn.

Например: я проверяю свои файлы, и клиент показывает мне версию 90, сборка начинается, но она использует 89.

Квест после фиксации выглядит следующим образом:

UUID=`svnlook uuid $REPOS`
/usr/bin/wget \
     --header "Content-Type:text/plain;charset=UTF-8" \
     --post-data "`svnlook changed --revision $REV $REPOS`" \
     --output-document "-" \
     --timeout=2 \
     http://ci-jenkins/job/Job1/build?rev=$REV 1>&2

Стратегия выписки в Jenkins в настройке "Всегда проверяйте новую копию". Что не так? Я все еще начинаю с этого и многому научился. Поэтому, пожалуйста, имейте это в виду, чтобы ответить мне.: -)

Ответы

Ответ 2

Убедитесь, что дата/время на сервере Jenkins соответствует дате/времени на сервере SVN (или, по крайней мере, позади).

Довольно уверен, что Дженкинс использует дату/время, когда делает это проверки и обновления.

Ответ 3

Привет, в настоящее время я работаю с Jenkins CI Server, и я хочу запустить работу/построить через svn post commit hook.

Хорошо, я укушу: почему вы не просто позволяете Дженкинсу запускать транзакцию Subversion?

Я видел, как люди делали это для CVS, потому что Дженкинс может занять много времени, чтобы опросить CVS, чтобы узнать, было ли выполнено коммивоучение CVS. Но, Дженкинс занимает всего несколько секунд, чтобы определить, что совершена транзакция Subversion.

Если вы действительно настаиваете на том, чтобы инициировать создание Jenkins самостоятельно, почему бы просто не сконфигурировать ваши проекты, чтобы разрешить удаленный запуск? В разделе "Триггеры сборки" для каждого задания вы указываете токен, а затем запускаете его с помощью wget:

 wget $JENKINS_URL/job/foo?token=BUILD_NOW

(Предполагая, что установленный токен BUILD_NOW)

Таким образом, вам не нужно беспокоиться о пересмотре, и Дженкинс построит последнюю ревизию, которая была проверена.

Другие считают, что это проблема синхронизации времени, но я не уверен. Вы передаете номер сборки в своем аргументе. Вы можете попробовать несколько вещей:

  • Сон в течение 30 секунд, прежде чем запускать сборку и посмотреть, поможет ли это. Я бы не сохранил его в script, потому что он задерживает фиксацию Subversion, но может помочь вам определить, что это не проблема времени.
  • Что делать, если вы добавите его в $REV, а затем запустите сборку Jenkin? Возможно, это позаботится о проблеме.

Ответ 4

Это может произойти, если время на сервере Jenkins и Subversion не синхронизировано. Убедитесь, что время остается в пределах 2 секунд.

Ответ 5

это связано с синхронизацией времени между сервером SVN и jenkins one. Другими словами, дата и время двух серверов не совпадают. Я столкнулся с этим, и у меня было три минуты разницы, я решил это, настроив задержку на 5 минут до выполнения задания jenkins в расширенных вариантах проекта.