Mayra Cabrera authored 5 years ago and Evan Read committed 5 years ago

Currently, the DB migrations guide says that "you must" use non-blocking
operations (such as CREATE INDEX CONCURRENTLY), always.

But this does not make sense in cases of empty tables and leads to
splitting the work to multiple non-atomic
(with disable_ddl_transaction!) DB migrations.

To follow KISS principle, to have fewer DB migrations steps,
to have them atomic when it's possible and simplify deployment
and troubleshooting, the following exceptions were added
to the doc:

- index creation,
- index dropping,
- defining an FK,
- adding a column with DEFAULT,

Marcel Amirault authored 5 years ago and Evan Read committed 5 years ago

Updating redirected links in the development, install, policy
raketasks and university dirs. Should now link to final
URL to avoid redirect hops

Update migration_style_guide.md

Add to docs paragraph about a way of moving EE migrations to CE
if needed

Evan Read authored 6 years ago and Achilleas Pipinellis committed 6 years ago

For the sake of consistency, removes any extraneous
consecutive blank lines from the doc suite.

- Also makes other minor Markdown fixes that were near the main fixes.

These are data columns that store runtime configuration
of build needed to execute it on runner and within pipeline.

The definition of this data is that once used, and when no longer
needed (due to retry capability) they can be freely removed.

They use `jsonb` on PostgreSQL, and `text` on MySQL (due to lacking
support for json datatype on old enough version).

Extending from ActiveRecord::Migration is deprecated, but was still used
in a bunch of places.

Closes #49789.

Index creation does not have an effect if the index is present already.
Index removal does not have an affect if the index is not present.

This helps to avoid patterns like this in migrations:
```
if index_exists?(...)
  remove_concurrent_index(...)
end
```

At some point we decided this isn't really necessary, so let's get rid
of it.

Starting with GitLab 9.1.0 we will no longer allow downtime migrations
unless absolutely necessary. This commit updates the various developer
guides and adds code that is necessary to make zero downtime migrations
less painful.

[ci skip]

[ci skip]

These new checks can be used to check if migrations require downtime or
not (as tagged by their authors). In CI this compares the current branch
with master so migrations added by merge requests are automatically
verified.

To check the migrations added since a Git reference simply run:

    bundle exec rake gitlab:db:downtime_check[GIT_REF]