checkbox-cli - Online nel cloud

PROGRAMMA:

NOME

checkbox_ng - Documentazione CheckboxNG

CheckboxNG è uno strumento di test hardware utile per certificare laptop, desktop e server
con Ubuntu. È una nuova versione di Checkbox che è costruita direttamente su PlainBox

Casella di controlloNG sostituisce Casella di controllo, ove applicabile.

ATTENZIONE:
La documentazione è in fase di sviluppo. Alcune cose sono sbagliate, imprecise o descritte
obiettivi di sviluppo piuttosto che lo stato attuale.

MONTAGGIO

CheckboxNG può essere installato da un PPA (consigliato) o pypi su Ubuntu Precise (12.04) o
più nuovo.

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

JOGGING vs RUNNING STABILE STAMPA AGGIORNAMENTO PROVE

CheckboxNG ha un supporto speciale per l'esecuzione di test di aggiornamenti di rilascio stabili in modo automatizzato
maniera. Questo esegue tutti i lavori dal sru.lista bianca e invia i risultati al
sito web di certificazione.

Per eseguire i test SRU dovrai conoscere il cosiddetto Secure ID del dispositivo che sei
test. Una volta che sai che tutto ciò che devi fare è eseguire:

$ checkbox sru $secure_id sottomissione.xml

Il secondo argomento, submit.xml, è un nome del file di fallback che viene solo creato
quando si inviano i dati al sito di certificazione non funziona per qualsiasi motivo.

REPORTING BUG

Per segnalare bug sul progetto Checkbox avrai bisogno di un account launchpad. Puoi trovare
istruzioni on come a creare prima <https://help.launchpad.net/YourAccount/NewAccount>
utile. Una volta che hai un account puoi rapporto bug <https://bugs.launchpad.net/checkbox-
progetto/+filebug>.

