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

Версия 14:50, 3 марта 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 - журнал изменений состояния сборочного задания при сборке ЫRPM-пакетов
• tests.log - журнал тестов, заключающихся в попытке установить соьранные пакеты

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