Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 6272 - Написать скрипт, автоматически обновляющий репозитории eterwine и eterhack   Make a simular bug
Summary: Написать скрипт, автоматически обновляющий репозитории eterwine и eterhack
Status: CLOSED FIXED
Alias: None
Product: WINE-tests
Classification: Свободные проекты (Open source projects)
Component: Общее (show other bugs)
Version: не указана
Hardware: PC All
: P4 minor
Target Milestone: ---
Assignee: Виталий Перов
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 6264 7538 7539 7537
  Show dependency treegraph
 
In work:
Reported: 2010-10-22 17:46 MSD by Виталий Перов
Modified: 2011-08-15 14:11 MSK (History)
2 users (show)

See Also:
Заявки RT:
Связано с:
Дата напоминания:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Виталий Перов 2010-10-22 17:46:03 MSD
На базе Wine-tests не сложно написать скрипт, автоматически обновляющий репозитории eterwine и eterhack.

Предполагаемое поведение для eterwine:
1) git pull origin
2) git checkout pure
3) обновить из winehq
4) git checkout master
5) merge pure
// вместо 3,4,5 может лучше делать git pull winehq находясь в master.
6)При возникновении ошибки завершится и послать письмо маинтейнеру для ручного обновления
7) запустить сборку
8) Проверить результат сборки и известить майнтейнера
9) Опубликовать репозиторий
// публиковать репозиторий или нет, если он смержился, но сборка не прошла?

Дальнейшее развитие:
Можно попробовать решать простые конфликты. Для этого:
1) При мерже сохраняем список конфликтных файлов
2) пробегаем все конфликтные файлы и смотрим конфликтующие патчи
3) выбираем оттуда только наши (возможно поиск по *.@etersoft.ru)
// а если это патч уже принятый в pure?
4) Сортируем конфликтные патчи по дате
5) Откатываем (самые новые вначале)
6) Если все патчи откатились, то можно мержить снова. Конфликтов не должно быть.
При этом рассылаем письма авторам патчей с просьбой их переделать. (Баги переоткрывают пусть сами).
Если какие-то патчи не откатились, то скрипт уже ничего сделать не может, отправляем письмо майнтейнеру, пускай мержит вручную.
Comment 1 Виталий Перов 2011-01-28 13:51:33 MSK
для начала предлагаю разобраться с eterwine. Его мержить проще, т.к можно мержиться с произвольным коммитом из pure.
Comment 2 Виталий Перов 2011-01-28 16:59:10 MSK
для начала упростил порядок задания репозиториев. Теперь репозитории описываются не кучей глобальных переменных, а структурами.
Comment 3 Виталий Перов 2011-01-28 17:29:00 MSK
Создал скрипт. Добавил разбор параметров командной строки
Comment 4 Виталий Перов 2011-01-28 18:12:21 MSK
Столкнулся с небольшой проблемой: у репозиториев eterwine и eterhack разные способы обновления: в eterwine обновляется сначала локальная ветка, а затем уже из неё мержится master. В eterhack мержится сразу из удалённого репозитория.

Было принято решение больше не сопровождать ветку pure в репозитории eterwine. Тогда будет единый механизм обновления eterwine и eterhack
Comment 5 Виталий Перов 2011-01-28 20:42:26 MSK
Начал реализацию мержа с определённым коммитом
Comment 6 Виталий Перов 2011-02-01 13:47:30 MSK
> Начал реализацию мержа с определённым коммитом
Закончил реализацию. Работает.
Добавил откат на предыдущее состояние, если сборка после мержа не удалась. Проверить работу отката пока не получится: нужен коммит ломающий сборку.