In quella pagina puoi selezionare il progetto su cui desideri archiviare il bug (usiamo un numero di
progetti per coordinare i rilasci e preferiamo avere bug associati ad appropriati
parte della casella di controllo). Se conosci il progetto giusto da usare, usalo e archivia il bug. Se
non conosci molto gli interni di Checkbox o hai dei dubbi, basta archiviarlo sulla base
Progetto 'Checkbox' (puoi usare questo dirette link
<https://bugs.launchpad.net/checkbox/+filebug>.) Un membro del team di sviluppo lo farà
rivedi il tuo bug e riassegnalo alla posizione appropriata. Il numero di bug non lo farà
cambiare quando ciò accade.

LA CASELLA DI CONTROLLO PILA

Il Checkbox Stack è una raccolta di progetti che insieme costituiscono un test completo
e soluzione di certificazione. È composto dalle seguenti parti (vedi tabella sotto per
dettagli aggiuntivi). Tutti i progetti sono collegati a dal Launchpad progetto gruppo
<https://launchpad.net/checkbox-project>.

Architettura Diagramma
[immagine: Diagramma dell'architettura] [immagine]

Questo diagramma contiene un'approssimazione di alto livello dell'attuale architettura Checkbox.
Ci sono tre "pilastri" principali. A sinistra abbiamo fine prodotti. Questi sono strumenti reali
che la certificazione e gli ingegneri stanno utilizzando. A destra abbiamo il test mercato. Questo è
un mercato aperto di venditori e fornitori di test. I test sono avvolti in contenitori noti come
fornitori. Al centro abbiamo tre componenti condivisi. Quelli implementano la maggior parte del
framework e interfacce utente per l'esecuzione dei test. Finalmente nell'angolo in basso a sinistra c'è
è una parte della casella di controllo (una libreria) condivisa con HEXR per determinate attività. HEXR è un
applicazione web fuori ambito utilizzata da parte del processo di certificazione. Le frecce implicano
comunicazione con la forma della freccia mostra chi chiama chi.

Come accennato in precedenza, nella colonna centrale ci sono tre componenti principali del codice condiviso
(condiviso da tutti coloro che utilizzano i prodotti finali discussi di seguito). Il codice condiviso è
composto da plainbox, checkbox-ng e checkbox-gui. Le responsabilità dei componenti sono
discusso più dettagliatamente nella tabella sottostante. Qui possiamo vedere che checkbox-gui usa DBus
API esposta da checkbox-ng, che a sua volta utilizza checkbox-support (una libreria di supporto
separati in modo da condividere del codice con HEXR) e plainbox.

Nella colonna di destra ci sono vari fornitori di test. Il progetto checkbox è
produrre e mantenere un numero di fornitori (vedere la tabella seguente) ma è previsto
che i nostri utilizzatori a valle produrranno anche i propri fornitori (specifici per un cliente o
progetto). Eventualmente alcuni provider potrebbero provenire da soggetti terzi che adotteranno il
formato.

Infine nell'angolo in basso a sinistra, la libreria condivisa, questa libreria contiene molti parser
di vari formati di file e formati di output. Tecnicamente questa libreria è una dipendenza di
HEXR, casella di controllo-ng ed di fornitori. Come ulteriore complessità, è necessario chiamare la libreria
dal codice python3 e dal codice python2.

NOTA:
La comunicazione tra checkbox-ng e plainbox è bidirezionale. Offerte Plainbox
alcune interfacce di base e punti di estensione. Questi sono tutti esposti tramite plainbox
(usando API comuni) ma alcune di queste sono effettivamente implementate in checkbox-ng.

ATTENZIONE:
Tutte le API interne sono semi-instabili. L'API DBus è più stabile in pratica ma dovrebbe
non fare affidamento. I progetti sono incoraggiati a essere uniti in lp: checkbox dove API
le transizioni possono essere gestite con grazia. L'unica API stabile è il formato file
specifica (definizioni di lavoro e whitelit). Le specifiche del lanciatore saranno
stabilizzato nella prossima versione.

Componente descrizioni
? ?
│Progetto │ Responsabile di │ Tipo │
? ?
│Casella di controllo di nuova generazione │ │ Applicazione │
│(GUI) · Il C++/QML
│ │ interfaccia utente │ │
│ │ │ │
│ │ · La grafica │ │
│ │ launcher per │ │
│ │ fornitori, ad es. │ │
│ │ checkbox-certificazione-cliente │ │
? ?
│Casella di controllo di nuova generazione │ │ Applicazione │
│(CLI) │ · La riga di comando di Python │ │
│ │ interfaccia │ │
│ │ │ │
│ │ · l'interfaccia utente testuale │ │
│ │ │ │
│ │ · il comando di test SRU │ │
│ │ │ │
│ │ · API di certificazione aggiuntive │ │
│ │ │ │
│ │ · invio di dati a Launchpad │ │
│ │ │ │
│ │ · invio dati a HEXR │ │
│ │ │ │
│ │ · il servizio DBus necessario a │ │
│ │ GUI │ │
? ?

Certificazione del cliente │ │ Fornitore │
│Fornitore │ · client-certificazione-canonica │ │
│ │ eseguibile │ │
│ │ │ │
│ │ · certificazione cliente │ │
│ │ whitelist │ │
? ?
Certificazione server │ │ Provider │
│Fornitore │ · certificazione server │ │
│ │ whitelist │ │
│ │ │ │
│ │ · whitelist di server aggiuntivi │ │
? ?
│Server System-on-Chip │ │ Provider │
Fornitore di certificazione │ · Certificazione server SoC │ │
│ │ whitelist │ │
? ?
│Casella di controllo Provider │ │ Provider │
│ │ · Quasi tutte le definizioni di lavoro │ │
│ │ │ │
│ │ · La maggior parte degli "script" personalizzati │ │
│ │ │ │
│ │ · Lista bianca predefinita e SRU │ │
? ?
Fornitore di risorse │ │ Fornitore │
│ │ · Quasi tutti i lavori delle risorse │ │
│ │ │ │
│ │ · Quasi tutte le risorse "script" │ │
? ?
│Supporto casella di controllo │ │ Libreria │
│ │ · Codice di supporto per vari │ │
│ │ fornitori │ │
│ │ │ │
│ │ · Parser per molti formati di testo │ │
? ?
│PlainBox │ │ Libreria e sviluppo │
│ │ · Quasi tutta la logica di base │ Toolkit │
│ │ │ │
│ │ · RFC822 (definizione del lavoro) │ │
│ │ analizzatore │ │
│ │ │ │
│ │ · Gestione della configurazione │ │
│ │ │ │
│ │ · Sessione di test │ │
│ │ (sospendi/riprendi) │ │
│ │ │ │
│ │ · Corridore di lavoro │ │
│ │ │ │
│ │ · Launcher affidabile │ │
│ │ │ │
│ │ · Risolutore di dipendenze │ │
│ │ │ │
│ │ · Gestione della riga di comando │ │
│ │ │ │
· XML, HTML e XSLX
│ │ esportatori │ │
│ │ │ │
│ │ · e altro ancora... │ │
│ │ │ │
│ │ · Toolkit di sviluppo del provider │ │
│ │ │ │
│ │ · 'plainbox startprovider' │ │
│ │ │ │
│ │ · Implementazione di 'manage.py' │ │
? ?

│Casella di controllo legacy (no │ │ Applicazione monolitica │
più mantenuto) │ · Applicazioni │ Libreria e dati │
│ │ │ │
│ · GUI Qt4 │ │
│ │ │ │
│ · GUI Gtk2 │
│ │ │ │
│ · Interfaccia grafica Urwid (testo) │ │
│ │ │ │
│ │ · Nucleo │ │
│ │ │ │
│ │ · Plugin ed Evento/Messaggio │ │
│ │ Motore │ │
│ │ │ │
│ │ · Quasi tutte le funzionalità │ │
│ │ ha implementato un plugin di base │ │
│ │ │ │
│ │ · Dati │ │
│ │ │ │
│ │ · Lavori e whitelist │ │
? ?

CHANGELOG

NOTA:
Questo registro delle modifiche contiene solo un riepilogo delle modifiche. Per una contabilizzazione più accurata di
cronologia di sviluppo si prega di controllare direttamente la cronologia di origine.

Casella di controlloNG 0.23 (inedito)
· Correzioni di bug: https://launchpad.net/checkbox-ng/+milestone/0.23

Casella di controlloNG 0.22
· Correzioni di bug: https://launchpad.net/checkbox-ng/+milestone/0.22

Casella di controlloNG 0.3
· Correzioni di bug: https://launchpad.net/checkbox-ng/+milestone/0.3

Casella di controlloNG 0.2
· Correzioni di bug: https://launchpad.net/checkbox-ng/+milestone/0.2

Casella di controlloNG 0.1
· Versione iniziale

· Supporto per la visualizzazione della configurazione

· Supporto per l'esecuzione di test SRU (test di regressione automatica)

TEST SCRIPT

Gli 'script' di test sono piccoli programmi utilizzati per aiutare nell'implementazione dei test.

luminosità_test
Questo script verifica che la luminosità della retroilluminazione del sistema può essere modificata utilizzando il pulsante
interfacce del kernel in /sys/class/backlight. Potrebbe esserci più di un'interfaccia tra cui scegliere
da, quindi l'interfaccia corretta da utilizzare viene selezionata utilizzando l'euristica prescritta in
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight. La luminosità
viene manipolato aggiornando il file di luminosità dell'interfaccia e la luminosità_effettiva
file viene controllato per vedere se il valore è stato modificato in base alla luminosità selezionata.

PROFILI CONFIGURAZIONE

I profili di esecuzione, o lanciatori, consentono di specificare un set predefinito di configurazione
opzioni che consentono la personalizzazione della schermata di benvenuto, delle whitelist visualizzate e
salvare i risultati localmente o inviare il file di invio a Launchpad o alla Certificazione
database/HEXR, così come alcuni altri parametri.

Le impostazioni del profilo fanno parte di uno script di avvio e utilizzano la casella di controllo-gui o
checkbox-launcher (in modalità testo/CLI) come shebang per interpretare la chiave/i valori.

Questo documento fornisce un riferimento sulla funzionalità e la sintassi del programma di avvio. Per capire il
design e concetti e vedere diversi esempi, potresti voler leggere il lezione su come
creare lanciatori e la loro relazione con Checkbox legacy.

Sintassi
Poiché checkbox-gui è un'applicazione Qt, le impostazioni devono seguire le regole in stile INI del
QImpostazioni <http://qt-project.org/doc/qt-5/QSettings.html> classe.

I valori su più righe sono supportati ma devono essere racchiusi tra virgolette doppie e righe aggiuntive
deve iniziare con uno spazio, ad esempio:

[categoria]
chiave = "Ciao
Mondo"

· Da QML:

settings.value("categoria/chiave", i18n.tr("valore_predefinito"))

· Da C++:

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

Al contrario, devono seguire i lanciatori specifici per il lanciatore di caselle di controllo Python Configura parser
<https://docs.python.org/3/library/configparser.html#supported-ini-file-structure> sintassi.

Inoltre, alcune impostazioni hanno senso solo per GUI o CLI e quindi non sono comprese da
l'altro. Questi sono indicati di seguito.

supportato Impostazioni profilo
benvenuto/titolo
Titolo dell'applicazione QML e intestazione della schermata di benvenuto. Il valore predefinito è Sistema Testing.

benvenuto/testo
Messaggio di benvenuto da visualizzare nella prima schermata (checkbox-gui supporta Rich text
consentendo il markup in stile HTML). Il valore predefinito è Accoglienza a Sistema Test. [...]

suite/filtro_lista bianca
Espressione regolare per la corrispondenza con un sottoinsieme di nomi di file della whitelist. Su checkbox-gui it
il valore predefinito è .*. Per checkbox-launcher non ha impostazioni predefinite e devono obbligatoriamente: essere definito.

suite/whitelist_selection
Pattern a cui le whitelist devono corrispondere per essere preselezionate. Espressione regolare Python.
Non ha impostazioni predefinite e devono obbligatoriamente: essere definito. (solo CLI)

suite/skip_whitelist_selection
Se impostato su true, l'utente non riceverà una scelta di whitelist. Solo i preselezionati
quelli (vedi whitelist_selection) saranno selezionati. (solo CLI).

suite/salta_selezione_test
Se impostato su true, l'utente non potrà deselezionare i test prima dell'esecuzione: tutti i test
nella whitelist selezionata verrà eseguito. (solo CLI)

sottomissione/messaggio
Testo dell'intestazione del pop-up di invio, mostrato all'utente dopo che l'invio è stato effettuato
completato. (solo GUI)

sottomissione/tipo_input
Mostra un campo di immissione testo per inserire l'ID protetto o l'indirizzo LP (predefinito). Per
basta salvare i risultati su disco, è necessario utilizzare il nessuna valore. Per convalidare utilizzando un'espressione regolare,
deve essere regex. (solo GUI)

sottomissione/regex
Espressione regolare per convalidare l'input nel campo di invio (ad es. email, secure_id)
se input_type è regex. (solo GUI). RegExpValidator, predefinito .*

sottomissione/input_placeholder
Testo temporaneo da inserire nel campo di input, utilizzato per guidare l'utente. Launchpad E-mail
Indirizzo (predefinito) o Sicuro ID (15 or 18 personaggi). (solo GUI)

sottomissione/secure_id
secure_id preconfigurato per compilare il campo di testo.

sottomissione/ok_btn_text
L'etichetta per il pulsante "Invia". Invio Risultati (predefinito) o Risparmi Risultati. (GUI
solo)

submit/cancel_warning
Mostra all'utente se vuole uscire senza aver salvato il report. Stai per
per uscire da questa esecuzione di test senza salvare il report dei risultati. Vuoi salvare il
rapporto? (solo GUI)

submit/submit_to_hexr
Boolean, aggiungi un'intestazione extra per inviare anche i risultati a HEXR (funziona con il
certificazione trasporto)

