checkbox-cli – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

checkbox_ng - CheckboxNG-Dokumentation

CheckboxNG ist ein Hardware-Testtool, das für die Zertifizierung von Laptops, Desktops und Servern nützlich ist
mit Ubuntu. Es ist eine neue Version von Checkbox, die direkt auf PlainBox aufgebaut ist

KontrollkästchenNG ersetzt Kontrollkästchen ggf.

WARNUNG:
Die Dokumentation befindet sich in der Entwicklung. Manche Dinge sind falsch, ungenau oder beschreiben
Entwicklungsziele statt aktueller Zustand.

INSTALLATION

CheckboxNG kann von einem PPA (empfohlen) oder pypi auf Ubuntu Precise (12.04) installiert werden oder
neuer.

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

LAUFEN STABIL Loslassen AKTUALISIEREN TESTS

CheckboxNG bietet spezielle Unterstützung für die Ausführung stabiler Release-Update-Tests in einem automatisierten
Benehmen. Dies führt alle Jobs aus dem sru.whitelist und sendet die Ergebnisse an die
Zertifizierungs-Website.

Um SRU-Tests durchführen zu können, müssen Sie die sogenannte Secure ID Ihres Geräts kennen
testen. Sobald Sie wissen, dass Sie nur noch Folgendes tun müssen:

$ checkbox sru $secure_id Einreichung.xml

Das zweite Argument, Einreichung.xml, ist ein Name der Fallback-Datei, die nur erstellt wird
wenn das Senden der Daten an die Zertifizierungswebsite aus irgendeinem Grund nicht funktioniert.

REPORTING Fehler

Um Fehler im Checkbox-Projekt zu melden, benötigen Sie einen Launchpad-Account. Du wirst vielleicht finden
Anleitung on wie zu erstellen dank One <https://help.launchpad.net/YourAccount/NewAccount>
sinnvoll. Sobald Sie ein Konto haben, können Sie berichten Bugs <https://bugs.launchpad.net/checkbox-
Projekt/+Dateibug>.

Auf dieser Seite können Sie das Projekt auswählen, bei dem Sie den Fehler melden möchten (wir verwenden eine Reihe von
Projekte, um Veröffentlichungen zu koordinieren, und wir bevorzugen es, Fehler mit entsprechenden
Teil der Checkbox). Wenn Sie das richtige Projekt kennen, verwenden Sie es einfach und melden Sie den Fehler. Wenn
Sie kennen die Interna von Checkbox nicht so gut oder haben Zweifel, legen Sie es einfach auf der Basis ab
'Checkbox'-Projekt (Sie können verwenden fehlen uns die Worte. Direkt Link
<https://bugs.launchpad.net/checkbox/+filebug>.) Ein Mitglied des Entwicklungsteams wird
Überprüfen Sie Ihren Fehler und weisen Sie ihn dem entsprechenden Speicherort zu. Die Fehlernummer wird nicht
ändern, wenn das passiert.

Kontrollkästchen STAPEL

Der Checkbox-Stack ist eine Sammlung von Projekten, die zusammen einen vollständigen Test bilden
und Zertifizierungslösung. Es besteht aus den folgenden Teilen (siehe Tabelle unten für
zusätzliche Angaben). Alle Projekte sind von der Seite verlinkt Launchpad Projekt Gruppe
<https://launchpad.net/checkbox-project>.

Architektur Diagramm
[Bild: Architekturdiagramm] [Bild]

Dieses Diagramm enthält eine grobe Annäherung der aktuellen Checkbox-Architektur.
Es gibt drei Haupt-„Säulen“. Links haben wir Ende unsere Produkte. Das sind echte Werkzeuge
die Zertifizierung und Ingenieure verwenden. Rechts haben wir die Test Markt. Dies ist
ein offener Markt für Testanbieter und -lieferanten. Die Tests sind in Behälter verpackt, die als . bekannt sind
Anbieter. In der Mitte haben wir drei gemeinsame Komponenten. Diese implementieren den Großteil der
Framework und Benutzeroberflächen für die Testausführung. Endlich in der unteren linken Ecke da
ist ein Teil der Checkbox (eine Bibliothek), die für bestimmte Aufgaben mit HEXR geteilt wird. HEXR ist ein
außerhalb des Geltungsbereichs liegende Webanwendung, die von einem Teil des Zertifizierungsprozesses verwendet wird. Pfeile implizieren
Kommunikation mit der Form des Pfeils zeigt, wer wen anruft.

Wie bereits erwähnt, befinden sich in der mittleren Spalte drei Hauptkomponenten des gemeinsamen Codes
(wird von allen geteilt, die die unten besprochenen Endprodukte verwenden). Der gemeinsame Code ist
bestehend aus plainbox, checkbox-ng und checkbox-gui. Die Verantwortlichkeiten der Komponenten sind
in der folgenden Tabelle genauer besprochen. Hier sehen wir, dass die checkbox-gui DBus verwendet hat
API von checkbox-ng verfügbar gemacht, die wiederum checkbox-support (eine Hilfsbibliothek) verwendet
getrennt, also teilen Sie etwas Code mit HEXR) und plainbox.

In der rechten Spalte finden Sie verschiedene Testanbieter. Das Checkbox-Projekt ist
Herstellung und Pflege einer Reihe von Anbietern (siehe Tabelle unten), aber es wird erwartet
dass unsere nachgeschalteten Anwender auch ihre eigenen Anbieter (spezifisch für einen Kunden oder
Projekt). Eventuell kommen einige Anbieter von Drittanbietern, die die
Format.

