checkbox-cli - онлайн в хмарі

ПРОГРАМА:

ІМ'Я

checkbox_ng - Документація CheckboxNG

CheckboxNG – це інструмент для тестування обладнання, корисний для сертифікації ноутбуків, настільних комп’ютерів і серверів
з Ubuntu. Це нова версія Checkbox, яка створена безпосередньо поверх PlainBox

ПрапорецьNG замінює Прапорець, якщо є.

ПОПЕРЕДЖЕННЯ:
Документація знаходиться на стадії розробки. Деякі речі неправильні, неточні або описані
цілі розвитку, а не поточний стан.

УСТАНОВКА

CheckboxNG можна встановити з PPA (рекомендовано) або pypi в Ubuntu Precise (12.04) або
новіший.

$ sudo add-apt-repository ppa:checkbox-dev/ppa && sudo apt-get update && sudo apt-get install checkbox-ng

РУНІНГ СТАБІЛЬНА РЕЛІЗ ОНОВЛЕННЯ ВИПРОБУВАННЯ

CheckboxNG має спеціальну підтримку для запуску тестів стабільних оновлень випуску в автоматизованому
манера. Це запускає всі завдання з sru.білий список і надсилає результати до
веб-сайт сертифікації.

Щоб запустити тести SRU, вам потрібно знати так званий Secure ID пристрою, яким ви є
тестування. Коли ви знаєте, що все, що вам потрібно зробити, це запустити:

$ прапорець sru $secure_id submission.xml

Другий аргумент, submission.xml, є ім'ям резервного файлу, який тільки створюється
при відправленні даних на веб-сайт сертифікації з будь-яких причин не працює.

ЗВІТНІСТЬ БУГИ

Щоб повідомити про помилки в проекті Checkbox, вам знадобиться обліковий запис панелі запуску. Ви можете знайти
інструкції on як до створювати один <https://help.launchpad.net/YourAccount/NewAccount>
корисний. Коли у вас є обліковий запис, ви можете звітом помилки <https://bugs.launchpad.net/checkbox-
проект/+файлова помилка>.