esportatore/percorso_esportazione_xml
Posizione per salvare il file di invio XML, se impostato su una stringa vuota si aprirà a
finestra di dialogo per il salvataggio del file. Predefinito: /tmp/invio.xml (solo GUI)

trasporto/invio_a
Endpoint di trasporto. Il valore predefinito è . Supporta l'invio a LP (l'impostazione predefinita,
APPREZZIAMO trampolino di lancio), Certificazione, o locale (salva su disco)

trasporto/invio_url
URL a cui inviare i risultati. Ciò consente di caricare su diversi siti Web, ad esempio
può caricare direttamente su hexr o sui siti di staging. Usato solo con il
Certificazione invia_a valore.

trasporto/nome_file_config
Nome di un file di configurazione personalizzato da caricare. I file di configurazione sono usati principalmente per definire
variabili ambientali. (solo CLI)

trasporto/dont_suppress_output
Se impostato, le risorse, i lavori locali e gli allegati verranno visualizzati sullo schermo, questo
genera molto testo ed è principalmente per il debug. (solo CLI)

CASELLA DI ASSEGNO/CASELLA SEMPLICE LANCIATORI TUTORIAL

Questo documento fornisce una spiegazione del perché i lanciatori sono necessari, cosa puoi ottenere
con loro, e passa attraverso diversi esempi per descrivere meglio le loro capacità. Per un
riferimento dettagliato su quali impostazioni sono supportate dai lanciatori e sintassi specifica per
file di avvio, guarda /profili.