Schließlich in der unteren linken Ecke, die gemeinsam genutzte Bibliothek, diese Bibliothek enthält viele Parser
verschiedener Dateiformate und Ausgabeformate. Technisch gesehen ist diese Bibliothek eine Abhängigkeit von
HEXR, Kontrollkästchen-ng und von Anbietern. Als zusätzliche Komplexität muss die Bibliothek aufgerufen werden
aus Python3-Code und Python2-Code.

Anmerkungen:
Die Kommunikation zwischen checkbox-ng und plainbox ist bidirektional. Plainbox-Angebote
einige Basisschnittstellen und Erweiterungspunkte. Diese werden alle durch Plainbox freigelegt
(unter Verwendung allgemeiner APIs), aber einige davon sind tatsächlich in checkbox-ng implementiert.

WARNUNG:
Alle internen APIs sind semi-instabil. Die DBus API ist in der Praxis stabiler, sollte aber
nicht verlassen werden. Es wird empfohlen, Projekte in lp:checkbox zusammenzuführen, wobei API
Übergänge können elegant gehandhabt werden. Die einzige stabile API ist das Dateiformat
Spezifikation (Auftragsdefinitionen und Whitelits). Launcher-Spezifikation wird sein
in der nächsten Ausgabe stabilisiert.

Komponente Beschreibungen
┌─────────────────────────┬─────────────────────── ──────────────────┬──────────────────────────┐
│Projekt │ Verantwortlich für │ Typ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Checkbox der nächsten Generation │ │ Anwendung │
(GUI) · Die C++/QML │ │
│ │ Benutzeroberfläche │ │
│ │ │ │
│ │ · Die grafische │ │
│ │ Launcher für │ │
│ │ Anbieter, zB │ │
│ │ checkbox-zertifizierung-client │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Checkbox der nächsten Generation │ │ Anwendung │
│(CLI) │ · Die Python-Befehlszeile │ │
│ │ Schnittstelle │ │
│ │ │ │
│ │ · die Text-Benutzeroberfläche │ │
│ │ │ │
│ │ · der SRU-Testbefehl │ │
│ │ │ │
│ · Zusätzliche Zertifizierungs-APIs │ │
│ │ │ │
│ │ · Daten an Launchpad senden │ │
│ │ │ │
│ │ · Daten an HEXR senden │ │
│ │ │ │
│ │ · der von │ │ . benötigte DBus-Dienst
│ │ GUI │ │
└─────────────────────────┴─────────────────────── ──────────────────┴──────────────────────────┘

│Kundenzertifizierung │ │ Anbieter │
│Anbieter │ · Canonical-Certification-Client │ │
│ │ ausführbare │ │
│ │ │ │
│ │ · Kundenzertifizierung │ │
│ │ weiße Listen │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Serverzertifizierung │ │ Anbieter │
│Provider │ · Serverzertifizierung │ │
│ │ weiße Listen │ │
│ │ │ │
│ │ · zusätzliche Server-Whitelists │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│System-on-Chip-Server │ │ Anbieter │
│Zertifizierungsanbieter │ · SoC-Server-Zertifizierung │ │
│ │ weiße Listen │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Checkbox Anbieter │ │ Anbieter │
│ │ · Fast alle Jobdefinitionen │ │
│ │ │ │
│ │ · Die meisten benutzerdefinierten "Skripte" │ │
│ │ │ │
│ │ · Standard- und SRU-Whitelist │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Ressourcenanbieter │ │ Anbieter │
│ │ · Fast alle Ressourcenjobs │ │
│ │ │ │
│ │ · Fast alle Ressourcen-"Skripte" │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│Checkbox-Unterstützung │ │ Bibliothek │
│ │ · Supportcode für verschiedene │ │
│ │ Anbieter │ │
│ │ │ │
│ │ · Parser für viele Textformate │ │
├─────────────────────────┼─────────────────────── ──────────────────┼──────────────────────────┤
│PlainBox │ │ Bibliothek und Entwicklung │
│ │ · Fast alle Kernlogik │ Toolkit │
│ │ │ │
│ │ · RFC822 (Jobdefinition) │ │
│ │ Parser │ │
│ │ │ │
│ │ · Konfigurationshandling │ │
│ │ │ │
│ │ · Testsitzung │ │
│ │ (unterbrechen/fortsetzen) │ │
│ │ │ │
│ │ · Jobrunner │ │
│ │ │ │
│ │ · Vertrauenswürdiger Launcher │ │
│ │ │ │
│ │ · Abhängigkeitsresolver │ │
│ │ │ │
│ │ · Kommandozeilen-Handling │ │
│ │ │ │
│ · XML, HTML und XSLX │
│ │ Exporteure │ │
│ │ │ │
│ │ · und mehr... │ │
│ │ │ │
│ · Toolkit für die Anbieterentwicklung │ │
│ │ │ │
│ │ · 'plainbox startprovider' │ │
│ │ │ │
│ · 'manage.py'-Implementierung │ │
└─────────────────────────┴─────────────────────── ──────────────────┴──────────────────────────┘

│Altes Kontrollkästchen (keine │ │ Monolithische Anwendung │
│länger gepflegt) │ · Anwendungen │ Bibliothek und Daten │
│ │ │ │
│ · Qt4 GUI │
│ │ │ │
│ · Gtk2-GUI │ │
│ │ │ │
│ · Urwid (Text) GUI │ │
│ │ │ │
│ │ · Kern │ │
│ │ │ │
│ │ · Plugin und Ereignis / Nachricht │ │
│ │ Motor │ │
│ │ │ │
│ │ · Fast alle Funktionen │ │
│ │ ein Core-Plugin implementiert │ │
│ │ │ │
│ │ · Daten │ │
│ │ │ │
│ │ · Jobs und Whitelists │ │
└─────────────────────────┴─────────────────────── ──────────────────┴──────────────────────────┘

ÄNDERUNGSPROTOKOLL