Осталось ещё добавить публикацию репозитория, и откат на предыдущее состояние при неудачной публикации
Comment 7 Виталий Перов 2011-02-01 14:25:11 MSK
> Осталось ещё добавить публикацию репозитория, и откат на предыдущее состояние
> при неудачной публикации
Реализовал, осталось проверить
Comment 8 Виталий Перов 2011-02-01 15:06:27 MSK
> Реализовал, осталось проверить
Проверил. Исправил ошибки. Работает
Comment 9 Виталий Перов 2011-02-07 13:57:34 MSK
Появилась проблема: при возникновении конфликтов репозиторий не откатывается к предыдущему состоянию.
Comment 10 Виталий Перов 2011-02-07 17:19:22 MSK
(В ответ на comment #9)
> Появилась проблема: при возникновении конфликтов репозиторий не откатывается к
> предыдущему состоянию.
Исправил
Comment 11 Виталий Перов 2011-02-15 21:11:35 MSK
Встретил проблему: не мержится при конфликте в configure.

Думаю этот случай легко исправить.
Comment 12 Виталий Перов 2011-02-15 21:15:19 MSK
Сейчас мерж делается напрямую. При этом сложно получить подробный результат мержа (конфликтующие файлы). Думаю надо попробовать осуществлять мерж с помощью комманд модуля git-python
Comment 13 Виталий Перов 2011-02-17 16:52:44 MSK
Встретил новую проблему: не прикладывается лог если сборка не удалась.
На почту приходит только сообщение о том, что мерж провалился, но ни слово не сказано про сборку вайн.
В логах:


[16:40:06]DEBUG wine_merge_task: Running merge task
[16:40:06]DEBUG wine_merge_task: Merging with commit 250448d7430c2880a2c399a816df7c1db099a756
[16:40:06]DEBUG wine_repository: Run wine-build script
[16:40:21]ERROR wine_repository: Wine build failed. Logfile attached.
[16:40:21]ERROR wine_repository: Can't attach the log file. _mail_report variable is unitialized for this class
[16:40:21]ERROR wine_repository: Cant't build wine. The current version is broken!
[16:40:21]ERROR wine_merge_task: Merge with commit 250448d7430c2880a2c399a816df7c1db099a756 failed
Comment 14 Виталий Перов 2011-02-17 17:26:31 MSK
Исправил. Теперь отправляется письмо с логом.
Comment 15 Виталий Перов 2011-03-02 17:55:42 MSK
(В ответ на comment #12)
> Сейчас мерж делается напрямую. При этом сложно получить подробный результат
> мержа (конфликтующие файлы). Думаю надо попробовать осуществлять мерж с помощью
> комманд модуля git-python

Попытался делать мерж с использованием функций модуля git-python.
Пока не получается. при выполнении git pull возникает исключение внутри модуля git-python:

Unhandled exception:
Traceback (most recent call last):
  File "./maintain_repo.py", line 70, in <module>
    result = repo.merge_with_commit(commit_id)
  File "/srv/vitperov/Projects/tests/git_repository.py", line 185, in merge_with_commit
    pull_result = remote.pull(rem_branch)
  File "/usr/lib/python2.6/site-packages/git/remote.py", line 674, in pull
    return self._get_fetch_info_from_stderr(proc, progress or RemoteProgress())
  File "/usr/lib/python2.6/site-packages/git/remote.py", line 610, in _get_fetch_info_from_stderr
    assert len(fetch_info_lines) == len(fetch_head_info)
AssertionError
Comment 16 Виталий Перов 2011-03-02 19:25:59 MSK
взял свежий git-python. В нём бага не возникает.
Но пока не понятно как парсить результаты git_pull.
Comment 17 Виталий Перов 2011-03-02 20:34:15 MSK
После неудачного мержа комманда self.is_dirty() возвращает True.
Но пока непонятно как вытащить конфликтные файлы.
Пробовал смотреть в self.head.commit.stats.files - список файлов после мержа не изменяется
Comment 18 Виталий Перов 2011-03-04 18:55:34 MSK
Возникшие конфликты можно посмотреть при помощи self.git.diff().
Только хорошо бы ещё понять как получить всё это не одним куском текста, а разбить на файлы
Comment 19 Виталий Перов 2011-03-04 19:49:17 MSK
Имена файлов можно получить при помощи:
stats = Stats._list_from_string(self, diff)
Comment 20 Виталий Перов 2011-03-04 20:30:23 MSK
Переделал. Теперь мерж происходит с помощью комманд модуля git-python.
Результат доступен как в виде списка конфликтных файлов, так и в виде строки с diff'ом этих файлов.

Осталось проверить систему локально, а затем под builder-robot.
Comment 21 Виталий Перов 2011-03-10 20:04:40 MSK
Проверил локально при наличии конфликта. Работает.
Comment 22 Виталий Перов 2011-03-10 20:06:31 MSK
Попробовал смержить репозиторий вручную - всё работает.
Оказывается возвращаемые имена файлов относятся к файлам, которые гит смержил автоматически.
Comment 23 Виталий Перов 2011-03-10 20:23:26 MSK
Разобрался. Тут возникает несколько проблем:

1) self.is_dirty() возвращает true при наличии файлов, которые смержились автоматически. Следовательно использовать его нельзя, нужно проверять результат мержа другим способом.
Можно пропробовать получать список изменений через self.git.diff без numstat=True. Тогда он должен быть пустой строкой при отсутствии конфликтов.

2) self.git.diff(numstat=True) возвращает даже те файлы, в которых конфликта не было. Возможно придётся использовать его без numstat=True. Но в этом случае не будет информации об изменённых файлах и придётся парсить строку с изменениями вручную.
Можно ещё попробовать для каждого файла запускать git annotate, и искать строчки с конфликтом. Если их нет, то считать, что конфликта в файле нет, и он смержился автоматически
Comment 24 Виталий Перов 2011-03-15 15:04:02 MSK
> 2) self.git.diff(numstat=True) возвращает даже те файлы, в которых конфликта не
> было. Возможно придётся использовать его без numstat=True. Но в этом случае не
> будет информации об изменённых файлах и придётся парсить строку с изменениями
> вручную.
> Можно ещё попробовать для каждого файла запускать git annotate, и искать
> строчки с конфликтом. Если их нет, то считать, что конфликта в файле нет, и он
> смержился автоматически
Проверил. diff показывает конфликты во всех файлах, и автоматически их не исправляет. Возможно есть какой-то атрибут при выполнении git.pull
Comment 25 Виталий Перов 2011-03-15 16:18:34 MSK
Есть методы from_tree и merge_tree. Про merge_tree в документации почти ничего не сказано, про from_tree есть упоминание, что этот метод может разрешать конфликты, но пока не совсем понятно как этим пользоваться
Comment 26 Виталий Перов 2011-08-03 21:28:01 MSK
Отложил пока автоматическое разрешение конфликтов.

