Skeema.io CI is a continuous integration system for MySQL and MariaDB, supporting a pull request workflow for schema changes. Once you enable our GitHub application on a schema repo, every
git push will be checked for common problems automatically. Pull requests will receive automated comments with DDL diff generation.
For more examples, check out an interactive demo with just a few clicks!
The Skeema.io CI system does not access your actual database servers. All behavior operates on your schema repo alone. The application just needs read-only access to your schema repo’s code, and a few other permissions in order to comment on pull requests or update commit statuses.
After each commit, your repo’s
*.sql files are scanned for
CREATE PROCEDURE, and
CREATE FUNCTION statements, searching for several types of problems.
Two types of problems are always detected (regardless of configuration), and are flagged as fatal errors if found:
- SQL syntax errors
- Statements that generate an error when run, despite being syntactically valid
Several other problems can be configured to generate errors or warnings, or be ignored entirely:
bad-charset: Flag tables using character sets not specified in allow-charset
bad-engine: Flag tables using storage engines not specified in allow-engine
no-pk: Flag tables that do not have an explicit PRIMARY KEY
Additional problems, such as ability to detect redundant indexes, will be added in the near future.
Skeema.io CI is configured in the same way as the
skeema command-line tool. In brief:
Each directory may optionally have a
.skeemaconfiguration file, formatted using an ini-like syntax similar to MySQL’s own configuration format.
Values set in a directory apply to that directory, and also cascade down to subdirectories. Subdirectories can override individual key/value pairs if desired.
Skeema.io will use values configured for the
productionenvironment. This means any configuration at the top of the .skeema file (before any
[section]) will apply, as will anything in the
The following options are particularly relevant for the CI system:
Controls what database vendor and version to use, for example “mysql:5.6” or “mariadb:10.3”. If not specified, the default for the CI system is currently “mysql:5.7”. Full docs.
Specifies which named linter problems are treated as fatal errors. Use a comma-separated list to specify multiple values. Full docs.
Specifies which named linter problems are treated as non-fatal warnings. Use a comma-separated list to specify multiple values. Full docs.
Comma-separated list specifying which character sets to permit. Any unlisted character set will trigger the
bad-charset problem. Full docs.
Comma-separated list specifying which storage engines to permit. Any unlisted storage engine will trigger the
bad-engine problem. Full docs.
Default character set to use for tables that don’t specify one explicitly. Full docs.
Default collation to use for tables that don’t specify one explicitly. Full docs.
Any table with a name matching this regex will be ignored entirely. Full docs.
How much does the service cost?
The service is completely free during the beta period. Paid tiers may be introduced in the future, but payment information is not requested or collected at this time.
Why am I getting so many warnings about unparseable statements?
The CI system is currently designed to operate on a file layout created with
skeema init. Support for arbitrary SQL (e.g.
mysqldump output) is only semi-functional right now, but will be improved in the future.
How do I see CI output on individual commits?
The CI system only leaves comments on pull requests. To see CI status for a commit that isn’t part of a pull request, go to the Commits tab of any branch in GitHub, and click on the green checkmark or red X next to any commit.
Will a copy of my schema repo be stored on your servers?
We do not retain or persist any repositories, nor any derived artifacts from them, beyond the brief time required to perform lint and diff operations – typically well under 60 seconds per
Is there an enterprise / on-prem version?
Not yet, but is expected to be under development in the future. Please reach out if your company is interested.
Will other platforms such as Bitbucket or GitLab be supported?
Possibly, depending on user demand and API complexity. Please reach out to express interest.
Any companion solutions for continuous deployment?
A continuous deployment system is under development, with a beta launch expected later in 2019. This will be an optional add-on which enables a completely automated schema change workflow: just merge a pull request, and if the change is determined to be safe and non-destructive, the system will kick off a schema change.
Support and Feedback
For feedback, bug reports, or other inquiries, please use our contact form.