Eredità casella di controllo comportamento di controllo
In passato, il comportamento di Checkbox era controllato da tre meccanismi.

Innanzitutto, le funzioni della casella di controllo potrebbero essere aumentate aggiungendo plugin. Ad esempio, il
la possibilità di inviare al sito Web di certificazione è stata aggiunta dal pacchetto di certificazione della casella di controllo
utilizzando un plug-in. I plugin inclusi da checkbox-certification e che aggiungono nuovi comportamenti
alla casella di controllo di base erano:

/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

Questi hanno aggiunto il modo per richiedere all'utente dati specifici per l'invio, generare l'xml
relazione e altre funzioni.

Successivamente, i comportamenti dei plugin potrebbero essere configurati o controllati utilizzando la configurazione
file, che sono "a cascata". Un file di configurazione può includerne altri e questi possono a loro volta
includerne altri.

Questo è un esempio di un file di configurazione principale project-qt.ini specifico del progetto. È il primo
file letto all'avvio del client specifico del progetto. Alcune impostazioni sono abbreviate:

[PREDEFINITO]
include = %(checkbox_oem_share)s/configs/checkbox-project-base-qt.ini %(checkbox_project_share)s/configs/checkbox-project-base.ini

[casella di controllo/plugin/info_ambiente]
repository = deb http:///.*\(archivio\|sicurezza\).ubuntu.com/ubuntu precision-security
router = multiplo
server_iperf = 10.20.30.40
source_list = / Etc / apt / sources.list
wpa_n_psk = password
wpa_n_ssid = punto di accesso

[casella di controllo/plugin/interfaccia_utente]
title = Il mio progetto Test di sistema

Notare la riga include, che indica di caricare il file di configurazione per
checkbox-project-base-qt e checkbox-project-base. Checkbox-project-base-qt carica il
configs per checkbox-certification e checkbox-progetto. Le impostazioni sono in cascata quindi il
le opzioni di configurazione in alto sovrascrivono quelle in basso.

Infine, il "binario" utilizzato per invocare la casella di controllo è uno script di shell che definisce dove trovare
la casella delle cose deve essere eseguita: puoi definire una directory condivisa, un dato specifico
directory, puntare a un file di configurazione e definire alcune variabili di ambiente che si
potrebbe essere necessario durante il test. Ecco un esempio per checkbox-project-qt:

#!/ bin / bash
esporta CHECKBOX_DATA=${CHECKBOX_DATA:-~/.casella di controllo}
esporta CHECKBOX_SHARE=${CHECKBOX_SHARE:-/usr/condividi/casella di controllo}
esporta CHECKBOX_OPTIONS=${CHECKBOX_OPTIONS:---log-level=debug --log=$CHECKBOX_DATA/checkbox-project.log}
export CHECKBOX_CERTIFICATION_SHARE=${CHECKBOX_CERTIFICATION_SHARE:-/usr/share/certificazione-casella}
esporta CHECKBOX_OEM_SHARE=${CHECKBOX_PROJECT_BASE_SHARE:-/usr/share/checkbox-project-base}
esporta CHECKBOX_PROJECT_SHARE=${CHECKBOX_PROJECT_SHARE:-/usr/share/checkbox-project}

# Convenienza per definire la directory PYTHONPATH.
if [ "$CHECKBOX_SHARE" != "/usr/share/checkbox" ]; poi
export PYTHONPATH="$CHECKBOX_SHARE:$PYTHONPATH"
fi

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

Qui puoi vedere che definisce alcune posizioni e una parte importante è il python3 finale
line, dove troverà e utilizzerà il file di configurazione .ini richiesto che abbiamo visto in precedenza.

Questa organizzazione gerarchica era molto potente ma era anche difficile da gestire e
aveva anche alcune limitazioni. Parte del lavoro che abbiamo svolto con checkbox è stato quello di integrare tutte le
plug-in specifici del progetto nel tronco della casella di controllo, in questo modo tutto il codice principale è in un unico posto,
e le varianti specifiche del progetto forniscono solo lavori, whitelist, dati e configurazione,
senza aggiungere nuovi comportamenti.

New pianura comportamento di controllo
A differenza della casella di controllo, il nucleo di plainbox è monolitico e non ha il concetto di plugin. Questo
rende più facile la comprensione e il lavoro. Il core plainbox ha implementazioni per tutti
le funzioni nei vecchi pacchetti di caselle di controllo, quindi non sono necessarie aggiunte per utilizzare le funzionalità
come la presentazione alla certificazione o la generazione di report.

Quello che chiamiamo plainbox è la libreria che implementa tutte le funzionalità, come si può vedere
qui.

Plainbox fornisce strumenti per aiutare gli sviluppatori di test a scrivere e creare pacchetti di test. Questi sono
consegnati in "provider", che sono entità progettate per incapsulare le descrizioni dei test,
script personalizzati per test, whitelist e dati assortiti. Sono stati progettati per consentire
team di scrivere e consegnare i loro test personalizzati senza preoccuparsi troppo del
codice plainbox sottostante.

Per ottenere informazioni su come scrivere test e provider, vedere il Tutorial sui provider

Tuttavia, quando si utilizzavano effettivamente questi test per verificare un sistema reale, volevamo fornire
qualcosa di più semplice e più vicino all'esperienza utente di checkbox. Abbiamo creato due clienti,
checkbox-gui e checkbox-cli, che avevano alcuni comportamenti hardcoded, e abbiamo anche iniziato
creando altri client basati su questi ma specifici per uno scopo. Ad esempio,
avevamo una versione della casella di controllo per i test SRU, un'altra per la certificazione del server e così via.

Ma poi ci siamo resi conto che molto del codice era duplicato e i comportamenti erano comuni
salvo poche modifiche. Quindi abbiamo ideato il concetto di "lanciatori", che sono
in qualche modo simile ai file di configurazione di checkbox e ai lanciatori di script della shell.

L'idea è che checkbox-gui e checkbox-cli abbiano alcuni comportamenti molto basilari, dal momento che
sono i client che vengono spediti di default con Ubuntu. Possono mostrare tutto il disponibile
whitelist, mostra un messaggio di benvenuto predefinito e alla fine consentirà all'utente di vedere il
html e invialo al launchpad usando il loro indirizzo e-mail, simile alla versione
della casella di controllo fornita con Ubuntu.

Invece di utilizzare complicate opzioni della riga di comando, i lanciatori ti consentono di configurare alcuni
comportamenti facoltativi per personalizzare la tua esperienza di test. Un launcher contiene le impostazioni e
è simile a uno script di shell, ma l'interprete sarà checkbox-gui o
lanciatore di caselle di controllo.

Ecco alcuni esempi di cosa si può fare con i lanciatori.

Sorprendentemente, checkbox-cli è di per sé un launcher:

#!/usr/bin/env checkbox-lanciatore
[benvenuto]
text = Benvenuto a System Testing!
Checkbox fornisce test per confermare che il sistema funziona correttamente.
Una volta terminata l'esecuzione dei test, è possibile visualizzare un rapporto di riepilogo per
il tuo sistema.
Avvertenza: alcuni test potrebbero causare il blocco o il blocco del sistema
non rispondente. Per favore salva tutto il tuo lavoro e chiudi tutte le altre in esecuzione
applicazioni prima di iniziare il processo di test.

[Continua]
whitelist_filter = ^predefinito$
whitelist_selection = ^predefinito$
skip_whitelist_selection = Vero