Anmerkungen:
Dieses Changelog enthält nur eine Zusammenfassung der Änderungen. Für eine genauere Abrechnung von
Entwicklungsgeschichte Bitte überprüfen Sie die Quellhistorie direkt.

KontrollkästchenNG 0.23 (unveröffentlicht)
· Fehlerbehebung: https://launchpad.net/checkbox-ng/+milestone/0.23

KontrollkästchenNG 0.22
· Fehlerbehebung: https://launchpad.net/checkbox-ng/+milestone/0.22

KontrollkästchenNG 0.3
· Fehlerbehebung: https://launchpad.net/checkbox-ng/+milestone/0.3

KontrollkästchenNG 0.2
· Fehlerbehebung: https://launchpad.net/checkbox-ng/+milestone/0.2

KontrollkästchenNG 0.1
· Erstveröffentlichung

· Unterstützung für die Anzeige der Konfiguration

· Unterstützung für die Durchführung von SRU-Tests (automatische Regressionstests)

TESTEN SKRIPTE

Testskripte sind kleine Programme, die bei der Durchführung von Tests helfen.

Helligkeitstest
Dieses Skript testet, ob die Helligkeit der Hintergrundbeleuchtung des Systems geändert werden kann
Kernel-Schnittstellen in /sys/class/backlight. Es kann mehr als eine Schnittstelle zur Auswahl geben
from, so wird die richtige zu verwendende Schnittstelle unter Verwendung der in vorgeschriebenen Heuristik ausgewählt
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight. Die Helligkeit
wird durch Aktualisieren der Helligkeitsdatei der Schnittstelle und der aktuellen_Helligkeit manipuliert
Datei wird überprüft, ob der Wert auf die ausgewählte Helligkeit geändert wurde.

PROFILE CONFIGURATION

Ausführungsprofile oder Startprogramme ermöglichen die Angabe eines vordefinierten Konfigurationssatzes
Optionen, die eine Anpassung des Begrüßungsbildschirms, der angezeigten Whitelists sowie
Ergebnisse lokal speichern oder die Einreichungsdatei an Launchpad oder an die Zertifizierung senden
database/HEXR, sowie einige andere Parameter.

Die Profileinstellungen sind Teil eines Launcher-Skripts und verwenden entweder checkbox-gui oder
checkbox-launcher (im Textmodus/CLI) als Shebang, um die Schlüssel/Werte zu interpretieren.

Dieses Dokument enthält eine Referenz zu Launcher-Funktionalität und -Syntax. Um das zu verstehen
Design und Konzepte und sehen Sie sich einige Beispiele an. Vielleicht möchten Sie die lesen Lernprogramm , wie
Launcher und ihre Beziehung zu Legacy Checkbox erstellen.

Syntax
Da checkbox-gui eine Qt-Anwendung ist, müssen die Einstellungen den INI-Stil-Regeln des
QEinstellungen <http://qt-project.org/doc/qt-5/QSettings.html> Klasse.

Mehrzeilige Werte werden unterstützt, müssen jedoch in doppelte Anführungszeichen und zusätzliche Zeilen eingeschlossen werden
muss mit einem Leerzeichen beginnen, zB:

[Kategorie]
key = "Hallo
Welt"

· Von QML:

settings.value("category/key", i18n.tr("default_value"))

· Von C++:

settings->value("category/key", app.tr("default_value"))

Umgekehrt müssen Checkbox-Launcher-spezifische Launcher folgen Python KonfigParser
<https://docs.python.org/3/library/configparser.html#supported-ini-file-structure> Syntax.

Außerdem sind einige Einstellungen nur für GUI oder CLI sinnvoll und werden daher von nicht verstanden
das andere. Diese sind unten vermerkt.

Unterstützte Einstellungen
Willkommen/Titel
Titel der QML-Anwendung und Kopfzeile des Begrüßungsbildschirms. Standardmäßig auf System Testen.

Willkommen/Text
Willkommensnachricht, die auf dem ersten Bildschirm angezeigt wird (Checkbox-GUI unterstützt Rich-Text
Markup im HTML-Stil zulassen). Standardmäßig auf Willkommen zu System Testen. [...]

suite/whitelist_filter
Regulärer Ausdruck, der mit einer Teilmenge von Whitelist-Dateinamen übereinstimmt. Auf checkbox-gui it
Standardmäßig ist .*. Für Checkbox-Launcher hat es keinen Standard und sollen definiert sein.

suite/whitelist_selection
Muster, denen Whitelists entsprechen müssen, um vorausgewählt zu werden. Regulärer Python-Ausdruck.
Es hat keine Vorgabe und sollen definiert sein. (nur CLI)

suite/skip_whitelist_selection
Wenn auf "true" gesetzt, erhält der Benutzer keine Auswahl der Whitelist. Nur die vorausgewählten
diejenigen (siehe whitelist_selection) werden ausgewählt. (Nur CLI).

suite/skip_test_selection
Wenn auf "true" gesetzt, darf der Benutzer die Tests vor der Ausführung nicht abwählen: alle Tests
in der ausgewählten Whitelist ausgeführt wird. (nur CLI)

Einreichung/Nachricht
Kopfzeilentext des Einreichungs-Pop-ups, der dem Benutzer nach der Einreichung angezeigt wird
vollendet. (nur GUI)

Einreichung/Eingabetyp
Zeigen Sie ein Texteingabefeld an, um die sichere ID oder die LP-Adresse einzugeben (Standard). Zu
Speichern Sie einfach die Ergebnisse auf der Festplatte, müssen Sie die keine Wert. Um mit einer Regex zu validieren,
muß Regex. (nur GUI)

Einreichung/Regex
Regulärer Ausdruck zur Validierung der Eingabe im Übermittlungsfeld (z. B. E-Mail, secure_id)
wenn input_type regex ist. (Nur GUI). RegExpValidator, Standard .*

