Continuous Integration Beta

Overview 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.

CI annotation example CI PR comment example

For more examples, check out an interactive demo with just a few clicks!


Simply add the application to your schema repo on GitHub. (Don’t have a schema repo yet? Download the open source Skeema CLI tool, and see examples for skeema init to get started in minutes!)

The 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.

Problem Detection

After each commit, your repo’s *.sql files are scanned for CREATE TABLE, 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.

Configuration CI is configured in the same way as the skeema command-line tool. In brief:

  • Each directory may optionally have a .skeema configuration 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.

  • will use values configured for the production environment. This means any configuration at the top of the .skeema file (before any [section]) will apply, as will anything in the [production] section.

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 git push.

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.

Please review our terms of service and privacy policy.

Support and Feedback

For feedback, bug reports, or other inquiries, please use our contact form.