Lo schema del database di Buildbot

Stai visualizzando una vecchia versione di questo article. Visualizza la versione più recente.

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.

The test_failure table

This table has one row for every test failure encountered:

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: This identifies the test run in which the test failure occured (eg. it is a foreign key to id in table test_run).
  • test_name: The name of the test that failed, eg. main.information_schema.
  • test_variant: Some tests are run multiple times in different variants. Ie. many replication tests are run under both statement-based, mixed-mode, and row-based replication. The variant will be 'stmt', 'mix', or 'row' accordingly. For tests that do not have multiple variants, the value will be the empty string (ie. not a NULL value).
  • info_text: This is a short description that mysql-test-run.pl sometimes gives for some kinds of test failures (for example "timeout").
  • failure_text: This is the entire output from mysql-test-run.pl concerning this test failure. It usually contains the diff against the result file, a stacktrace for a crash, etc. This is useful to run LIKE queries against when searching for test failures similar to one being investigated.

The test_warnings table

This table holds information about test problems that were detected after a test case ran, during server restart (typically by finding an error or warning message in the server error log files). A typical example of this is a memory leak or a crash during server shutdown.

Such a failure can not be attributed to a specific test case, as it could be caused by any of the tests run against the server since last restart, or could even be a general problem not caused by any test case. Instead, for each occurence, this table provides a list of names of the tests that were run by the server prior to detecting the error or 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: Identifies the corresponding row in table <code>test_run</code>.
  • list_id: This is a counter for occurences of warnings within each test run (ie. it starts over from 0 again for each different value of <code>test_run_id</code>).
  • list_idx: This is a counter for each test name (ie. it starts over from 0 again for each different value of <code>test_run_id</code> ''and'' <code>list_id</code>).
  • test_name: The name of the test run by the server prior to seeing the warning.

Sample queries

Show all platforms that failed for a particular revision of a particular 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));

Find failures similar to a given failure being investigated:

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%";

Check which branches a specific kind of failure has occured in:

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;

Find all test runs where a given test was run against a server that later had warnings in the error log, and also count the number of occurences of this event in each run:

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;

Commenti

Sto caricando i commenti......
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.