Einreichung/Eingabe_Platzhalter
Temporärer Text, der in das Eingabefeld eingefügt werden soll, um den Benutzer zu führen. Launchpad E-Mail
Adresse (Standard) oder Security ID (15 or 18 Figuren). (nur GUI)

Einreichung/secure_id
Vorkonfigurierte secure_id zum Ausfüllen des Textfelds.

Einreichung/ok_btn_text
Die Beschriftung für die Schaltfläche "Senden". Absenden Die Ergebnisse (Standard) oder Speichern Die Ergebnisse. (GUI
nur)

Übermittlung/Abbrechen_Warnung
Dem Benutzer anzeigen, wenn er den Bericht verlassen möchte, ohne den Bericht gespeichert zu haben. Du bist dabei
um diesen Testlauf zu beenden, ohne Ihren Ergebnisbericht zu speichern. Möchten Sie die
Prüfbericht? (nur GUI)

Einreichung/submit_to_hexr
Boolean, fügen Sie einen zusätzlichen Header hinzu, um die Ergebnisse auch an HEXR zu senden (funktioniert mit dem
Zertifizierungstransport)

exporter/xml_export_pfad
Speicherort für die XML-Übermittlungsdatei, wenn auf eine leere Zeichenfolge gesetzt, öffnet sich a
Datei speichern Dialog. Standard: /tmp/submission.xml (nur GUI)

transportieren/submit_to
Transportendpunkt. Standardmäßig auf . Unterstützt die Übermittlung an LP (die Standardeinstellung,
Wert Launchpad), Zertifizierung, oder aus einer regionalen (auf Festplatte speichern)

transport/submit_url
URL, an die Ergebnisse gesendet werden sollen. Dies ermöglicht zum Beispiel das Hochladen auf verschiedene Websites
es kann direkt auf hexr oder auf die Staging-Sites hochgeladen werden. Nur verwendet mit dem
Zertifizierung send_to-Wert.

transport/config_dateiname
Name einer zu ladenden benutzerdefinierten Konfigurationsdatei. Konfigurationsdateien werden hauptsächlich verwendet, um zu definieren
Umgebungsvariablen. (nur CLI)

transport/dont_suppress_output
Wenn festgelegt, werden Ressourcen, lokale Jobs und Anhänge auf dem Bildschirm ausgegeben
erzeugt viel Text und dient hauptsächlich zum Debuggen. (nur CLI)

CHECKBOX/PLAINBOX STARTER TUTORIAL

Dieses Dokument erklärt, warum Trägerraketen notwendig sind und was Sie erreichen können
mit ihnen und geht auf mehrere Beispiele ein, um ihre Fähigkeiten besser zu beschreiben. Für ein
detaillierte Referenz zu den von Launchern unterstützten Einstellungen und spezifische Syntax für
Launcher-Dateien, siehe /profile.

Legacy Checkbox Verhalten Smartgeräte App
In der Vergangenheit wurde das Verhalten von Checkbox durch drei Mechanismen gesteuert.

Erstens könnten die Funktionen der Checkbox durch das Hinzufügen von Plugins erweitert werden. Zum Beispiel die
Möglichkeit zur Einreichung bei der Zertifizierungswebsite wurde durch das Checkbox-Zertifizierungspaket hinzugefügt
mithilfe eines Plugins. Die Plugins, die durch die Checkbox-Zertifizierung enthalten sind und die ein neues Verhalten hinzufügen
to base checkbox waren:

/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

Diese haben die Möglichkeit hinzugefügt, den Benutzer zur Eingabe spezifischer Daten aufzufordern, die XML-Datei zu generieren
Bericht und andere Funktionen.

Als nächstes könnte das Verhalten der Plugins mithilfe von Konfiguration konfiguriert oder gesteuert werden
Dateien, die "kaskadiert" sind. Eine Konfigurationsdatei kann andere enthalten und diese wiederum können
andere einbeziehen.

Dies ist ein Beispiel für eine projektspezifische Hauptkonfigurationsdatei project-qt.ini. Es ist das erste
Datei gelesen, wenn der projektspezifische Client gestartet wird. Einige Einstellungen werden abgekürzt:

[STANDARD]
enthält = %(checkbox_oem_share)s/configs/checkbox-project-base-qt.ini %(checkbox_project_share)s/configs/checkbox-project-base.ini

[Checkbox/plugins/environment_info]
Repositorys = deb http://.*\(Archiv\|Sicherheit\).ubuntu.com/ubuntu präzise-Sicherheit
Router = mehrere
server_iperf = 10.20.30.40
Quellen_Liste = / Etc / apt / sources.list
wpa_n_psk = Passwort
wpa_n_ssid = Zugangspunkt

[Checkbox/Plugins/Benutzeroberfläche]
title = Mein Projekt Systemtest

Beachten Sie die Zeile "Includes", die es anweist, die Konfigurationsdatei für zu laden
checkbox-project-base-qt und checkbox-project-base. Checkbox-project-base-qt lädt die
configs für Checkbox-Zertifizierung und Checkbox-Projekt. Die Einstellungen sind kaskadiert, sodass die
config-Optionen im oberen Bereich überschreiben die im unteren Bereich.

Schließlich ist die "Binärdatei", die zum Aufrufen der Checkbox verwendet wird, ein Shell-Skript, das definiert, wo es zu finden ist
die Dinge, die das Kontrollkästchen ausführen muss: Sie können ein Freigabeverzeichnis definieren, bestimmte Daten
Verzeichnis, zeigen Sie auf eine Konfigurationsdatei und definieren Sie einige Umgebungsvariablen, die Sie
kann während des Tests benötigt werden. Hier ist ein Beispiel für checkbox-project-qt:

#!/ bin / bash
CHECKBOX_DATA exportieren=${CHECKBOX_DATA:-~/.Kontrollkästchen}
export CHECKBOX_SHARE=${CHECKBOX_SHARE:-/usr/share/checkbox}
export CHECKBOX_OPTIONS=${CHECKBOX_OPTIONS:---log-level=debug --log=$CHECKBOX_DATA/checkbox-project.log}
export CHECKBOX_CERTIFICATION_SHARE=${CHECKBOX_CERTIFICATION_SHARE:-/usr/share/checkbox-certification}
export CHECKBOX_OEM_SHARE=${CHECKBOX_PROJECT_BASE_SHARE:-/usr/share/checkbox-project-base}
export CHECKBOX_PROJECT_SHARE=${CHECKBOX_PROJECT_SHARE:-/usr/share/checkbox-project}

# Komfort beim Definieren des PYTHONPATH-Verzeichnisses.
if [ "$CHECKBOX_SHARE" != "/usr/share/checkbox" ]; dann
export PYTHONPATH="$CHECKBOX_SHARE:$PYTHONPATH"
fi

python3 $CHECKBOX_SHARE/run "$@" $CHECKBOX_PROJECT_SHARE/configs/$(basename $0).ini

Hier können Sie sehen, dass es einige Standorte definiert und ein wichtiger Teil das endgültige Python ist3
line, wo es die erforderliche .ini-Konfigurationsdatei findet und verwendet, die wir zuvor gesehen haben.

Diese hierarchische Organisation war sehr mächtig, aber auch schwer zu handhaben, und
hatte auch einige Einschränkungen. Ein Teil der Arbeit, die wir mit Checkbox gemacht haben, war die Integration aller
projektspezifische Plugins in den Checkbox-Trunk, auf diese Weise ist der gesamte Kerncode an einem Ort,
und die projektspezifischen Varianten liefern nur Jobs, Whitelists, Daten und Konfiguration,
ohne neues Verhalten hinzuzufügen.

Neu Plainbox Verhalten Smartgeräte App
Im Gegensatz zu checkbox ist der Kern von plainbox monolythisch und hat kein Konzept von Plugins. Dies
erleichtert das Verstehen und Arbeiten. Der Plainbox-Kern hat Implementierungen für alle
die Funktionen in den alten Checkbox-Paketen, daher sind keine Ergänzungen notwendig, um Funktionen zu nutzen
B. die Einreichung zur Zertifizierung oder die Erstellung von Berichten.

Was wir Plainbox nennen, ist die Bibliothek, die alle Funktionen implementiert, wie man sehen kann
hier.

Plainbox bietet Tools, die Testentwicklern beim Schreiben und Paketieren von Tests helfen. Diese sind
in "Providern" geliefert, bei denen es sich um Einheiten handelt, die Testbeschreibungen kapseln sollen,
benutzerdefinierte Skripte zum Testen, Whitelists und verschiedene Daten. Sie wurden entwickelt, um zu ermöglichen
Teams, ihre benutzerdefinierten Tests zu schreiben und bereitzustellen, ohne sich zu viele Gedanken über die
zugrunde liegenden Plainbox-Code.

Informationen zum Schreiben von Tests und Anbietern finden Sie im Anbieter-Tutorial

Wenn wir diese Tests jedoch tatsächlich verwenden, um ein reales System zu verifizieren, wollten wir Folgendes bereitstellen:
etwas einfacher und näher an der Benutzererfahrung von Checkbox. Wir haben zwei Kunden erstellt,
checkbox-gui und checkbox-cli, die einige hartcodierte Verhaltensweisen hatten, und wir haben auch angefangen
Erstellung anderer Clients, die auf diesen basierten, aber zweckgebunden waren. Zum Beispiel,
Wir hatten eine Version des Kontrollkästchens für SRU-Tests, eine andere für die Serverzertifizierung und so weiter.

Aber dann stellten wir fest, dass ein Großteil des Codes dupliziert wurde und die Verhaltensweisen üblich waren
bis auf ein paar Änderungen. Also haben wir uns das Konzept der "Launcher" ausgedacht, die sind
ähnlich den Konfigurationsdateien von Checkboxen und Shell-Skript-Startprogrammen.

Die Idee ist, dass checkbox-gui und checkbox-cli einige sehr grundlegende Verhaltensweisen haben, da sie
sind die Clients, die standardmäßig mit Ubuntu ausgeliefert werden. Sie können alle verfügbaren anzeigen
Whitelists, zeigt eine vordefinierte Willkommensnachricht an und lässt den Benutzer am Ende die
html-Bericht und senden Sie ihn mit ihrer E-Mail-Adresse an das Launchpad, ähnlich der Version
des Kontrollkästchens, das mit Ubuntu geliefert wurde.

Anstatt komplizierte Befehlszeilenschalter zu verwenden, können Sie mit Launchern einige konfigurieren
optionale Verhaltensweisen, um Ihr Testerlebnis anzupassen. Ein Launcher enthält Einstellungen und
ähnelt einem Shell-Skript, aber der Interpreter ist entweder checkbox-gui oder
Checkbox-Starter.

Hier sind ein paar Beispiele dafür, was mit Trägerraketen gemacht werden kann.

Überraschenderweise ist checkbox-cli selbst ein Launcher:

#!/usr/bin/env Checkbox-Launcher
[willkommen]
text = Willkommen beim Systemtest!
Checkbox bietet Tests, um zu bestätigen, dass Ihr System ordnungsgemäß funktioniert.
Wenn Sie mit der Ausführung der Tests fertig sind, können Sie einen zusammenfassenden Bericht für
dein System.
Warnung: Einige Tests können dazu führen, dass Ihr System einfriert oder
nicht ansprechbar. Bitte speichern Sie Ihre gesamte Arbeit und schließen Sie alle anderen laufenden Arbeiten
Anträge, bevor Sie mit dem Testverfahren beginnen.

