Контроль

Обязательная проверка для всего дистрибутива

Конфигурация Fedora Greenwave применяет некоторые политики проверки для всего дистрибутива. Обновления в большинстве групп критического пути (кроме тех, что относятся к рабочим столам, не блокирующим релиз) проверяются на подмножествах набора тестов обновлений Fedora openQA в зависимости от того, в какие группы они входят. Эта проверка не является опциональной и не может быть отключена.

Опциональная проверка

Дополнительные требования проверки можно включить по запросу для каждого пакета отдельно. Если вы хотите включить проверку для вашего пакета, создайте новый файл gating.yaml в корне каталога dist-git пакета со следующим содержимым:

Включить проверку перед попаданием в тестовый репозиторий:

--- !Policy
product_versions:
  - fedora-*
decision_contexts: [bodhi_update_push_testing] subject_type: koji_build rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}

Включить проверку перед попаданием в стабильный репозиторий:

--- !Policy
product_versions:
  - fedora-*
decision_contexts: [bodhi_update_push_stable] subject_type: koji_build rules:
  - !PassingTestCaseRule {test_case_name: fedora-ci.koji-build.tier0.functional}
Чтобы включить обе проверки, просто объедините оба примера выше.
Чтобы добавить другой тест, просто расширьте список rules дополнительными !PassingTestCaseRule.

Это включит проверку для всех релизов Fedora на основе результата конвейера Jenkins CI, который запускает тесты TMT пакета. Контекст решения определяет набор политик, используемых для конкретной проверки. Например, контекст решения bodhi_update_push_stable используется для проверки сборок RPM в обновлениях Bodhi перед попаданием в стабильный репозиторий. Обратите внимание, что обработка этих двух контекстов решения в Bodhi работает с ошибками. На самом деле обновления никогда не блокируются от отправки в тестирование, даже если существует политика bodhi_update_push_testing и она не проходит. Но лучше всего включать оба контекста в вашу политику с одинаковыми требованиями, иначе отображаемый «статус проверки» вашего обновления в веб-интерфейсе Bodhi может меняться запутанным образом со странными последствиями, как описано в отчёте об ошибке.

decision_contexts должны совпадать как в файле удалённых правил, так и в политике конфигурации Greenwave (по крайней мере один контекст решения). Правила определяют тестовые случаи resultsdb, которые следует учитывать при принятии решения о проверке — в данном случае fedora-ci.koji-build.tier0.functional, то есть тесты, запущенные в CI на основе конфигурации tmt в dist-git пакета. Если для конкретного контекста решения не требуются тесты, правила должны быть установлены в пустой список, т.е. rules: [], иначе Greenwave вернёт сообщение о том, что не найдено ни одной применимой политики.

Для проверки можно включить следующие тесты Fedora CI:

  • fedora-ci.koji-build.tier0.functional — тесты, специфичные для компонента, включённые с помощью tmt в dist-git

  • fedora-ci.koji-build.rpmdeplint.functional — для проверки зависимостей обновления и отсутствия незарегистрированных конфликтов файлов с другими пакетами

  • fedora-ci.koji-build.rmdepcheck.functional — для проверки того, что обновление не нарушает зависимости других пакетов

  • fedora-ci.koji-build.rpminspect.static-analysis — для проверки корректности пакета, включая стабильность ABI

  • fedora-ci.koji-build.installability.functional — для проверки корректной установки / обновления пакета

Обратитесь к Политикам для конкретных пакетов Greenwave для получения более подробной технической информации о настройке политики.

Использование нескольких планов

Если вы используете несколько планов tmt, можно включить проверку только для выбранных планов. Вместо общего типа tier0 используйте имя нужного плана в имени тестового случая resultsdb:

!PassingTestCaseRule {test_case_name: fedora-ci.koji-build.<имя-плана>.functional}

Например, правило для включения проверки плана /plans/basic будет выглядеть так:

!PassingTestCaseRule {test_case_name: fedora-ci.koji-build./plans/basic.functional}

Прежде чем можно будет использовать вышеуказанные правила, необходимо включить раздельную отчётность по планам. Подробности см. в разделе Несколько планов.

Отказ от проверки

Если результат неудачного теста несущественен, вы можете отказаться от него, используя веб-интерфейс Bodhi или напрямую из командной строки. Однако, пожалуйста, не отказывайтесь от неудачных тестов Fedora openQA — тестовых случаев, имена которых начинаются с update. Если вы откажетесь от ошибки openQA, эта же ошибка, вероятно, будет «наследоваться» в каждом последующем тесте любого другого обновления и вызовет проверку всех остальных обновлений. Вместо этого обратитесь в команду Fedora Quality за помощью в устранении неудачных тестов openQA. Примеры отказа из командной строки:

# Вывести список блокирующих результатов тестов
bodhi updates waive <id> --show
# Указать, от каких тестов отказаться:
bodhi updates waive <id> --test="dist.rpmlint" --test="atomic-ci" "Комментарий с объяснением отказа"
# Отказаться от всех тестов:
bodhi updates waive <id> --test=all "Комментарий с объяснением отказа"

В то время как веб-интерфейс позволяет отказаться только от всех тестов, командная строка даёт возможность выбрать тесты, от которых следует отказаться.

Ссылки

Want to help? Learn how to contribute to Fedora Docs ›