Работа с кодом проектов и сборка проектов — различия между версиями

Версия 16:41, 20 июня 2014

Работа с Git-репозиториями

Код всех проектов ABF находится в Git-репозиториях; для каждого проекта заводится свой репозиторий. Доступ к Git может осуществляться по протоколам HTTPS и SSH. Ссылка на репозиторий проекта <имя_проекта>, находящегося в группе <имя_группы>, имеет вид <URL_сервера_ABF>/<имя_группы>/<имя_проекта>.git. Например, чтобы склонировать по HTTPS репозиторий проекта 0ad группы import с сервера abf.rosalinux.ru на локальную машину с помощью консольного клиента Git, необходимо выполнить команду

git clone https://abf.rosalinux.ru/import/0ad.git

Для работы с git-репозиториями можно использовать консольные и графические клиенты Git, консольный клиент ABF, а также непосредственно веб-интерфейс ABF.

Для работы с Git-репозиторием проекта с использованием веб-интерфейса ABF, необходимо перейти на страницу проекта. По умолчанию будет активна вкладка "Код", отображающая файлы репозитория в ветке по умолчанию. В верхней части окна можно увидеть:

• кнопку с надписью zip, при нажатии на которую вам будет предложено скачать архив репозитория в формате zip или tar.gz
• ссылки для клонирования репозитория по HTTPS или SSH
• рядом со ссылкой на репозиторий находится знак вопроса, при клике на который будет показана детальная справка по клонированию репозитория
• меню "текущая ветка/тег", с помощью которой можно переключаться между ветками и тегами репозитория.

Код проекта

Ниже расположены четыре влкдаки:

• Файлы - файлы репозитория в выбранной ветке. Вы можете кликнуть на любой файл и отредактировать его непосредственно в веб-интерфейсе, если он является текстовым. На этой же влкдаке показывается описание проетка, последний коммит в текущую ветку, а также кнопки для начала сборки проекта, его клонирования и создания запроса на изменение ("пул реквеста").
• Коммиты - перечень всех изменений в текущей ветке репозитория
• Ветки - имеющиеся ветки репозитория. Здесь можно сравнивать, удалять и создавать ветки. Обратите внимание, что нельзя удалить ветку по умолчанию (задается в настройках проекта)
• Теги - имеющиеся теги проекта. Здесь можно просмотреть код, соответсвующий тегу, или скачать его в архиве формата zip либо tar.gz.

Хранение бинарных файлов

При использовании ABF не рекомендуется хранить бинарные файлы непосредственно в Git-репозитории. Это приводит к излишнему росту размера репозитория и замедляет процесс его клонирования. В то же время для бинарных файлов многие преимущества Git неактуальны - например, нельзя просматривать разницу между одним и тем же файлом в разных ветках.

Для бинарных файлов в ABF предусмотрено использование специального Файлового хранилища ("File store") - отдельного файлового сервера, доступ к которому может осуществляться с помощью веб-интерфейса, REST API или консольного клиента ABF. Сервер файлового хранилища позволяет загружать файлы на хранение и извлекать файлы на основе их хэш-суммы (вычисляемой по алгоритму SHA1).

Файловое хранилище ABF

В Git-репозитории проектов ABF вместо бинарных файлов можно помещать специальный файл с названием .abf.yml в формате YAML, содержащим перечень бинарных файлов и их хэш-суммы. Файлы должны быть перечислены в секции sources, например:

sources:
  "myfile1.tar.gz": e80fd7a3d85e3a75e88780d36c80f672df8ddf64
  "myfile2.gif": a96c913906f6d36c30fa70f8c6ad259dbcfb0a98

При сборке проекта на ABF, сборочный скрипт проанализирует файл .abf.yml и извлечет с файлового хранилища все файлы, необходимые для сборки.

Поскольку файл .abf.yml хранится в Git-репозитории, то для него отслеживается история изменений. Поскольку при этом старые версии бинарных файлов не удаляются из файлового хранилища, то вы можете просматривать историю изменений этих файлов и скачивать их версии, соответсвующие той или иной ветке, тегу или коммиту.

Обратите внимание, что консольный клиент ABF при выполнении команды "abf put" автоматически загружает бинарные файлы на файловое хранилище и прописывает ссылки на них в .abf.yml. При создании проектов на основе SRPM-пакетов, бинарные файлы также автоматически помещаются в файловое хранилище.

Сборка проекта