[mehr]
whitelist_filter = ^Standard$
whitelist_selection = ^Standard$
skip_whitelist_selection = Wahr

[Transport]
Submit_to = Launchpad

Sie können hier sehen, dass wir einige Optionen anpassen: Es wird automatisch eine Willkommensnachricht angezeigt
wählt die Standard-Whitelist aus und sendet sie an das Launchpad, wenn es fertig ist.

Ein grafisches Launcher-Beispiel ist canonical-certification-client.

#!/usr/bin/checkbox-gui

[willkommen]
title = "Systemzertifizierung"
Text = " Willkommen bei der Systemzertifizierung! Diese Anwendung wird
Informationen aus Ihrem System sammeln. Dann werden Sie zu manuellen Tests aufgefordert
bestätigen Sie, dass das System ordnungsgemäß funktioniert. Schließlich werden Sie gefragt
die sichere ID des Computers, um die Informationen an die Zertifizierung zu übermitteln
Datenbank. Um zu erfahren, wie Sie die sichere ID erstellen oder finden,
siehe hier: Certification.canonical.com "

[mehr]
whitelist_filter = "^client-(cert|selftest).*"

[Vorlage]
input_type = "regex"
input_placeholder = "Sichere ID (15 oder 18 Zeichen)"
ok_btn_text = "Ergebnisse senden"
Submit_to_hexr = "wahr"

[Exporteur]
xml_export_path = "/tmp/submission.xml"

[Transport]
Submit_to = "Zertifizierung"

Grafische Launcher sind etwas komplizierter, aber im Wesentlichen ist es ähnlich, was es ist
ermöglicht es Ihnen, einige Parameter zu definieren, um Ihr Testerlebnis anzupassen.

Ein sehr einfacher Textmodus-Launcher ist die Canonical-HW-Collection, die nur die Basics ausführt
Hardwareinformationen testen und in eine Hardwaredatenbank hochladen:

[willkommen]
title = Sammeln von Hardwareinformationen
text = Sammeln von Hardwareinformationen. Möglicherweise werden Sie nach Ihrem Passwort gefragt.
Dieser Vorgang dauert ungefähr 30 Sekunden und Sie werden zur Verfügung gestellt
mit einer URL, über die Sie Ihre Hardware bestätigen und registrieren können
Einreichung.

[mehr]
whitelist_filter = ^hwsubmit$
whitelist_selection = ^hwsubmit$
skip_whitelist_selection = Wahr
skip_test_selection = Wahr

[Vorlage]
# Eine gefälschte secure_id stellt sicher, dass wir nicht danach fragen
# Es kann jederzeit in der .conf-Datei überschrieben werden.
sichere_id = 000

[Transport]
Submit_to = Zertifizierung
send_url = https://hardware-server.example.com/

Schließlich bietet Canonical-Driver-Test-Suite sowohl einen grafischen als auch einen Textmodus-Launcher,
die funktional äquivalent sind:

#!/usr/bin/checkbox-gui

[willkommen]
title = "Canonical Driver Test Suite"
Text = " Willkommen bei der Canonical Driver Test Suite.

Dieses Programm enthält automatisierte und manuelle Tests, die Ihnen dabei helfen,
Probleme, die auftreten, wenn Sie Ihre Gerätetreiber unter Ubuntu ausführen.

Diese Anwendung führt den Benutzer durch diese Tests in a
vorgegebene Reihenfolge und sammeln automatisch sowohl Systeminformationen als auch
sowie Testergebnisse. Es fordert den Benutzer auch zur Eingabe auf, wenn es manuell ist
Prüfung erforderlich ist.

Die Laufzeit der Tests hängt davon ab, für welche Tests Sie sich entscheiden
ausführen. Der Benutzer hat die Möglichkeit, den Testlauf an
Anpassung an den Fahrer und die Zeit, die zum Testen zur Verfügung steht.

Um zu beginnen, klicken Sie einfach unten auf die Schaltfläche Weiter und folgen Sie den Anweisungen auf dem Bildschirm
Anweisungen. "

[mehr]
whitelist_filter = "^ihv-.*"

[Vorlage]
ok_btn_text = "Ergebnisse speichern"
input_type = "keine"

[Exporteur]
xml_export_path = ""

[Transport]
Submit_to = "lokal"

Textmodus:

#!/usr/bin/env Checkbox-Launcher
[willkommen]
text = Willkommen bei der Canonical Driver Test Suite
Dieses Programm enthält automatisierte und manuelle Tests, die Ihnen dabei helfen,
Probleme, die auftreten, wenn Sie Ihre Gerätetreiber unter Ubuntu ausführen.
Diese Anwendung führt den Benutzer durch diese Tests in a
vorgegebene Reihenfolge und sammeln automatisch sowohl Systeminformationen als auch
sowie Testergebnisse. Es fordert den Benutzer auch zur Eingabe auf, wenn es manuell ist
Prüfung erforderlich ist.
Die Laufzeit der Tests hängt davon ab, für welche Tests Sie sich entscheiden
ausführen. Der Benutzer hat die Möglichkeit, den Testlauf an
Anpassung an den Fahrer und die Zeit, die zum Testen zur Verfügung steht.
Um zu beginnen, klicken Sie einfach unten auf die Schaltfläche Weiter und folgen Sie den Anweisungen auf dem Bildschirm
Anweisungen.

[mehr]
# Whitelist(s), die im Suite-Auswahlbildschirm angezeigt werden
whitelist_filter = ^ihv-.*
# Whitelist_selection ist obligatorisch, daher setzen wir es auf einen falschen Wert
# Es sind keine Whitelists vorausgewählt.
whitelist_selection = falsch

