Будни Chromium разработчика

Хотите знать как выглядит процесс коммита в Chromium? Есть у меня такие истории. Для затравки уточню терминологию. Chromium - это, фактически, open source версия Chrome. Если взять Chromium и добавить немного закрытого кода и логотип Google, то получится Chrome. А вот если добавить немного закрытого кода и логотип Яндекс, то получится Яндекс.Браузер. Исходники Chrome Remote Desktop, над которым работаю я с коллегами, тоже собираются из репозитория Chromium.

Так вот, про процесс коммита.

Чтобы уменьшить размеры бинарников Chrome Remote Desktop решили мы весь код переместить в одну DLL. А все выполняемые файлы превратить в заглушки, которые просто передают управление на нужную точку входа в DLL. Chrome собирается по похожей схеме. Помимо уменьшения размера бинарных файлов такой подход ещё и загрузку процессов успоряет, так как после старта первого процесса весь код уже загружен в память. Я подготовил соответствующий change list (CL), послал его на ревью и завалился болеть гриппом на неделю. Когда злобный вирус наконец отступил, CL уже был одобрен. После прогона тестов и пары финальных исправлений, CL, наконец, попадает в репозиторий.

На следующий день получаю письмо, что мой CL сломал сборку на одном из ботов и его откатили назад. Лезу в историю коммитов и логи, чтобы разобраться что к чему. Выясняется что мой CL переместил код из EXE в DLL. А независимый от него CL другого разработчика переместил этот же код из одной DLL в другую. Результат - конфликт модификаторов __declspec(export) и __declspec(import). Моему CL не повезло и его откатили первым.

Правлю код, прогоняю тесты и коммичу второй CL. На следующий день получаю письмо, что мой второй CL сломал сборку уже на другом боте. В этот раз mt.exe ругается ошибкой c101008a (Failed to save the updated manifest to the file “remoting_controller.exe.manifest”. The parameter is incorrect). Ругается, что характерно именно на бинарники, которые я менял.

В этот раз совершенно не понятно в чем дело. Единственная зацепка - сборка с помощью msbuild работает, а сборка с помощью ninja падает. Но только на этом конкретном боте. У меня локально и на других ботах все OK. По прежнему ничего не понятно. Возможно дело в том, что GYP генерирующий скрипты для ninja, не совсем корректно работает с манифестами?

Ну, хорошо. Переписываю GYP проект так, чтобы манифесты, которые автоматически генерирует связка GYP+ninja никак не пересекались с манифестами, которые я внедряю в бинарники: https://codereview.chromium.org/12092117. На этой версии CL ломается commit queue (CQ) - система, которая прогоняет тесты беред коммитом. Тестирую CL на своей машине, коммичу в обход CQ и … ломаю сборку - в CL случайно попадает файл, которого там не должно было быть.

Откатываю CL назад, извиняюсь по IRC за резко покрасневшее дерево. Убираю “залетный” файл, повторно тестирую сборку у себя на машине и коммичу CL. Дерево остается зеленым. Ура! Ура!

Но, не тут то было. mt.exe снова ругается ошибкой c101008a. Лезу в поисковик. Нахожу несколько баг-репортов, указывающих на то, что mt.exe может выдавать ошибку c101008a, в случае, если целевой файл уже существует. При каких условиях он это делает, остается не понятным, но утверждается, что пересборка с нуля проблемы решает. Хорошо. Прошу трупера (дежурного с правами доступа на сбойный сервер) перезапустить сборку с чистого листа. Заодно прошу скопировать проблемные манифесты - может быть удасться воспроизвести проблему локально? Воспроизвети локально не получается. Магифесты тоже выглядят нормально. Но чистая сборка проходит на ура. А вот следующая за ней - ломается.

Последная попытка - правлю GYP так, чтобы целевой манифест удалялся перед запуском mt.exe. Исходники GYP хранятся в отдельном репозитории и подтягиваются в основное дерево с помощью системы DEPS файлов. Это означет, что любая правка GYP выливается в два коммита: один в дерево GYP, другой - в дерево Chromium. Коммичу все изменения - бот зеленеет. Ура!

С нетерпением жду что будет завтра…