[trasporto]
invia_a = launchpad

Puoi vedere qui personalizziamo alcune opzioni: mostra un messaggio di benvenuto, automaticamente
seleziona la whitelist predefinita e la invierà al launchpad al termine.

Un esempio di launcher grafico è canonical-certification-client.

#!/usr/bin/checkbox-gui

[benvenuto]
title = "Certificazione di sistema"
testo = " Benvenuto nella certificazione del sistema! Questa applicazione sarà
raccogliere informazioni dal proprio sistema. Quindi ti verranno chiesti i test manuali per
confermare che il sistema funziona correttamente. Infine, ti verrà chiesto
il Secure ID del computer per inviare le informazioni alla certificazione
Banca dati. Per sapere come creare o individuare l'ID di sicurezza,
vedere qui: certificate.canonical.com "

[Continua]
whitelist_filter = "^client-(cert|autotest).*"

[sottomissione]
input_type = "regex"
input_placeholder = "ID sicuro (15 o 18 caratteri)"
ok_btn_text = "Invia risultati"
submit_to_hexr = "vero"

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

[trasporto]
submit_to = "certificazione"

I lanciatori grafici sono un po' più complicati, ma essenzialmente è simile, di cosa si tratta
permette di definire alcuni parametri per personalizzare la tua esperienza di test.

Un launcher in modalità testo molto semplice è canonical-hw-collection che esegue solo la base
le informazioni sull'hardware le verifica e le carica in un database hardware:

[benvenuto]
title = Raccolta di informazioni sull'hardware
text = Raccolta di informazioni sull'hardware. Potrebbe essere richiesta la password.
Questo processo richiederà circa 30 secondi e ti verrà fornito
con un URL attraverso il quale puoi confermare e registrare il tuo hardware
sottomissione.

[Continua]
whitelist_filter = ^hwsubmit$
selezione_whitelist = ^hwsubmit$
skip_whitelist_selection = Vero
skip_test_selection = Vero

[sottomissione]
# Un secure_id fasullo assicura che non lo chiediamo
# Può sempre essere sovrascritto nel file .conf.
secure_id = 000

[trasporto]
submit_to = certificazione
submit_url = https://server-hardware.example.com/

Infine, canonical-driver-test-suite fornisce sia un launcher in modalità grafica che testuale,
che sono funzionalmente equivalenti:

#!/usr/bin/checkbox-gui

[benvenuto]
title = "Suite canonica di test del conducente"
testo = " Benvenuto nella suite di test dei driver Canonical.

Questo programma contiene test automatici e manuali per aiutarti a scoprire
problemi che si presenteranno durante l'esecuzione dei driver del dispositivo su Ubuntu.

Questa applicazione guiderà l'utente attraverso questi test in a
ordine predeterminato e raccogliere automaticamente entrambe le informazioni di sistema come
così come i risultati dei test. Richiederà anche all'utente l'input quando è manuale
test è richiesto.

Il tempo di esecuzione dei test è determinato da quali test si decide di eseguire
eseguire. L'utente avrà l'opportunità di personalizzare l'esecuzione del test per
soddisfare il conducente e la quantità di tempo disponibile per il test.

Per iniziare, fai semplicemente clic sul pulsante Continua in basso e segui le istruzioni sullo schermo
Istruzioni. "

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

[sottomissione]
ok_btn_text = "Salva risultati"
input_type = "nessuno"

[esportatore]
xml_export_path = ""

[trasporto]
submit_to = "locale"

Modalità testo:

#!/usr/bin/env checkbox-lanciatore
[benvenuto]
text = Benvenuto nel Canonical Driver Test Suite
Questo programma contiene test automatici e manuali per aiutarti a scoprire
problemi che si presenteranno durante l'esecuzione dei driver del dispositivo su Ubuntu.
Questa applicazione guiderà l'utente attraverso questi test in a
ordine predeterminato e raccogliere automaticamente entrambe le informazioni di sistema come
così come i risultati dei test. Richiederà anche all'utente l'input quando è manuale
è richiesto il test.
Il tempo di esecuzione dei test è determinato da quali test si decide di eseguire
eseguire. L'utente avrà l'opportunità di personalizzare l'esecuzione del test per
soddisfare il conducente e la quantità di tempo disponibile per il test.
Per iniziare, fai semplicemente clic sul pulsante Continua in basso e segui le istruzioni sullo schermo
istruzioni.

[Continua]
# Whitelist visualizzate nella schermata di selezione della suite
whitelist_filter = ^ihv-.*
# Whitelist_selection è obbligatorio, quindi lo impostiamo su un valore fasullo così
# nessuna whitelist è preselezionata.
whitelist_selection = fasullo

CASELLA DI CONTROLLO STAMPA PROCESSO

Questa pagina descrive i passaggi necessari per rilasciare le versioni di Checkbox e Checkbox
Certificazione al PPA stabile appartenente al team di Certificazione Hardware, regolarmente
base. In questo documento il termine "Casella di controllo" viene utilizzato come termine generico per coprire
tutte le versioni di Checkbox di proprietà del team di certificazione hardware, attualmente Checkbox
stesso e le estensioni di certificazione della casella di controllo.