Kontrollkästchen Loslassen PROZESSE

Auf dieser Seite werden die erforderlichen Schritte zum Freigeben von Versionen von Checkbox und Checkbox beschrieben
Regelmäßige Zertifizierung zum stabilen PPA des Hardware-Zertifizierungsteams
Basis. In diesem Dokument wird der Begriff 'Checkbox' als Sammelbegriff verwendet, um
alle Versionen von Checkbox im Besitz des Hardware-Zertifizierungsteams, derzeit Checkbox
selbst und die Checkbox-Zertifizierungserweiterungen.

Überblick
Derzeit läuft der Prozess im zweiwöchentlichen Rhythmus, mit einer neuen Version von Checkbox alle
zwei Wochen. Dies umfasst zehn Arbeitstage und die an jedem Tag oder Gruppe von
Tage ist im Folgenden beschrieben:

· Tage 1-4: Zeit für die Einführung neuer Änderungen in den Stamm.

· Tag 5: Änderungen werden aus dem Stamm von . zusammengeführt lp:Checkbox und lp:Checkbox-Zertifizierung zu
ihre jeweiligen Release-Zweig. Die Changelogs für beide sind gestoßen an dieser Stelle und
Revisionen sind markiert. In diesem Stadium kann es auch notwendig sein, das Paket 'fwts' zu kopieren
von dem FWTS Stabil PPA <https://launchpad.net/~firmware-testing-team/+archive/ppa-
fwts-stabil> zum Checkbox Loslassen Testen PPA <https://launchpad.net/~checkbox-
dev/+archiv/testing>.

· Tage 6-9: Die Tests werden vom Release Manager für die Hardwarezertifizierung durchgeführt
Team und ein Vertreter des CE-QS-Teams (der Hauptkunde für Checkbox innerhalb von
Kanonisch)

· Tag 9: Es findet ein Release-Meeting zwischen dem Release-Manager für die Hardware statt
Zertifizierungsteam und der Vertreter des CE-QS-Teams. Mögliche Probleme mit dem
Veröffentlichungen identifiziert und Pläne zu ihrer Behebung erstellt.

· Tag 10: Die getestete Version von Checkbox wird auf das stabile PPA kopiert.

Launchpad Branchen
Der Freigabeprozess erfordert separate Zweige in Launchpad, die ein halbgefrorenes . enthalten
Version des Codes, der sich an Tag 5 des Prozesses im Kofferraum befand. Dies ist so, dass die Entwicklung
kann auf dem Stamm fortgesetzt werden, ohne die Stabilität der zu veröffentlichenden Version von . zu gefährden
Kontrollkästchen. Die Beziehung zwischen allen am Prozess beteiligten Zweigen ist wie folgt:

· lp:Checkbox/Freigabe <- lp:Checkbox

· lp:Checkbox-Zertifizierung/Freigabe <- lp:Checkbox-Zertifizierung

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

Auditing Meilenstein Bugs
Vor dem Erstellen des Release-Kandidaten sollte der Release-Manager die Liste der Fehler überprüfen
Meilenstein für die nächste Version von Checkbox. Sie sollten besuchen Checkbox Meilensteine
<https://launchpad.net/checkbox/+milestonesmilestones> und suchen Sie den Meilenstein mit dem Datum
das Erscheinungsdatum.

· Bei Fehlern, die mit einem verknüpften Zweig auf In Bearbeitung gesetzt sind - mit dem Zweig in Verbindung treten
Eigentümer, um zu sehen, ob die Zusammenführung vor Ablauf der Frist abgeschlossen werden kann.

· Für Bugs, die sich in einem anderen nicht geschlossenen Status befinden (außer Fixieren Engagiert) - erneuter Meilenstein
sie zum nächsten Meilenstein.

Cutting Release
Um das Release zu kürzen, müssen wir die Änderungen von trunk in das Release einarbeiten
branch, bestätige sie mit einer passenden Nachricht und aktualisiere das Changelog im trunk so, dass
zukünftige Änderungen gehen unter die richtige Version. Für jede oben gezeigte Kombination von Zweigen,
gehen Sie wie folgt vor (das Beispiel verwendet lp:Checkbox und lp:Checkbox/Freigabe):

bzr-Zweig lp:checkbox/release checkbox-release
bzr branch lp:checkbox checkbox-trunk
CD-Checkbox-Freigabe
current_stable=`head -n1 $(find . -name 'changelog') | grep -oP '(?<=\().*(?=\))'`
bzr Merge lp:Checkbox

an dieser Stelle, wenn keine Änderungen (außer einer zu Debian/Änderungsprotokoll) fusionieren, dann tun wir es
keine Freigabe des betreffenden Pakets durchführen. In der Praxis passiert das oft mit
Checkbox-Zertifizierung aber nie mit Checkbox:

bzr commit -m "Änderungen von rev$(bzr revno -r tag:$current_stable lp:checkbox) zu rev$(bzr revno lp:checkbox) von lp:checkbox zusammengeführt"
bzr push lp:checkbox/release
cd `finden. -name 'debian'`; CD ..
bzr-Tag `head -n1 debian/changelog | grep -oP '(?<=\().*(?=\))'`
dch -r (Änderungsprotokoll speichern)
dch -i -U 'Inkrementiertes Änderungsprotokoll'
Debcommit
bzr push lp:Checkbox

Der letzte Schritt des Prozesses besteht darin, einen Build der Pakete im
ppa:checkbox-dev/testing PPA. Dazu müssen wir auf die Rezeptseiten für die
Checkbox und / oder Checkbox-Zertifizierung Zweige freigeben.