Сборка в ABF возможна для проектов, являющихся пакетами. Сборка производится на основе spec-файла, находящегося в корне Git-репозитория проекта. Если в корне Git-репозитория нет spec-файлов или имеется больше одного spec-файла, то ABF Откажется собирать проект.

Сборка проекта может осуществляться для персонального репозитория владельца (группы либо пользователя), а также в репозитории, к которым этот проект явно приписан. Подключение проекта к репозиториям осуществляется на страницах настройки платформы, к которой относится репозиторий.

Для сборки проекта, необходимо на его странице перейти на вкладку "Файлы" и нажать кнопку "Новая сборка". На появившейся странице необходимо выбрать платформу и ее репозиторий, для которого будет производиться сборка, ветку или тег Git-репозитория, из которой будет взят исходный код для сборки, и аппаратные архитектуры, для которых необходимо собрать пакет. При выборе репозитория, платформа, ветка и архитектуры будут выбраны автоматически на основе настроек группы, к которой принадлежит проект, и целевой платформы. Однако вы можете изменить выбранные значения - в частности, собрать пакет в репозиторий из ветки, предназначенной для другого репозитория либо собрать пакет для платформы, сборки для которой по умолчанию осуществляются из проектов другой группы.

Далее необходимо указать критичность обновления (используется как дополнительная информация для инструментов управления пакетами в системе - например, для возможноси отделить обновления, связанные с безопасностью, от добвалений, предоставляющих новые функциональные возможности). При необходимости, можно подключить дополнительные репозитории и результаты других сборочных заданий - это необходимо в ситуациях, когда в репозиториях. подключаемых по умолчанию, отсутсвуют необходимые для сборки зависимости. Использовать репозитории из других персональных платформ возможно только для сборки в персональную платформу. Для подключения репозитория, добавьте имя платформы, затем из списка выберете репозиторий для поключения и нажмите кнопку "Добавить". Пример: правильно ввести "uxteam_personal", неправильно: "uxteam_personal/main".

Требования для подключаемых сборочных заданий:

• можно подключить только задание с контейнером (см. ниже);
• для основных платформ возможно подключить только задания, которые предназначены для этой же платформы;
• будут подключены только задания с архитектурой, соотвествующей создаваемой, или предназначенные для обеих архитектур (если установлено соответствующее свойство в настройках rhel-проекта). Пример: для x86_64 архитектуры будут подключены только сборочные задания, собранные для x86_64.

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

В секции "Настройки" можно определить:

• будет ли результат сборки сразу опубликован в целевой репозиторий
• будет ли для сборки создан контейнер
• нужно ли подключать для сборки testing-репозиторий (если такие репозитории имеются в целевой платформе)
• можно ли использовать для сборки дополнительные сборочные клиенты, предоставляемые пользователями и не входящими в основную инфраструктуру ABF.

После задания всех настроек, нажмите кнопку "Начать сборку"

Начало сборки проекта

Мониторинг сборки

После начала сборки, вы будете перенаправлены на страницу мониторинга задач для конкретного проекта. Вы также можете отслеживать статус сборок произвольных преоктов, перейдя на вкладку "Мониторинг задач" в главном меню ABF. Посредством фильтров в верхней часи окна мониторинга вы можете отбирать задачи, удовлетворяющие определенным критериям.

Для каждой задачи на странице мониторинга отображаются идентификатор, настройки сборки, а также ее текущий статус:

• ожидает сборку - сборка еще не начата, ожидается освобождения одного из сборочных клиентов
• собирается - идет процесс сборки; при этом отображается время, прошедшее с момента старта сборки, а также ожидаемое полное время сборки (это время вычисляется на основе продолжительности предыдущих сборок проекта)
• собран - проект собран, но не опубликован, т.к. в параметрах сборки не была задана автоматическая публикация
• тесты перезапускаются - идет повторный запуск тестов
• публикуется - проект собран и публикуется
• опубликован - проект собран и собранные пакеты успешно опубликованы в целевой репозиторий
• ошибка тестов - сборка завершилась с успешно, но собранные пакеты не прошли тесты
• ошибка сборки - сборка завершилась с ошибкой
• ошибка публикации - сборка завершилась успешно, но при публикации возникли ошибки.