Panoramica
Attualmente il processo viene eseguito con cadenza bisettimanale, con una nuova versione di Checkbox ogni
due settimane. Questo copre dieci giorni lavorativi e le attività svolte in ogni giorno o gruppo di
giorni è descritto di seguito:

· Giorni 1-4: Tempo concesso per l'introduzione di nuove modifiche nel tronco.

· Giorno 5: le modifiche vengono unite dal tronco di lp:casella di controllo ed lp:checkbox-certificazione a
rispettivi rami di rilascio. I changelog per entrambi sono urtato a questo punto e
le revisioni sono contrassegnate. In questa fase potrebbe anche essere necessario copiare il pacchetto 'fwts'
dal FWTS Stabile PPA <https://launchpad.net/~firmware-testing-team/+archive/ppa-
fwts-stabile> al casella di controllo Rilasciare Testing PPA <https://launchpad.net/~checkbox-
sviluppo/+archivio/test>.

· Giorni 6-9: il test viene eseguito dal responsabile della versione per la certificazione hardware
team e un rappresentante del team CE QA (il cliente principale per Checkbox all'interno
Canonico)

· Giorno 9: si tiene un incontro di rilascio tra il manager di rilascio per l'hardware
Team di certificazione e rappresentante del team CE QA. Potenziali problemi con il
vengono identificati i rilasci e pianificati per affrontarli.

· Giorno 10: la versione testata di Checkbox viene copiata nel PPA stabile.

Launchpad Filiali
Il processo di rilascio richiede rami separati in Launchpad contenenti un semi-congelato
versione del codice che era nel trunk il giorno 5 del processo. Questo è così che lo sviluppo
può continuare sul tronco senza compromettere la stabilità della versione da rilasciare di
Casella di controllo. La relazione tra tutte le filiali coinvolte nel processo è la seguente:

· lp: checkbox/release <- lp:casella di controllo

· lp:checkbox-certificazione/rilascio <- lp:checkbox-certificazione

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

Revisione pietra miliare bug
Prima di creare la release candidate, il release manager dovrebbe rivedere l'elenco dei bug
pietra miliare per la prossima versione di Checkbox. Dovrebbero visitare casella di controllo pietre miliari
<https://launchpad.net/checkbox/+milestonesmilestones> e individuare la pietra miliare datata con
la data di rilascio.

· Per i bug che sono impostati su In corso con un ramo associato - collaborare con il ramo
proprietario per vedere se la fusione può essere completata prima della scadenza.

· Per bug che si trovano in qualsiasi altro stato non chiuso (tranne Fissare Impegnato) - ri-traguardo
loro alla tappa successiva.