· Checkbox-Testen Rezept <https://code.launchpad.net/~checkbox-dev/+recipe/checkbox-
Natürlich sind wir auch auf Facebook zu finden: <br> <a href="https://www.facebook.com/tijhof.de" target="_blank" rel="noopener"><img class="alignleft wp-image-15850 size-full" src="https://tijhof.nl/wp-content/uploads/2024/03/facebookGmBh.png" alt="" width="250" height="50"></a>>

· Checkbox-Zertifizierungsprüfung Rezept <https://code.launchpad.net/~checkbox-
dev/+rezept/checkbox-zertifizierung-testen>

Das Bauen Option sollte auf der Seite verfügbar sein. Klicken Sie darauf, um einen Build zu starten.

Kopieren Firmware Test Suiten zu Testen PPA
Das Tool Firmware Test Suite ist ein Testtool für Systemfirmware, die naturgemäß stark
von Checkbox verwendet. Um sicherzustellen, dass die neueste Version, die Fixes und neue enthält,
Tests/Funktionen, die von Checkbox benötigt werden, sind verfügbar und brechen auch nichts ein
Checkbox, wir müssen es neben Checkbox freigeben. Nach dem Schneiden der Freigabe, wenn die
Das Firmware-Testteam hat benachrichtigt, dass eine neue Version verfügbar ist und dass diese Version
für die Zertifizierung verwendet werden soll, müssen wir es in das Testing PPA kopieren. Dazu wir
muss zum Kopieren Pakete view of Firmware Test Suiten (Stable) PPA
<https://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages> und
Wählen Sie die 'fwts'-Pakete für alle Releases zurück zu Precise. Wir müssen die einstellen
'Destination PPA' als 'Checkbox Release Testing [~checkbox-dev/testing]' und die 'Copy
Optionen“ auf „Vorhandene Binärdateien kopieren“ und klicken Sie dann auf „Pakete kopieren“. Dieser Schritt dann
muss wiederholt werden, aber setzen Sie das Feld "Ziel-PPA" auf "PPA für Checkbox-Entwickler".
[~checkbox-dev/ppa]'.

Weiter Loslassen of Checkbox Email
Damit jeder die Möglichkeit hat, alle erforderlichen Prüfungen rechtzeitig durchzuführen
Weise sollte nach Abschluss der PPA-Builds eine E-Mail an folgende Adresse gesendet werden
Mailinglisten:

· [E-Mail geschützt] <Hardware-Zertifizierung-
[E-Mail geschützt] >

· [E-Mail geschützt] <[E-Mail geschützt] >

Der Inhalt sieht normalerweise so aus:

Betreff: Nächste Veröffentlichung der Checkbox (18)

Hallo,

Die nächste Version von Checkbox ist im
https://code.launchpad.net/~checkbox-dev/+archive/testing PPA.
Bitte testen Sie es nach Belieben. Kontrollkästchen basiert auf Überarbeitung 2484 von
Die lp:checkbox- und Checkbox-Zertifizierung basiert auf Revision 586 von
lp:Checkbox-Zertifizierung.

Vielen Dank,

Wenn das eine oder andere der Checkbox- und Checkbox-Zertifizierungen nicht aktualisiert wurde, dann
Das Paket muss nicht erwähnt werden

Testen Release
Nachdem das Release nun gekürzt wurde, sollten die Tests vor dem Release-Meeting stattfinden.
Aus Sicht des Zertifizierungsteams ist zu prüfen:
checkbox-zertifizierung-client und checkbox-zertifizierungsserver die die Grundlage bilden für
CE QAs OEM-spezifische Versionen von Checkbox. Der Checkbox-Zertifizierungsserver wird in der . getestet
Der CI-Loop Checkbox-Zertifizierungsclient muss manuell getestet werden.

Loslassen Treffen
Am Donnerstag vor der Veröffentlichung findet ein Treffen zwischen einem Vertreter der
das Zertifizierungsteam und ein Vertreter der Gewerbe Entwicklung QA Mannschaft. Das
Das Meeting findet um 7:30 UTC statt, wie hier gezeigt Kalender einladen
<https://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com>.
Eine Tagesordnung für die Sitzung ist in der Einladung enthalten.

Publishing Release
Um die Veröffentlichung zu veröffentlichen, müssen wir lediglich eine Reihe von Paketen aus dem Checkbox
Loslassen Testen PPA <https://launchpad.net/~checkbox-dev/+archive/testing> zum Hardware
Zertifizierung Öffentliche PPA <https://launchpad.net/~hardware-certification/+archive/public>.
Dazu gehen wir zum Kopieren Pakete view of Checkbox Loslassen Testen PPA
<https://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages> und alle auswählen
Versionen der folgenden Paketliste: Kontrollkästchen, Checkbox-Zertifizierung, fwts. Machen
Stellen Sie sicher, dass das Feld 'Destination PPA' auf 'Public PPA for Hardware Certification . eingestellt ist
[~hardware-certification/public]' und dass das Feld 'Kopieroptionen' auf 'Kopie . gesetzt ist
vorhandene Binärdateien“ und klicken Sie dann auf „Pakete kopieren“.

Danach sollte eine Ankündigungs-E-Mail gesendet werden an
[E-Mail geschützt] <[E-Mail geschützt] >.
Eine Vorlage für die Ankündigung ist unten enthalten:

Hallo,

Eine neue Version der Checkbox wurde auf die Hardware hochgeladen
Zertifizierung Öffentliches PPA
(https://launchpad.net/~hardware-certification/+archive/public). Die
Release basiert auf Revision 2294 von lp:checkbox

Vielen Dank,

Bitte fügen Sie den neuesten Teil des Changelogs als Versionshinweise bei

· Genindex

· Modindex

· Suche

Verwenden Sie checkbox-cli online über die Dienste von onworks.net