Для экономии пространства, на странице мониторинга задач по умолчанию осуществляется группировка сборок, запущенных для одного и того же проекта на основе одного и того же исходного кода, но под разные репозитории или аппаратные архитектуры. В такой ситуации отображается статус только одной из таких сборок (выбор осуществляется на основе статуса сборки), а для получения информации обо всех сборочных заданиях необходимо нажать на стрелку, расположенную слева от идентификатора задания. Рядом с идентификатором также отображаются вертикальные прямоугольники; их количество соответствует количеству задач, сгруппированных в одну строку, а цвет каждого прямоугольника отражает статус задачи (зеленый - сборка завершена/опубликована успешно, красный - при сборке или публикации возникли ошибки).

Мониторинг сборок

Результаты сборки и контейнеры

Результатом сборки проекта является SRPM-пакет и один или несколько RPM-пакетов. На странице с результатом успешной сборки в секции "Пакеты" можно найти ссылки на собранные пакеты. В зависимости от параметров сборки, эти пакеты могут быть сразу опубликованы в целевой репозиторий или для них может быть создан контейнер - спецциальный репозиторий, состоящий только из пакетов, полученных в результате сборки проекта. Для контейнера генерируются файлы с метаданными и он может быть подключен, как обычный репозиторий.

Страница с результатом сборки

Если пакет не был опубликован в целевой или тестовый репозиторий, то публикацию можно запустить со страницы сборки, нажав на соответсвующую кнопку. Если проект уже был опубликован, то его можно переопубликовать еще раз. Такая возможность полезна в ситуации, когда в репозитории есть более новая версия пакета, в которой содержится ошибка и которую необходимо подменить старой версией. Обратите внимание, что кнопки "Опубликовать" и "Опубликовать снова" доступны только в случае, если у вас есть права на публикацию в целевой репозиторий.

На странице с результатами сборки можно узнать путь до контейнера и создать контейнер. если он не был создан. Также можно запустить сборку с такими же параметрами еще раз, нажав на кнопку "Перезапустить сборку".

В секции "Логи" доступны различные журналы сборки:

• abfworker::publish-worker-* - журнал публикации собранных пакетов
• abfworker::rpm-worker-* - полный журнал сборки проекта
• changelog.log - cписок изменений, сформированный на основе журнала изменений в Git-репозитории и помещенный в соотвутствующую секцию собранных пакетов
• chroot-tree.log - полный листинг файлов в сборочном окружении
• rpm-build.log - отдельный журнал сборки SRPM- и RPM-пакетов
• rpm-qa.log - перечень пакетов, которые были установлены в среде сборки
• rpm-root.log - журнал создания сборочного окружения для сборки RPM-пакетов
• rpm-state.log - журнал изменений состояния сборочного задания при сборке RPM-пакетов
• rpmlint.log - отдельный журнал с результатом запуска rpmlint на собранных пакетах
• src-rpm-build.log - отдельный журнал сборки SRPM-пакета
• src-rpm-root.log - журнал создания сборочного окружения для сборки SRPM-пакета
• src-rpm-state.log - журнал изменений состояния сборочного задания при сборке SRPM-пакетов
• tests.log - журнал тестов (включающих в себя попытку установить собранные пакеты, проверит наличие более новых верси в репозитории и так далее)

В зависимости от настроек целевой платформы и результатов сборки, некоторые из перечисленных выше журналов могут отсутсвовать.

Запросы на изменение ("пул реквесты")

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

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

Создание пул реквеста

ABF проанализирует код в исходной и целевой ветке и отобразит диалог для ввода названия и детального описания запроса на изменения. Также появятся вкладки "Изменения" и "Коммиты", на которых можно детально ознакомиться с изменениями, которые будут перенесены. Также ABF проаналзирует, могут ли изменения быть перенесены автоматичсеки - то есть завершится ли успехом команда "git merge" по вливанию изменений в целевую ветку.

Создание пул реквеста

Для завершения создания пул реквеста, нажмите кнопку "Создать пул реквест".

После этого на странице целевого проекта во вкладке "Пул реквесты" появится запись о поступившем запросе на изменения.

Входящие пул реквесты

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

Обработка пул реквеста

Если изменения могут быть внесены в проект автоматически, то появится кнопка "Данный пул реквест можно смержить автоматически", при нажатии на которую ABF сам внесет все запрошенные изменения и закроет запрос.

Если же предлагаемые изменения конфликтуют с кодовой базой проекта, то этой кнопки не появится, а в заголовке запроса будет отображен статус "Заблокирован". Такие ситуации необходимо разрешать вручную - в общем случае, необходимо вручную попробовать слить две версии кода посредством "git merge" и разрешить спорные ситуации.

Для закрытия запроса, нажмите кнопку "Закрыть пул реквест".