Отправил серию из пяти патчей к 1.0.12. После сообщения о приложении третьего патча пришло письмо от Cron Daemon с логом, в котором есть следующее: To git.office:/projects/eterhack.git * [new tag] 1.0.12-alt7.28 -> 1.0.12-alt7.28 ! [rejected] eter-1.0.12 -> eter-1.0.12 (non-fast-forward) error: failed to push some refs to 'git.office:/projects/eterhack.git' Судя по всему, ошибка при push связана с тем, что уже закоммитился четвёртый патч, а Cron Daemon добавил свой коммит после третьего. В git-log почему-то получилась вот такая ерунда: commit c05510e5677d4cfc855b92510f997a8f37984fc2 Author: Etersoft builder <builder@etersoft.ru> Date: Fri Nov 26 14:00:09 2010 +0300 new build 1.0.12-alt7.29 (with rpmlog script) commit ae825c78e29518e6166372b961b8ebfd099cb4c8 Author: Etersoft builder <builder@etersoft.ru> Date: Fri Nov 26 13:50:13 2010 +0300 new build 1.0.12-alt7.28 (with rpmlog script) commit c34b5cdf56a90232243e1b5475c87817d982d052 Author: Alexander Morozov <amorozov@etersoft.ru> Date: Thu Nov 25 17:38:59 2010 +0300 crypt32/tests: Fix test failures on some Win95 and some NT4. В changelog: * Fri Nov 26 2010 Etersoft Builder <builder@etersoft.ru> 1.0.12-alt7.29 - crypt32/tests: Fix test failures on some Win95 and some NT4 - crypt32/tests: Skip more tests - new build 1.0.12-alt7.28 (with rpmlog script) * Fri Nov 26 2010 Etersoft Builder <builder@etersoft.ru> 1.0.12-alt7.28 - crypt32/tests: Do not crash on some Win98 - crypt32/tests: Fix test failures on WinME and some NT4 - crypt32/tests: Use pCryptAcquireContextA
Логической проблемы нет — содержимое changelog не повторяется. Скрипт формирования changelog переделал — теперь в случае неудачи публикации changelog он не будет его откладывать и потом публиковать два, а будет откатывать изменения, и в следующий раз делать полный changelog. Это должно исключить появление таких changelog.
commit d59588fdae21e39eda538036fdcc3f99e5dea130 Author: Vitaly Lipatov <lav@etersoft.ru> Date: Wed Dec 1 13:55:03 2010 +0300 build_funcs: do reset hard if push is failed (see eterbug #6560) diff --git a/tools/cron/build-funcs.sh b/tools/cron/build-funcs.sh @@ -73,7 +72,10 @@ pub_and_push() rpmpub -r $WORKTARGET # will works only if REPOALIAS is origin :) - gpush $REPOALIAS $WORKBRANCH || fatal + gpush $REPOALIAS $WORKBRANCH && return + + # if push is failed + git reset --hard $CURTAG
Отправлял сегодня серию из 11 патчей для eter-1.0.12. Часть серии не приложилась из-за того, что в репозиторий добавился коммит "new build 1.0.12-alt7.35 (with rpmlog script)". Для первого отвергнутого патча пришло письмо с заголовком "Your patch is not correctly applied ([eter-1.0.12] eterbugs #3850, #6182)". В письме такая ошибка: [17:56:03]ERROR: wine_repository: Error occured during the 'git push'. Backtrace:Traceback (most recent call last): File "/srv/builder-robot/Projects/wine-tests/git_repository.py", line 55, in publish self.git.execute(["git", "push", "origin", master_name]) File "/usr/lib/python2.6/site-packages/git/cmd.py", line 341, in execute raise GitCommandError(command, status, stderr_value) GitCommandError: 'git push origin eter-1.0.12' returned exit status 1: To git.office:/projects/eterhack.git ! [rejected] eter-1.0.12 -> eter-1.0.12 (non-fast-forward) error: failed to push some refs to 'git.office:/projects/eterhack.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.
Думаю, проблему можно обойти, если прикладывать всю серию патчей за один push.
(В ответ на comment #4) > Думаю, проблему можно обойти, если прикладывать всю серию патчей за один push. Сейчас патчи рассматриваются независимо. Они не привязываются к конкретному письму. Переделка существующей системы займёт много времени. Вместо этого предлагаю другие решения. Решение 1: объединить приложение патчей и создание нового релиза в один скрипт-обёртку. Сначала скрипт запускает робота, прикладывающего патчи, а затем он запускает скрипт, создающий новый релиз. При этом надо дописать проверку на запуск только одной версии этого скрипта-обёртки. Решение 2: Создать обёртку для скрипта, создающего новый релиз. В обёртке только добавить блокировка повторного запуска. Файл блокировки сделать общим. Таким образом ни один из скриптов не будет запускаться пока работает другое. Возникает только одна проблема: Они не должны запускаться по cron в одинаковое время
В последнее время проблема не актуальна. Откладываю.
Для тех, кто не пользуется багзиллой или не умеет пользоваться групповым редактированием при поиске, закрываем задачи, которые они должны были принять.
