The migrations migrate-2021-06-29 and migrate-2021-06-30 would not apply
if a job exists without any successful build. Now the migrations script
silently skips jobs without succesful builds.
Each migration is, for the most part, a module that exposes expected
database version numbers, command identifier and documentation. This
results in all information about the migration and rollback are
found in the module itself, and builder_migrations.ml only has to
reference the module.
Some migrations require foreign keys constraints are disabled. It is not
possible to enable or disable foreign key constraints inside a
transaction.
Parts of the database representation are exposed.
A fixup command for builder-migrations is added to remove bad database
entries fixed in a57798f4c0. It is up to
the operator to remove the files and optionally re-upload the 'full'
files to builder-web.
Sqlite3 application_id and user_version are now set to identify the
database is a builder-web database, and the user_version represents the
schema version.
The 'build' table is extended with a 'main_binary' column. This
represents the main binary artifact from the build. This is decided by
there being exactly one file in bin/.
A migration tool is written that does both migrations and rollbacks, and
migration and rollback is implemented for the above mentioned change.
