Lo schema del database di Buildbot

Questa pagina illustra lo schema del database usato da Buildbot per salvare i risultati dei test.

L'idea è quella di poter usare questi dati fuori da Buildbot, ad esempio per creare delle pagine web aggiuntive che presentano i risultati dei test, o utility di ricerca/data mining che riguardano i test falliti.

Accesso al database

Il piano è permettere connessioni remote al database che siano usabili dai membri della comunità. Per questo, occorre approntare un host slave che replica il database del master Buildbot (il che sarebbe comunque utile per isolare il Buildbot in esecuzione da un possibile carico elevato di query).

Tuttavia, per ora l'accesso al database è disponibile solo in locale dalla macchina (hasky) che esegue il master di Buildbot.

Lo schema

Le informazioni più attuali riguardo al database usato sono disponibili nel file buildbot/process/mtrlogobserver.py nei sorgenti di Buildbot. Con l'evolvere del codice ulteriori informazioni verranno registrate nel database, ed esso potrebbe essere esteso, ma la descrizione presente nei sorgenti dovrebbe essere sempre aggiornata.

La tabella test_run

Questa tabella ha una riga per ogni esecuzione dei test. Pertanto, ogni record corrisponde a una cella nel [http://askmonty.org/buildbot/waterfall Grafico a cascata]. Il formato della tabella è il seguente:

CREATE TABLE test_run(
    id INT PRIMARY KEY AUTO_INCREMENT,
    branch VARCHAR(100),
    revision VARCHAR(32) NOT NULL,
    platform VARCHAR(100) NOT NULL,
    dt TIMESTAMP NOT NULL,
    bbnum INT NOT NULL,
    typ VARCHAR(32) NOT NULL,
    info VARCHAR(255),
    KEY (branch, revision),
    KEY (dt),
    KEY (platform, bbnum)
) ENGINE=innodb

• id: Chiave primaria, un semplice id auto_increment.
• branch: Il nome della branch bzr relativa ai test.
• revision: Il numero di versione indicato da Bzr del software testato.
• platform: Il nome del builder che ha eseguito i test.
• dt: Data in cui l'esecuzione di buildbot è iniziata.
• bbnum: Il '''build number''' di Buildbot, che insieme a platform identifica in modo univoco una build di Buildbot.
• typ: Abbreviazione concisa che descrive il tipo di test. Ad esempio pr per --ps-protocol con la replica basata sulle righe, o nm per un test normale con replica mista.
• info: Breve descrizione testuale del tipo di test.

La tabella test_failure

Questa tabella ha una riga per ogni fallimento dei test:

CREATE TABLE test_failure(
    test_run_id INT NOT NULL,
    test_name VARCHAR(100) NOT NULL,
    test_variant VARCHAR(16) NOT NULL,
    info_text VARCHAR(255),
    failure_text TEXT,
    PRIMARY KEY (test_run_id, test_name, test_variant)
) ENGINE=innodb

• test_run_id: Identifica l'esecuzione del test nel quale è avvenuto un fallimento (è una chiave esterna verso id nella tabella test_run).
• test_name: Il nome del test fallito, ad esempio main.information_schema.
• test_variant: Alcuni test vengono eseguiti più volte in diverse varianti. Per esempio molti test della replica vengono eseguiti in modalità statement-based, mixed-mode e row-based. Le varianti saranno rispettivamente 'stmt', 'mix', o 'row'. Per i test che non hanno varianti, il valore è una stringa vuota (non un valore NULL).
• info_text: Una breve descrizione che talvolta viene fornita da mysql-test-run.pl per alcuni tipi di fallimenti dei test (per esempio "timeout").
• failure_text: Questo è l'output completo di mysql-test-run.pl riguardo al fallimento. Solitamente contiene il diff con il file dei risultati, una stacktrace per i crash, etc. E' utile eseguire query LIKE su questo campo quando si cercano fallimenti simili a uno su cui si ha già investigato.

La tabella test_warnings

Questa tabella contiene informazioni sui problemi dei test che sono stati rilevati dopo l'esecuzione di un test case, durante un riavvio del server (di solito trovando un messaggio di errore o di warning nei log del server).Un esempio tipico è un memory leak o un crash durante l'arresto del server.

Un fallimento di questo tipo non può essere attribuito a uno specifico test case, perché potrebbe essere stato causato da uno qualsiasi dei test eseguiti sul server dall'ultimo riavvio, o potrebbe perfino essere un problema generico non relativo a un test case. Ogni volta che avviene, questa tabella fornisce una lista dei nomi dei test che sono stati eseguiti dal server prima di rilevare l'errore o il warning.

CREATE TABLE test_warnings(
    test_run_id INT NOT NULL,
    list_id INT NOT NULL,
    list_idx INT NOT NULL,
    test_name VARCHAR(100) NOT NULL,
    PRIMARY KEY (test_run_id, list_id, list_idx)
) ENGINE=innodb

• test_run_id: Identifica la riga corrispondente nella tabella <code>test_run</code>.
• list_id: Un contatore dei warning avvenuti durante ogni test (ossia, ricomincia da 0 per ogni diverso valore di <code>test_run_id</code>).
• list_idx: Un contatore di ogni nome di test (ossia, ricomincia da 0 per ogni diverso valore di <code>test_run_id</code> ''e'' <code>list_id</code>).
• test_name: Il nome del test eseguito dal server prima di vedere il warning.

Query di esempio

Mostra tutte le piattaforme su cui è fallita una certa revisione di una certa branch:

select platform
  from test_run r
where branch = 'mysql-6.0-testing2'
  and revision = '2819'
  and (exists (select * from test_failure f where f.test_run_id = r.id)
    or exists (select * from test_warnings w where w.test_run_id = r.id));

Trova i fallimenti simili a un particolare fallimento che è già stato studiato:

select branch, revision, platform, test_name, test_variant, failure_text
  from  test_failure f
  inner join test_run r on (f.test_run_id = r.id)
  where failure_text LIKE "%--protocol=TCP' failed%";

Controlla in quali branch è avvenuto uno specifico tipo di fallimento:

select branch, count(*)
  from test_failure f
  inner join test_run r on (f.test_run_id = r.id)
  where failure_text LIKE "%--protocol=TCP' failed%"
  group by branch;

Trova tutte le esecuzioni in cui un dato test è stato eseguito su un server che più tardi ha avuto dei warning nel log degli errori, e conta il numero di occorrenze di questo evento per ogni esecuzione:

select branch, revision, platform, count(*)
  from test_warnings w
  inner join test_run r on (w.test_run_id = r.id)
  where test_name = 'rpl.rpl_plugin_load'
  group by r.id;