Cutting , il rilasciare
Per tagliare il rilascio, dobbiamo unire le modifiche dal tronco al rilascio
branch, inviali con un messaggio adatto e aggiorna il log delle modifiche in trunk in modo che
le modifiche future vanno sotto la versione corretta. Per ogni combinazione di rami mostrata sopra,
fai quanto segue (l'esempio usa lp:casella di controllo ed lp: checkbox/release):

bzr ramo lp:casella di controllo/rilascio casella di controllo-rilascio
bzr branch lp: checkbox checkbox-trunk
cd checkbox-rilascio
current_stable=`head -n1 $(find . -name 'changelog') | grep -oP '(?<=\().*(?=\))'`
bzr unisci lp: checkbox

a questo punto se non cambia (diverso da uno a debian/log delle modifiche) ci uniamo e poi lo facciamo
non eseguire un rilascio del pacchetto in questione. In pratica questo accade spesso con
checkbox-certificazione ma mai con casella di controllo:

bzr commit -m "Unito nelle modifiche da rev$(bzr revno -r tag:$current_stable lp:checkbox) a rev$(bzr revno lp:checkbox) da lp:checkbox"
bzr push lp: checkbox/release
cd `trova. -nome 'debian'`; cd ..
bzr tag `head -n1 debian/changelog | grep -oP '(?<=\().*(?=\))'`
dch -r (salva il log delle modifiche modificato)
dch -i -U 'Registro modifiche incrementato'
debito
bzr push lp: checkbox

L'ultimo passaggio del processo consiste nell'eseguire una build dei pacchetti nel
ppa: checkbox-dev/testing PPA. Per fare questo dobbiamo andare alle pagine delle ricette per il
casella di controllo e / o checkbox-certificazione rilasciare rami.

· checkbox-test ricetta <https://code.launchpad.net/~checkbox-dev/+recipe/checkbox-
analisi>

· checkbox-certificazione-test ricetta <https://code.launchpad.net/~checkbox-
dev/+ricetta/checkbox-certificazione-test>

I Costruire Adesso l'opzione dovrebbe essere disponibile nella pagina. Fare clic per avviare una build.

Copiatura Firmware Test Suite a , il Testing PPA
Lo strumento Firmware Test Suite è uno strumento di test per il firmware di sistema che è naturalmente pesante
utilizzato da Checkbox. Per assicurarti che l'ultima versione che contenga correzioni e novità
i test/caratteristiche necessarie per Checkbox sono disponibili e non interrompono nulla
Checkbox, dobbiamo rilasciarlo insieme a Checkbox. Dopo aver tagliato il rilascio se il
Il team di test del firmware ha notificato che è disponibile una nuova versione e che questa versione
dovrebbe essere utilizzato per la certificazione, dobbiamo copiarlo nel Testing PPA. Per fare questo noi
devo andare al Copia Packages vista of , il Firmware Test Suite (Stabile) PPA
<https://launchpad.net/~firmware-testing-team/+archive/ppa-fwts-stable/+copy-packages> e
seleziona i pacchetti 'fwts' per tutte le versioni torna a Precise. Dobbiamo impostare il
'Destination PPA' come 'Checkbox Release Testing [~checkbox-dev/testing]' e 'Copia
opzioni' su 'Copia binari esistenti', quindi fare clic su 'Copia pacchetti'. Questo passaggio allora
deve essere ripetuto ma impostare il campo 'Destination PPA' su 'PPA for Checkbox Developers
[~checkbox-dev/ppa]'.

Avanti Rilasciare of casella di controllo e-mail
In modo che tutti abbiano l'opportunità di eseguire qualsiasi test richiesto in tempo utile
modo, dopo che le build PPA sono state completate, un'e-mail deve essere inviata al seguente
mailing list:

· [email protected] <certificazione-hardware-
[email protected]>

· [email protected] <[email protected]>

Il contenuto è in genere qualcosa del genere:

Oggetto: Prossima versione di Checkbox (18/11/2013)

Ciao,

La prossima versione di Checkbox è disponibile in
https://code.launchpad.net/~checkbox-dev/+archive/testing PPA.
Per favore provalo a tuo piacimento. La casella di controllo si basa sulla revisione 2484 di
lp:checkbox e Checkbox La certificazione si basa sulla revisione 586 di
lp:checkbox-certificazione.

Grazie,

Se l'uno o l'altro di Checkbox e Checkbox Certification non sono stati aggiornati, allora
non c'è bisogno di menzionare quel pacchetto

Testing , il rilasciare
Ora che la versione è stata tagliata, i test dovrebbero aver luogo prima della riunione di rilascio.
Dal punto di vista del team di certificazione, ciò che deve essere testato è
checkbox-certificazione-cliente ed checkbox-certificazione-server che costituiscono la base per
CE QA Versioni specifiche OEM di Checkbox. Il server di certificazione Checkbox è testato nel
Il client di certificazione CI loop Checkbox deve essere testato manualmente.

Rilasciare riunione
Il giovedì prima del rilascio si tiene un incontro tra un rappresentante di
il team di certificazione e un rappresentante del Locali commerciali Ingegneria QA squadra. Il
la riunione si tiene alle 7:30 UTC come mostrato in questo gestione del progetto invitare
<https://www.google.com/calendar/hosted/canonical.com/event?action=TEMPLATE&tmeid=Y3QxcWVla3ViMTRvMXByOHZlOTFvc283Y2NfMjAxMzA4MjlUMDczMDAwWiBicmVuZGFuLmRvbmVnYW5AY2Fub25pY2FsLmNvbQ&tmsrc=brendan.donegan%40canonical.com>.
L'ordine del giorno della riunione è incluso nell'invito.

editoriale , il rilasciare
Per pubblicare il rilascio abbiamo semplicemente bisogno di copiare un numero di pacchetti dal casella di controllo
Rilasciare Testing PPA <https://launchpad.net/~checkbox-dev/+archive/testing> al Hardware
Certificazione Pubblico PPA <https://launchpad.net/~hardware-certification/+archive/public>.
Per farlo andiamo su Copia Packages vista of , il casella di controllo Rilasciare Testing PPA
<https://launchpad.net/~checkbox-dev/+archive/testing/+copy-packages> e seleziona tutto
versioni del seguente elenco di pacchetti: casella di controllo, checkbox-certificazione, fwt. Rendere
assicurati che il campo "PPA di destinazione" sia impostato su "PPA pubblico per la certificazione hardware
[~hardware-certification/public]' e che il campo 'Opzioni di copia' sia impostato su 'Copia
binari esistenti", quindi fare clic su "Copia pacchetti".

Fatto ciò, dovrebbe essere inviata un'e-mail di annuncio a
[email protected] <[email protected]>.
Un modello per l'annuncio è incluso di seguito:

Ciao,

Una nuova versione della casella di controllo è stata caricata nell'Hardware
Certificazione PPA pubblica
(https://launchpad.net/~certificazione-hardware/+archive/public). Il
il rilascio è basato sulla revisione 2294 di lp: checkbox

Grazie,

Si prega di allegare la parte più recente del registro delle modifiche come note di rilascio

· genindice

· modiindice

· ricerca

Usa checkbox-cli online usando i servizi onworks.net