На цій сторінці ви можете вибрати проект, до якого ви хочете повідомити про помилку (ми використовуємо кілька
проектів для координації випусків, і ми вважаємо за краще мати помилки, пов’язані з відповідними
частина прапорця). Якщо ви знаєте правильний проект для використання, просто скористайтеся ним і зареєструйте помилку. Якщо
ви не дуже знаєте внутрішні елементи Checkbox або сумніваєтеся, просто подайте його на базу
Проект "Checkbox" (можна використовувати це прямий link
<https://bugs.launchpad.net/checkbox/+filebug>.) Член команди розробників буде
перегляньте свою помилку та повторно призначте її у відповідне місце. Номер помилки не буде
змінити, коли це станеться.

THE ПРАВОК СТЕК

Стек прапорців — це набір проектів, які разом становлять повне тестування
і сертифікаційне рішення. Він складається з наступних частин (див. таблицю нижче
додаткові деталі). Усі проекти пов’язані з Лаунчпад проект група
<https://launchpad.net/checkbox-project>.

архітектура Діаграма
[зображення: архітектурна схема] [зображення]

Ця діаграма містить апроксимацію високого рівня поточної архітектури Checkbox.
Є три основні «стовпи». Зліва маємо кінець продукти. Це справжні інструменти
що використовують сертифікацію та інженери. Праворуч у нас є тест ринок, Це
відкритий ринок постачальників і постачальників тестів. Тести загорнуті в контейнери, відомі як
постачальників. У центрі ми маємо три спільні компоненти. Ті реалізують основну частину
фреймворк та інтерфейси користувача для виконання тестів. Нарешті в нижньому лівому куті є
є частиною прапорця (бібліотеки), який використовується спільно з HEXR для певних завдань. HEXR - це a
веб-додаток поза межами, що використовується в рамках процесу сертифікації. Стрілки означають
зв'язок за допомогою форми стрілки показує, хто кому дзвонить.

Як згадувалося раніше, у центральному стовпці є три основні компоненти спільного коду
(розповсюджується всіма, хто використовує кінцеві продукти, які обговорюються нижче). Спільний код
складається з plainbox, checkbox-ng і checkbox-gui. Обов'язки компонентів є
більш детально розглянуто в таблиці нижче. Тут ми бачимо, що checkbox-gui використовував DBus
API надається checkbox-ng, який, у свою чергу, використовує checkbox-support (допоміжну бібліотеку
відокремлено, тому поділіться деяким кодом з HEXR) і plainbox.

У правій колонці є різні постачальники тестів. Проект прапорця є
виробництво та підтримка ряду постачальників (див. таблицю нижче), але це очікується
що наші нижчестоящі користувачі також створюватимуть своїх власних постачальників (специфічних для клієнта або
проект). Згодом деякі постачальники можуть виходити з третіх сторін, які приймуть цю програму
Формат.

Нарешті, у нижньому лівому куті, спільна бібліотека, ця бібліотека містить багато аналізаторів
різноманітних форматів файлів і вихідних форматів. Технічно ця бібліотека є залежністю від
HEXR, прапорець-ng та постачальників. В якості додаткової складності необхідно викликати бібліотеку
з коду python3 і коду python2.

ПРИМІТКА:
Зв'язок між checkbox-ng і plainbox є двостороннім. Пропозиції Plainbox
деякі базові інтерфейси та точки розширення. Все це відкривається через звичайну коробку
(використовуючи звичайні API), але деякі з них насправді реалізовані в checkbox-ng.

ПОПЕРЕДЖЕННЯ:
Усі внутрішні API є напівнестабільними. API DBus є більш стабільним на практиці, але повинен
не можна покладатися. Рекомендується об’єднувати проекти в lp:checkbox, де API
переходи можна обробляти витончено. Єдиний стабільний API - це формат файлу
специфікація (визначення вакансій і білий список). Специфікація запуску буде
стабілізується в наступному випуску.

Компонент Описи
┌─────────────────────────┬────────────────────── ───────────────────┬───────────────────────────┐
│Проект │ Відповідальний за │ Тип │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Прапорець наступного покоління │ │ Програма │
│(GUI) │ · C++/QML │ │
│ │ інтерфейс користувача │ │
│ │ │ │
│ │ · Графічний │ │
│ │ пускова установка для │ │
│ │ постачальники, наприклад │ │
│ │ прапорець-сертифікація-клієнт │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Прапорець наступного покоління │ │ Програма │
│(CLI) │ · Командний рядок python │ │
│ │ інтерфейс │ │
│ │ │ │
│ │ · текстовий інтерфейс користувача │ │
│ │ │ │
│ │ · команда тестування SRU │ │
│ │ │ │
│ │ · Додаткові API сертифікації │ │
│ │ │ │
│ │ · надсилання даних на панель запуску │ │
│ │ │ │
│ │ · надсилання даних до HEXR │ │
│ │ │ │
│ │ · послуга DBus, необхідна │ │
│ │ GUI │ │
└─────────────────────────┴────────────────────── ───────────────────┴───────────────────────────┘

│Сертифікація клієнта │ │ Постачальник │
│Провайдер │ · канонічний-сертифікаційний-клієнт │ │
│ │ виконуваний │ │
│ │ │ │
│ │ · сертифікація клієнта │ │
│ │ білі списки │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Сертифікація сервера │ │ Провайдера │
│Провайдер │ · Сертифікація сервера │ │
│ │ білі списки │ │
│ │ │ │
│ │ · додаткові білі списки серверів │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Сервер «Система на чіпі» │ │ Постачальник │
│Постачальник сертифікації │ · Сертифікація сервера SoC │ │
│ │ білі списки │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Прапорець Постачальник │ │ Постачальник │
│ │ · Майже всі визначення посади │ │
│ │ │ │
│ │ · Більшість користувальницьких «скриптів» │ │
│ │ │ │
│ │ · За замовчуванням і білий список SRU │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Постачальник ресурсів │ │ Постачальник │
│ │ · Майже всі ресурсні робочі місця │ │
│ │ │ │
│ │ · Майже всі ресурсні «скрипти» │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│Підтримка прапорця │ │ Бібліотека │
│ │ · Код підтримки різних │ │
│ │ постачальники │ │
│ │ │ │
│ │ · Парсери для багатьох текстових форматів │ │
├─────────────────────────┼────────────────────── ───────────────────┼───────────────────────────┤
│PlainBox │ │ Бібліотека та розробка │
│ │ · Майже вся основна логіка │ Набір інструментів │
│ │ │ │
│ │ · RFC822 (визначення роботи) │ │
│ │ аналізатор │ │
│ │ │ │
│ │ · Обробка конфігурації │ │
│ │ │ │
│ │ · Сесія тестування │ │
│ │ (призупинити/відновити) │ │
│ │ │ │
│ │ · Завдання │ │
│ │ │ │
│ │ · Надійний запуск │ │
│ │ │ │
│ │ · Розв’язувач залежностей │ │
│ │ │ │
│ │ · Обробка командного рядка │ │
│ │ │ │
│ │ · XML, HTML і XSLX │ │
│ │ експортери │ │
│ │ │ │
│ │ · та інше... │ │
│ │ │ │
│ │ · Інструментарій розробки постачальника │ │
│ │ │ │
│ │ · «постачальник звичайної скриньки» │ │
│ │ │ │
│ │ · Реалізація 'manage.py' │ │
└─────────────────────────┴────────────────────── ───────────────────┴───────────────────────────┘

│Застарілий прапорець (немає │ │ Монолітного застосування │
│довше обслуговується) │ · Програми │ Бібліотека та дані │
│ │ │ │
│ │ · Qt4 GUI │ │
│ │ │ │
│ │ · Gtk2 GUI │ │
│ │ │ │
│ │ · Urwid (текстовий) GUI │ │
│ │ │ │
│ │ · Ядро │ │
│ │ │ │
│ │ · Плагін і подія / повідомлення │ │
│ │ Двигун │ │
│ │ │ │
│ │ · Майже кожна функція │ │
│ │ реалізовано основний плагін │ │
│ │ │ │
│ │ · Дані │ │
│ │ │ │
│ │ · Вакансії та білі списки │ │
└─────────────────────────┴────────────────────── ───────────────────┴───────────────────────────┘

КАНГЕЛОГ

ПРИМІТКА:
Цей журнал змін містить лише підсумок змін. Для більш точного обліку
історія розробки, будь ласка, перегляньте історію джерел безпосередньо.

ПрапорецьNG 0.23 (невипущений)
· Виправлення помилок: https://launchpad.net/checkbox-ng/+milestone/0.23

ПрапорецьNG 0.22
· Виправлення помилок: https://launchpad.net/checkbox-ng/+milestone/0.22

ПрапорецьNG 0.3
· Виправлення помилок: https://launchpad.net/checkbox-ng/+milestone/0.3

ПрапорецьNG 0.2
· Виправлення помилок: https://launchpad.net/checkbox-ng/+milestone/0.2

ПрапорецьNG 0.1
· Початковий випуск

· Підтримка відображення конфігурації

· Підтримка виконання тестів SRU (автоматичне регресійне тестування)

TEST СЦЕНАРІЇ

Тестові «скрипти» — це невеликі програми, які використовуються для допомоги в реалізації тестів.

яскравість_тест
Цей скрипт тестує яскравість підсвічування системи, яку можна змінити за допомогою
інтерфейси ядра в /sys/class/backlight. Можна вибрати кілька інтерфейсів
від, тому правильний інтерфейс для використання вибирається за допомогою евристики, описаної в
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight. Яскравість
маніпулюється шляхом оновлення файлу яскравості інтерфейсу та fact_brightness
файл перевіряється, щоб побачити, чи було змінено значення на вибрану яскравість.

ПРОФІЛІ КОНФІГУРАЦІЯ

Профілі виконання, або програми запуску, дозволяють вказати попередньо визначений набір конфігурації
параметри, які дозволяють налаштувати екран привітання, відображені білі списки, а також
збереження результатів локально або надсилання файлу подання на панель запуску або до сертифікації
database/HEXR, а також деякі інші параметри.

Налаштування профілю є частиною сценарію програми запуску та використовують або графічний інтерфейс прапорця, або
checkbox-launcher (у текстовому режимі/CLI) як інструмент для інтерпретації ключа/значень.

У цьому документі міститься посилання на функціональні можливості та синтаксис запуску. Щоб зрозуміти
дизайну та концепцій та переглянути кілька прикладів, ви можете прочитати підручник про те, як
створення пускових установок та їх зв’язок із застарілими прапорцями.

синтаксис
Оскільки checkbox-gui є програмою Qt, налаштування повинні відповідати правилам у стилі INI
QSettings <http://qt-project.org/doc/qt-5/QSettings.html> клас.

Багаторядкові значення підтримуються, але їх потрібно брати в подвійні лапки та додаткові рядки
має починатися з одного пробілу, наприклад:

[категорія]
key = "Привіт
світ"

· З QML:

settings.value("категорія/ключ", i18n.tr("default_value"))

· З C++:

settings->value("категорія/ключ", app.tr("default_value"))

Навпаки, слідувати повинні відповідні лаунчери для прапорців Python ConfigParser
<https://docs.python.org/3/library/configparser.html#supported-ini-file-structure> синтаксис.

Крім того, деякі налаштування мають сенс лише для графічного інтерфейсу або CLI, і, таким чином, не зрозумілі
інші. Вони зазначені нижче.

Підтриманий Налаштування
ласкаво просимо/назва
Назва програми QML і заголовок екрана привітання. За замовчуванням SYSTEM Тестування.

вітання/текст
Привітальне повідомлення для відображення на першому екрані (інструментальний інтерфейс прапорця підтримує форматований текст
дозволяючи розмітку в стилі HTML). За замовчуванням Ласкаво просимо до SYSTEM Тестування. [...]

suite/whitelist_filter
Регулярний вираз для відповідності підмножині імен файлів білого списку. На checkbox-gui це
за замовчуванням .*. Для прапорця-запуску він не має за замовчуванням і повинен бути визначеним.

набір/вибір_білого списку
Шаблон, який має відповідати білим спискам для попереднього вибору. Регулярний вираз Python.
Він не має за замовчуванням і повинен бути визначеним. (лише CLI)

suite/skip_whitelist_selection
Якщо встановлено значення true, користувач не отримає вибір білого списку. Тільки попередньо відібрані
будуть вибрані одиниці (див. whitelist_selection). (лише CLI).

набір/вибір_пропуску_тесту
Якщо встановлено значення true, користувачу не буде дозволено скасувати вибір тестів перед запуском: усі тести
у вибраному білому списку буде запущено. (лише CLI)

подання/повідомлення
Текст заголовка спливаючого вікна, який відображається користувачеві після подання
завершено. (лише GUI)

подання/тип_введення
Показати поле введення тексту, щоб ввести захищений ідентифікатор або адресу LP (за замовчуванням). До
просто збережіть результати на диск, необхідно використовувати ніхто значення. Щоб перевірити за допомогою регулярного виразу,
повинно бути regex. (лише GUI)

подання/регулярний вираз
Регулярний вираз для перевірки введених даних у полі подання (наприклад, електронна пошта, secure_id)
якщо input_type є регулярним виразом. (лише GUI). RegExpValidator, за замовчуванням .*

submission/input_placeholder
Тимчасовий текст для введення в поле введення, який використовується для керівництва користувача. Лаунчпад E-Mail
адреса (за замовчуванням) або Безпечний ID (15 or 18 символів). (лише GUI)

submission/secure_id
Попередньо налаштований secure_id для заповнення текстового поля.

submission/ok_btn_text
Мітка для кнопки «Надіслати». Надіслати результати (за замовчуванням) або зберегти результати. (графічний інтерфейс
тільки)

submission/cancel_warning
Показати користувачеві, якщо він хоче вийти без збереження звіту. Ви про
щоб вийти з цього тестового запуску без збереження звіту про результати. Ви хочете зберегти
звітувати? (лише GUI)

submission/submit_to_hexr
Boolean, додайте додатковий заголовок, щоб також надіслати результати в HEXR (працює з
сертифікаційний транспорт)

експортер/xml_export_path
Розташування для збереження XML-файлу, якщо встановлено порожній рядок, відкриє a
діалогове вікно збереження файлу. За замовчуванням: /tmp/submission.xml (лише GUI)

транспортувати/подавати_то
Транспортна кінцева точка. За замовчуванням . Підтримує подання на LP (за замовчуванням,
значення LaunchPad), сертифікаціяабо місцевий (зберегти на диск)

transport/submit_url
URL для надсилання результатів. Це дозволяє завантажувати, наприклад, на різні веб-сайти
його можна завантажувати безпосередньо на hexr або на сайти для розміщення. Використовується тільки з
сертифікація submit_to значення.

транспорт/ім'я_файлу конфігурації
Ім'я спеціального файлу конфігурації для завантаження. Конфігураційні файли в основному використовуються для визначення
змінні середовища. (лише CLI)

transport/dont_suppress_output
Якщо встановлено, ресурси, локальні завдання та вкладення будуть виведені на екран, це
генерує багато тексту і в основному призначений для налагодження. (лише CLI)

ПРАВИЛЬНИК/ЗВ ПАНЕЛІ Підручник

У цьому документі пояснюється, навіщо потрібні пускові установки, чого ви можете досягти
з ними, і розглядає кілька прикладів, щоб краще описати їхні можливості. Для
детальна довідка про те, які параметри підтримуються пусковими установками, і спеціальний синтаксис для
файли програми запуску, подивіться /профілі.

Legacy прапорець поведінка контроль
У минулому поведінка Checkbox контролювалася трьома механізмами.

По-перше, функції прапорця можна було б розширити, додавши плагіни. Наприклад,
можливість подання на веб-сайт сертифікації додано пакетом checkbox-certification
за допомогою плагіна. Плагіни, включені за допомогою checkbox-certification і які додають нову поведінку
до базового прапорця були:

/usr/share/checkbox-certification/plugins/certify_message.py
/usr/share/checkbox-certification/plugins/submission_info.py
/usr/share/checkbox-certification/plugins/backup.py
/usr/share/checkbox-certification/plugins/certify_prompt.py
/usr/share/checkbox-certification/plugins/certify_report.py
/usr/share/checkbox-certification/plugins/certify_schemas.py

Вони додали спосіб запропонувати користувачеві ввести конкретні дані, генерувати xml
звіт та інші функції.

Далі поведінку плагінів можна налаштувати або керувати за допомогою конфігурації
файли, які є «каскадними». Конфігураційний файл може включати інші, а ті в свою чергу
включають інші.

Це приклад головного конфігураційного файлу project-qt.ini для конкретного проекту. Це перше
файл зчитується під час запуску клієнта конкретного проекту. Деякі параметри скорочено:

[DEFAULT]
включає = %(checkbox_oem_share)s/configs/checkbox-project-base-qt.ini %(checkbox_project_share)s/configs/checkbox-project-base.ini

[checkbox/plugins/environment_info]
репозиторії = deb http://.*\(архів\|безпека\).ubuntu.com/ubuntu точна-безпека
маршрутизатори = кілька
server_iperf = 10.20.30.40
список_джерел = / Etc / кв / sources.list
wpa_n_psk = пароль
wpa_n_ssid = точка доступу

[checkbox/plugins/user_interface]
title = Тестування системи мого проекту

Зверніть увагу на рядок включає, це вказує йому завантажити файл конфігурації для
checkbox-project-base-qt і checkbox-project-base. Checkbox-project-base-qt завантажує файл
конфігурації для checkbox-certification і checkbox-project. Налаштування каскадні, так що
Параметри конфігурації вгорі замінюють ті, що знаходяться в нижній частині.

Нарешті, «двійковий», який використовується для виклику прапорця, є сценарієм оболонки, який визначає, де знайти
потрібно запустити прапорець речі: ви можете визначити загальний каталог, конкретні дані
каталогу, вкажіть на файл конфігурації та визначте деякі змінні середовища, які ви
може знадобитися під час тестування. Ось приклад для checkbox-project-qt:

#!/ bin / bash
експорт CHECKBOX_DATA=${CHECKBOX_DATA:-~/.прапорець}
експорт CHECKBOX_SHARE=${CHECKBOX_SHARE:-/usr/share/checkbox}
експорт CHECKBOX_OPTIONS=${CHECKBOX_OPTIONS:---log-level=debug --log=$CHECKBOX_DATA/checkbox-project.log}
експорт CHECKBOX_CERTIFICATION_SHARE=${CHECKBOX_CERTIFICATION_SHARE:-/usr/share/checkbox-certification}
експорт CHECKBOX_OEM_SHARE=${CHECKBOX_PROJECT_BASE_SHARE:-/usr/share/checkbox-project-base}
експорт CHECKBOX_PROJECT_SHARE=${CHECKBOX_PROJECT_SHARE:-/usr/share/checkbox-project}

# Зручність для визначення каталогу PYTHONPATH.
if [ "$CHECKBOX_SHARE" != "/usr/share/checkbox" ]; тоді
експорт PYTHONPATH="$CHECKBOX_SHARE:$PYTHONPATH"
fi

python3 $CHECKBOX_SHARE/виконати "$@" $CHECKBOX_PROJECT_SHARE/configs/$(basename $0).ini

Тут ви можете побачити, що він визначає деякі розташування, і важливою частиною є остаточний python3
рядок, де він знаходить і використовуватиме необхідний файл конфігурації .ini, який ми бачили раніше.

Ця ієрархічна організація була дуже потужною, але з нею також було важко впоратися
також мали деякі обмеження. Частина роботи, яку ми виконали з прапорцем, полягала в тому, щоб інтегрувати всі
специфічні для проекту плагіни в стовбур прапорців, таким чином весь код ядра знаходиться в одному місці,
а варіанти для конкретного проекту надають лише завдання, білі списки, дані та конфігурацію,
без додавання нової поведінки.

Нові звичайна коробка поведінка контроль
На відміну від прапорця, ядро ​​Plainbox є монолітним і не має концепції плагінів. Це
полегшує розуміння та роботу з ним. Ядро Plainbox має реалізацію для всіх
функції в старих пакетах прапорців, тому для використання функцій не потрібно додавати
наприклад подання на сертифікацію або формування звіту.

Те, що ми називаємо plainbox, — це бібліотека, яка реалізує всю функціональність, як можна побачити
тут.

Plainbox надає інструменти, які допомагають розробникам тестів писати та пакувати тести. Це такі
поставляються в "постачальників", які є об'єктами, призначеними для інкапсуляції описів тестів,
користувацькі скрипти для тестування, білі списки та різноманітні дані. Вони були розроблені, щоб дозволити
команди, щоб написати та поставити свої власні тести, не турбуючись надто
базовий код простого ящика.

Щоб отримати інформацію про те, як писати тести та провайдерів, перегляньте підручник провайдера

Однак, коли фактично використовували ці тести для перевірки реальної системи, ми хотіли надати
щось простіше та ближче до користувацького досвіду прапорця. Ми створили двох клієнтів,
checkbox-gui та checkbox-cli, які мали певну жорстко закодовану поведінку, і ми також почали
створення інших клієнтів, які базувалися на них, але мали певну мету. Наприклад,
у нас була версія прапорця для тестування SRU, інша для сертифікації сервера тощо.

Але потім ми зрозуміли, що багато коду дублюється, а поведінка звичайна
за винятком кількох змін. Тому ми придумали поняття «пускові установки», які є
дещо схожий на файли конфігурації прапорців і програми запуску сценаріїв оболонки.

Ідея полягає в тому, що checkbox-gui і checkbox-cli мають деякі дуже основні особливості поведінки, оскільки вони
це клієнти, які за замовчуванням поставляються разом із ubuntu. Вони можуть показати все наявне
білих списків, показувати попередньо визначене вітальне повідомлення, а в кінці дозволить користувачеві побачити
html та надіслати його на панель запуску, використовуючи адресу електронної пошти, аналогічну версії
прапорця, що постачається разом із Ubuntu.

Замість використання складних перемикачів командного рядка, програми запуску дозволяють налаштувати деякі
додаткові способи поведінки, щоб налаштувати ваш досвід тестування. Панель запуску містить налаштування та
подібний до сценарію оболонки, але інтерпретатором буде або checkbox-gui, або
прапорець-запуск.

Ось кілька прикладів того, що можна зробити за допомогою пускових установок.

Як несподіванка, checkbox-cli сам по собі є запуском:

#!/usr/bin/env прапорець-запуск
[ласкаво просимо]
text = Ласкаво просимо до тестування системи!
Прапорець містить тести, щоб підтвердити, що ваша система працює належним чином.
Після завершення виконання тестів ви можете переглянути підсумковий звіт для
ваша система.
Попередження: деякі тести можуть призвести до зависання системи
не реагує. Будь ласка, збережіть всю свою роботу та закрийте всі інші запущені
додатків до початку процесу тестування.

[люкс]
whitelist_filter = ^за замовчуванням$
whitelist_selection = ^за замовчуванням$
skip_whitelist_selection = Правда

[транспорт]
submit_to = панель запуску

Ви можете побачити, що тут ми налаштовуємо кілька параметрів: воно автоматично показує вітальне повідомлення
вибирає білий список за замовчуванням і відправляється на панель запуску, коли це буде завершено.

Прикладом графічного запуску є canonical-certification-client.

#!/usr/bin/checkbox-gui

[ласкаво просимо]
title = "Сертифікація системи"
текст = " Ласкаво просимо до системи сертифікації! Ця програма буде
збирати інформацію зі своєї системи. Потім вам буде запропоновано виконати ручні тести
переконатися, що система працює належним чином. Нарешті, вас попросять
безпечний ідентифікатор комп’ютера для подання інформації на сертифікацію
бази даних. Щоб дізнатися, як створити або знайти безпечний ідентифікатор,
див. тут: certification.canonical.com "

[люкс]
whitelist_filter = "^клієнт-(сертифікат|самоперевірка).*"

[подання]
input_type = "регулярний вираз"
input_placeholder = "Захищений ідентифікатор (15 або 18 символів)"
ok_btn_text = "Надіслати результати"
submit_to_hexr = "правда"

[експортер]
xml_export_path = "/tmp/submission.xml"

[транспорт]
submit_to = "сертифікація"

Графічні лаунчери трохи складніші, але по суті це схоже, що це таке
дозволяє визначити деякі параметри, щоб налаштувати свій досвід тестування.

Дуже простим запуском у текстовому режимі є canonical-hw-collection, який просто запускає базовий
апаратна інформація перевіряє та завантажує її в апаратну базу даних:

[ласкаво просимо]
title = Збір інформації про обладнання
text = Збір інформації про обладнання. Можливо, вам буде запропоновано ввести пароль.
Цей процес займе приблизно 30 секунд, і вам буде надано
з URL-адресою, за допомогою якої можна підтвердити та зареєструвати своє обладнання
подання.

[люкс]
білий список_фільтр = ^hwsubmit$
whitelist_selection = ^hwsubmit$
skip_whitelist_selection = Правда
skip_test_selection = Правда

[подання]
# Підроблений secure_id гарантує, що ми його не запитуємо
# Його завжди можна змінити у файлі .conf.
secure_id = 000

[транспорт]
submit_to = сертифікація
submit_url = https://hardware-server.example.com/

Нарешті, canonical-driver-test-suite забезпечує як графічний, так і текстовий режими запуску,
які функціонально еквівалентні:

#!/usr/bin/checkbox-gui

[ласкаво просимо]
title = "Набір тестів Canonical Driver"
текст = " Ласкаво просимо до Canonical Driver Test Suite.

Ця програма містить автоматичні та ручні тести, які допоможуть вам знайти
проблеми, які виникнуть під час запуску драйверів пристроїв на Ubuntu.

Ця програма проведе користувача через ці тести в a
заздалегідь визначений порядок і автоматично збирає як системну інформацію, так і
а також результати тестів. Він також запропонує користувачеві ввести вручну
потрібне тестування.

Час виконання тестів визначається тим, які тести ви вирішили провести
виконувати. Користувач матиме можливість налаштувати тестовий запуск
врахувати водія та кількість часу, доступного для тестування.

Для початку просто натисніть кнопку «Продовжити» нижче та дотримуйтесь інструкцій на екрані
інструкції. "

[люкс]
whitelist_filter = "^ihv-.*"

[подання]
ok_btn_text = "Зберегти результати"
input_type = "немає"

[експортер]
xml_export_path = ""

[транспорт]
submit_to = "місцевий"

Текстовий режим:

#!/usr/bin/env прапорець-запуск
[ласкаво просимо]
text = Ласкаво просимо до Canonical Driver Test Suite
Ця програма містить автоматичні та ручні тести, які допоможуть вам знайти
проблеми, які виникнуть під час запуску драйверів пристроїв на Ubuntu.
Ця програма проведе користувача через ці тести в a
заздалегідь визначений порядок і автоматично збирає як системну інформацію, так і
а також результати тестів. Він також запропонує користувачеві ввести вручну
потрібне тестування.
Час виконання тестів визначається тим, які тести ви вирішите провести
виконувати. Користувач матиме можливість налаштувати тестовий запуск
врахувати водія та кількість часу, доступного для тестування.
Для початку просто натисніть кнопку «Продовжити» нижче та дотримуйтесь інструкцій на екрані
інструкціям.

[люкс]
# Білі списки, що відображаються на екрані вибору набору
білий список_фільтр = ^ihv-.*
# Вибір білого списку є обов'язковим, тому ми встановлюємо для нього фіктивне значення
# білих списків попередньо не вибрано.
whitelist_selection = фіктивний

ПРАВОК РЕЛІЗ ПРОЦЕС

На цій сторінці описано необхідні кроки для випуску версій Checkbox і Checkbox
Сертифікація стабільного PPA, що належить команді з сертифікації обладнання, на регулярній основі
основи. У цьому документі термін «чекбокс» використовується як загальний термін для охоплення
усі версії Checkbox належать команді з сертифікації обладнання, зараз Checkbox
себе та розширеннями Сертифікація Checkbox.

огляд
Наразі процес виконується раз на два тижні, з кожним новим випуском Checkbox
два тижні. Це охоплює десять робочих днів і завдання, що виконуються на кожен день або групу
днів описано нижче:

· Дні 1-4: час, дозволений для внесення нових змін у багажник.

· День 5: Зміни об'єднуються з магістралі lp: прапорець та lp: checkbox-certification до
їх відповідні гілки випуску. Журнали змін для обох є зіткнувся в цей момент і
редакції позначено тегами. На цьому етапі також може знадобитися скопіювати пакет 'fwts'
від FWTS Стабільний PPA <https://launchpad.net/~firmware-testing-team/+archive/ppa-
fwts-стабільний> до прапорець Відпустіть Тестування PPA <https://launchpad.net/~checkbox-
dev/+архів/тестування>.

· Дні 6-9: Тестування виконується менеджером випуску для сертифікації обладнання
команда та представник команди CE QA (основний замовник Checkbox в
канонічний)

· День 9: між менеджером випуску апаратного забезпечення проводиться зустріч з випуску
Команда сертифікації та представник команди CE QA. Потенційні проблеми з
звільнення визначено та розроблено плани щодо їх вирішення.

· День 10: Перевірена версія Checkbox копіюється до стабільного PPA.

Лаунчпад Філії
Для процесу випуску потрібні окремі гілки в Launchpad, які містять напівзаморожений
версія коду, яка була в багажнику на 5 день процесу. Це так, що розвиток
може продовжувати роботу в магістралі, не ставлячи під загрозу стабільність версії, яка буде випущена
Прапорець. Відносини між усіма галузями, які беруть участь у процесі, показано нижче:

· lp: прапорець/звільнення <- lp: прапорець

· lp: checkbox-certification/release <- lp: checkbox-certification

· lp:~checkbox-dev/checkbox/checkbox-packaging-release <-
lp:~checkbox-dev/checkbox/checkbox-packaging

Аудит етапний помилки
Перед створенням релізу-кандидата менеджер релізу повинен переглянути список помилок
важливою для наступного випуску Checkbox. Вони повинні відвідати прапорець віхи
<https://launchpad.net/checkbox/+milestonesmilestones> і знайдіть віху, датовану с
дата випуску.

· Для помилок, для яких встановлено значення In Progress з пов'язаною гілкою - зв'язок з гілкою
власника, щоб побачити, чи можна об’єднання завершити до кінцевого терміну.

· Для помилок, які знаходяться в будь-якому іншому незакритому статусі (крім виправляти Відданий) - повторна віха
їх до наступного етапу.

різання звільнити
Щоб вирізати реліз, ми повинні об’єднати зміни з магістралі в реліз
гілки, зафіксуйте їх відповідним повідомленням і оновіть журнал змін у магістралі, щоб
майбутні зміни стосуються правильної версії. Для кожної комбінації гілок, показаних вище,
виконайте наступне (у прикладі використовується lp: прапорець та lp: прапорець/звільнення):

bzr гілка lp: checkbox/release checkbox-release
bzr гілка lp: checkbox checkbox-trunk
cd прапорець-реліз
current_stable=`голова -n1 $(знайти. -name 'changelog') | grep -oP '(?<=\().*(?=\))'`
bzr злиття lp: checkbox

на цьому етапі, якщо немає змін (окрім однієї до debian/changelog) об’єднатися, тоді ми це зробимо
не виконувати випуск відповідного пакета. На практиці це часто трапляється з
прапорець-сертифікація але ніколи з прапорець:

bzr commit -m "Об'єднано зміни від rev$(bzr revno -r tag:$current_stable lp:checkbox) до rev$(bzr revno lp:checkbox) з lp:checkbox"
bzr push lp: checkbox/release
cd `знайти. -ім'я 'debian'`; компакт-диск ..
Тег bzr `head -n1 debian/changelog | grep -oP '(?<=\().*(?=\))'`
dch -r (зберегти змінений журнал змін)
dch -i -U 'Збільшений журнал змін'
debcommit
bzr push lp: checkbox

Останнім кроком у цьому процесі є збірка пакетів у файлі
ppa:checkbox-dev/testing PPA. Для цього нам потрібно перейти на сторінки рецептів
прапорець та / або прапорець-сертифікація звільнити гілки.

· checkbox-тестування рецепт <https://code.launchpad.net/~checkbox-dev/+recipe/checkbox-
Тестування>

· прапорець-сертифікація-тестування рецепт <https://code.launchpad.net/~checkbox-
dev/+recepe/checkbox-certification-testing>

Команда Будувати зараз опція має бути доступною на сторінці. Натисніть його, щоб розпочати збірку.

Копіювання прошивки Тест Набір до Тестування PPA
Інструмент Firmware Test Suite є інструментом тестування мікропрограми системи, яка, як правило, є сильною
використовується Checkbox. Щоб переконатися, що остання версія, яка містить виправлення та нові
тести/функції, необхідні для Checkbox, доступні, а також нічого не порушують
Прапорець, нам потрібно звільнити його разом із Checkbox. Після розрізання звільніть, якщо
Команда тестування прошивки повідомила, що нова версія доступна і ця версія
має бути використаний для сертифікації, нам потрібно скопіювати його в Testing PPA. Для цього ми
потрібно йти до Скопіювати пакети вид of прошивки Тест Набір (Стабільний) PPA
<https://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages> і
виберіть пакети 'fwts' для всіх випусків назад до Precise. Нам потрібно встановити
"Цільовий PPA" як "Checkbox Release Testing [~checkbox-dev/testing]" і "Copy
параметри», виберіть «Копіювати наявні двійкові файли», а потім натисніть «Копіювати пакети». Тоді цей крок
потрібно повторити, але в поле "Цільовий PPA" встановіть значення "PPA для розробників прапорців"
[~checkbox-dev/ppa]'.

МАЙБУТНІ Відпустіть of прапорець електронна пошта
Щоб кожен мав можливість своєчасно провести будь-яке необхідне тестування
Таким чином, після завершення збірок PPA слід надіслати електронний лист на наступну адресу
списки розсилки:

· [захищено електронною поштою] <сертифікація обладнання-
[захищено електронною поштою]>

· [захищено електронною поштою] <[захищено електронною поштою]>

Зміст зазвичай приблизно такий:

Тема: Наступний випуск прапорця (18)

привіт,

Наступний випуск Checkbox доступний у
https://code.launchpad.net/~checkbox-dev/+archive/testing PPA.
Будь ласка, перевірте це, коли вам зручно. Прапорець заснований на редакції 2484 оф
lp:checkbox і Checkbox Сертифікація заснована на версії 586
lp: checkbox-certification.

Спасибі,

Якщо те чи інше з Checkbox і Checkbox Certification не було оновлено
немає потреби згадувати цей пакет

Тестування звільнити
Тепер, коли випуск було скорочено, тестування має відбутися до зустрічі з випуском.
З точки зору сертифікаційної групи, те, що потрібно перевірити
прапорець-сертифікація-клієнт та прапорець-сертифікація-сервер які є основою для
Спеціальні версії Checkbox для CE QAs OEM. Сервер сертифікації прапорців тестується в
Клієнт сертифікації циклу CI Checkbox потрібно перевірити вручну.

Відпустіть Наради
У четвер перед звільненням проводиться зустріч представника с
команда з сертифікації та представник Комерційний Машинобудування QA команда The
Зустріч відбудеться о 7:30 UTC, як показано на цьому календар запрошувати
<https://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com>.
Порядок денний зустрічі міститься в запрошенні.

Видавничий звільнити
Щоб опублікувати реліз, нам просто потрібно скопіювати декілька пакетів з прапорець
Відпустіть Тестування PPA <https://launchpad.net/~checkbox-dev/+archive/testing> до апаратні засоби
сертифікація громадськості PPA <https://launchpad.net/~hardware-certification/+archive/public>.
Для цього переходимо до Скопіювати пакети вид of прапорець Відпустіть Тестування PPA
<https://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages> і виберіть усі
версії наступного списку пакетів: прапорець, прапорець-сертифікація, fwts. Зробіть
переконайтеся, що в полі «Destination PPA» встановлено значення «Public PPA for Hardware Certification
[~hardware-certification/public]" і що в полі "Параметри копіювання" встановлено значення "Копіювати
існуючі двійкові файли», а потім натисніть «Копіювати пакети».

Після цього потрібно надіслати електронний лист з оголошенням
[захищено електронною поштою] <[захищено електронною поштою]>.
Нижче наведено шаблон оголошення:

привіт,

Новий випуск прапорця було завантажено на апаратне забезпечення
Сертифікація Public PPA
(https://launchpad.net/~hardware-certification/+archive/public). The
випуск заснований на версії 2294 lp:checkbox

Спасибі,

Будь ласка, додайте останню частину журналу змін як примітки до випуску

· геніндекс

· модіндекс

· пошук

Використовуйте checkbox-cli онлайн за допомогою служб onworks.net