Using this piece of YAML:
```
deploy:
bash:
command: 'bundle exec cap production deploy'
```
Will run Capistrano and deploy your app to production.
You can use any other deployment tool instead of Capistrano.
Basically this is caused by sqlite actually doesn't have any
column type restriction. also save gob type column as blob to enforce
byte-string value, since varchar with utf8 collation type will take at
least 3 byte to store, this will break YAML-Gob decoding at `params`
column.
Also fix some typo, and clean up fixtures code.
This allows the same SHA to have different builds on different branches, each
separately viewable. This is useful for expressing a "pipeline" in terms of
branches, e.g. a commit starts on branch A and progress through B and C to
master, with the build script switching on branch name.
Previously viewing each build would arbitrarily choose which branch's commit
to show.
Requirements:
MySQL/MariaDB need to be configured with this settings:
innodb_file_format = Barracuda
innodb_file_per_table = On
innodb_large_prefix = On
to support key prefix length up to 3042 bytes.
MySQL/MariaDB DSN will need this parameter:
parseTime=true
as per [1]
The migration system itself mostly inspired by Rails (ActiveRecord),
but it still rough at the edges. Could use some inputs.
Next Todo: more testing!
[1] https://github.com/go-sql-driver/mysql#parsetime
Also suppress error at the latest migration script
for backward compatibility with existing database, in which
open_invitations column wasn't added via migration.
This includes refactoring database setup, and migration system.
Remove setupDatabase from main and use `Init` method from database
package.
At database package, defines Init method which actually initiate
database with options given from comand line flag. I think `--path`
wont be used anywhere so I plan to remove it later.
Both meddler and migration initiated here, then we call `Set` method
to setup all the tables, etc. Here I think I want to separate database
schema and turn it into migration script instead, later maybe.
At migration package I made some tweak to `Operation` interface.
Realized that it's ludicrous to let migration driver re-implement `Exec`
and `Query`, I made migration script to receive The whole
migrationDriver struct which contains both Operation implementor, and
the Tx itself. This made possible thanks to Go struct being able to
promote its member, now our migration is more transparent.
There's also stub implementation for bot mysql and postgresql, will
implement this really soon.
