Upgrading
Bitten's database schema is versioned using the bitten_version entry in Trac's system table. If you install a version of Bitten with a more recent schema you will need to run trac-admin update after installing Bitten to update your database. Until this done Trac will not activate your new Bitten installation.
Note
You should back up your Trac database and Trac environment before running trac-admin upgrade.
Note
If you are using a SQLite database file, Trac automatically creates a copy before proceeding with the update. This should not be relied upon but can be useful if you have ignored the advice above.
Bitten's upgrade scripts attempt to commit changes made to the database each time a new schema version is reached. This ensures that if an upgrade fails to complete the Bitten database is left in the most up-to-date state possible.
For example, if you were upgrading from Bitten schema 6 to schema version 12 and duplicate builds were found during the attempt to upgrade to schema 10, your database would be left at schema 9.
1 Removing Duplicate Builds
Bitten schema version 10 adds a unique index on the columns (config, platform, rev) to the bitten_build table. This constraint is relied on by Bitten but was not enforced in earlier versions and duplicate builds could arise. Before the upgrade to schema version 10 can complete, these duplicate builds must be removed. The trac-admin upgrade will produce a list of duplicates but the decision on which to keep remains with the user.
A script for removing builds is provided. This scripts supports schema versions 9 through 12.
2 Reporting Upgrade Issues
Debugging upgrade issues can be difficult since the Bitten development team does not have access to your database. Attaching a description of your database schema before and after running trac-admin upgrade to your request for assistance may help others diagnose the problem more swiftly.
You can create such a schema description using Gerald or a similar tool.
3 Upgrade history
The current version of the Bitten schema is version 12.
3.1 Version 12
- last activity column added to bitten_build.
3.2 Version 11
- Badly named log level files that ended with .log.level created by earlier versions of Bitten were renamed to end in .log.levels which is the correct extension.
- Log level files that had not been correctly deleted by earlier versions of Bitten were cleaned up.
3.3 Version 10
- PostgreSQL sequences on the id column that had not been correctly updated by previous Bitten upgrade scripts were corrected. This affected four tables: bitten_build, bitten_log, bitten_platform and bitten_report.
- A unique index on the columns (config, platform, rev) was added to the bitten_build table and an old unique index on (config, rev, slave) was removed.
Note
The lack of an index on (config, platform, rev) in ealier versions of Bitten allowed duplicate builds to be created in the database under some conditions. These duplicate builds need to be manually removed before the upgrade to version 10 can complete.
3.4 Version 9
- The id column of the bitten_rule table was converted from a text column to an integer one.
3.5 Version 8
- Log messages that had been stored in the bitten_log_messages table were migrated to files.
- A filename field was added to the bitten_log table to record the location of the new log files.
3.6 Version 7
- The bitten_error table as added to record the reasons for step failures.
3.7 Version 6
- Filenames stored in the value column of bitten_report_item where normalized to use / as the path separator.
- The generator columns in bitten_log and bitten_report previously stored just the short tag name of the associated generator. These were updated to store the full tag name of the generator (including the XML namespace). For example, pipe was changed to http://bitten.edgewall.org/tools/sh#pipe.
3.8 Version 5
- An orderno column was added to the bitten_log table to record the order in which sets of log messages were generated.
- The bitten_report and bitten_report_item tables were added to record reports generated by unit tests and other build tools.
- Report data was imported from the old Berkeley DB XML store into the new database tables.
3.9 Version 4
- The build configuration that generated a report was added to the report metadata in the Berkeley DB XML store.
3.10 Version 3
- The recipe column was added to bitten_config to store the recipe XML.
3.11 Version 2
- The bitten_log and bitten_log_message tables were created for storing log messages.
- The log column was removed from bitten_step and the log messages where migrated to the two new logging tables.
3.12 Version 1
- The first Bitten database schema.
See also: Documentation