Начала реализацию автоматического обновления до апстрима.
Comment 27 Виталий Перов 2011-08-08 22:46:12 MSK
Добавил вывод дополнительной информации при мерже с определённым коммитом.
Comment 28 Виталий Перов 2011-08-09 19:48:30 MSK
Реализовал мерж при отправке письма.
Для этого надо отправить письмо с заголовком [merge_task]....
И названием текущего репозитория в первой строке.
Comment 29 Виталий Перов 2011-08-09 20:33:37 MSK
Реализовал обновление при помощи отдельного скрипта maintain_repo.py.
Обновление работает, только посылка писем майнтейнеру пока не работает
Comment 30 Виталий Перов 2011-08-09 21:36:56 MSK
Исправил отправку писем.

Обновил конфигурацию для builder-robot@builder
Добавил скрипт в автозагрузку в 00:00.

Заметил новую проблему: Если репозиторий не требует обновления, то всё-равно мерж считается успешным, и письмо отправляется.
Comment 31 Виталий Перов 2011-08-10 20:02:15 MSK
> Заметил новую проблему: Если репозиторий не требует обновления, то всё-равно
> мерж считается успешным, и письмо отправляется.

Исправил
Comment 32 Виталий Перов 2011-08-11 17:06:21 MSK
Исправил работу скрипта ./maintain_repo для мержа с отдельными коммитами.

Следующий шаг - добиться, чтобы в этом режиме выводилась информация о конфликтных файлах (сейчас она выводится только при мерже с апстримом.
Comment 33 Виталий Перов 2011-08-11 17:37:49 MSK
> Следующий шаг - добиться, чтобы в этом режиме выводилась информация о
> конфликтных файлах (сейчас она выводится только при мерже с апстримом.

Сделано
Comment 34 Виталий Перов 2011-08-11 18:22:22 MSK
начал реализацию разбора полученного git diff.
Comment 35 Виталий Перов 2011-08-12 20:26:26 MSK
Достаточно сложно воспроизвести конфликты при мерже.
Если откатывать локальный реопозиторий, а потом мержиться с ближайшим коммитом из апстрима, то мерж не проходит, git говорит, что уже всё смержено.
Единственный способ воспроизвести конфликты - это откатить локальный репозиторий, и смержиться с верхним коммитом апстрима, ито при условии, что мержа с этим коммитом ещё не было.
Comment 36 Виталий Перов 2011-08-12 21:47:06 MSK
(В ответ на comment #35)
> Единственный способ воспроизвести конфликты - это откатить локальный
> репозиторий, и смержиться с верхним коммитом апстрима, ито при условии, что
> мержа с этим коммитом ещё не было.
Нет, так тоже не проходит. Спокойно мержит, но не может опубликовать
Comment 37 Виталий Перов 2011-08-13 14:03:20 MSK
Создал новую ветку в репозитории. В ней мерж с конфликтным коммитом работает.
В итоге результат конфликтного мержа выглядит следующим образом:
0       0       configure
103     94      configure
0       0       configure.ac
63      58      configure.ac
Comment 38 Виталий Перов 2011-08-13 15:05:02 MSK
Написал код, получающий список файлов с конфликтами из git-diff
Comment 39 Виталий Перов 2011-08-13 17:41:30 MSK
Реализовал автоматическое устранение конфликтов в файле configre.
Само устранение конфликтов работает, сборка wine после этого проходит успешно.
Но почему-то id верхнего коммита не изменяется, и письмо с результатом не отправляется.
Comment 40 Виталий Перов 2011-08-13 19:06:19 MSK
Забыл выполнять git-commit.
Исправил. Сейчас возникла проблема с заданием сообщения коммита.
Comment 41 Виталий Перов 2011-08-13 19:40:51 MSK
Встретил дополнительную проблему:
При мерже с апстримом в дереве не показываются промежуточные коммиты, виден только тот коммит, с которым осуществляется мерж.
Нужно попробовать мержиться с апстримом с указанием конкретного id коммита.
Comment 42 Виталий Перов 2011-08-15 13:29:01 MSK
(В ответ на comment #41)
> Встретил дополнительную проблему:
> При мерже с апстримом в дереве не показываются промежуточные коммиты, виден
> только тот коммит, с которым осуществляется мерж.
> Нужно попробовать мержиться с апстримом с указанием конкретного id коммита.

Оказалось, что в исходном репозитории промежуточных коммитов нет. В последний день был только один коммит.
Comment 43 Виталий Перов 2011-08-15 14:05:49 MSK
Проверил. Проблемы в configure успешно исправляются. Wine после этого успешно собирается, репозиторий публикуется.
Думаю, что багу можно закрывать.

Для расширения функциональности (разрешения более сложных конфликтов) создал отдельные баги  7537 и 7538.