delta/gitlab/gitlab-ce.git/rubocop/cop/migration, branch docs/api-single-codebase

Properly handle `ee` migration specs

2019-03-27T21:48:53+00:00

Make add_reference cop accept a hash for :index

2018-11-27T10:40:38+00:00

It might happen you want to make the reference column have a unique
value, or you want to create partial indexes. So instead of only
accepting a `true` value, also accept a hash of options.

Add rubocop check for add_reference to require index.

2018-08-08T21:30:48+00:00

Add more large tables to cop

2018-06-22T11:08:39+00:00

These are all over 20 GB on GitLab.com. merge_request_diff_commits is several
hundred gigabytes in size.

Disallow methods that copy data on large tables

2018-06-19T16:18:15+00:00

{change_column_type,rename_column}_concurrently both copy data from one column
to another during a migration, which should not be done on GitLab.com. Instead,
we should use background migrations.

Resolve "Make a Rubocop that forbids returning from a block"

2018-04-18T09:19:40+00:00

Enable RuboCop Style/RegexpLiteral

2018-01-31T17:06:07+00:00

Use gitlab-styles

2017-12-22T14:34:44+00:00

Signed-off-by: Rémy Coutable

Add cop for use of remove_column

2017-12-11T16:34:51+00:00

remove_column should only be used in the up (or change) step of a migration if
it's a post-deployment migration. Otherwise there will be downtime due to the
ActiveRecord column cache, which we can avoid by using the IgnorableColumn
concern in combination with a post-deployment migration.

Prevent update_column_in_batches on large tables

2017-11-17T16:56:50+00:00

add_column_with_default is implemented in terms of update_column_in_batches, but
update_column_in_batches can be used independently. Neither of these should be
used on the specified large tables, because they will cause issues on large
instances like GitLab.com.

This also ignores the cop for all existing migrations, renaming
AddColumnWithDefaultToLargeTable where appropriate.