diff options
| author | Dylan Griffith <dyl.griffith@gmail.com> | 2018-10-03 12:58:45 +0300 |
|---|---|---|
| committer | Dylan Griffith <dyl.griffith@gmail.com> | 2018-10-03 12:58:45 +0300 |
| commit | 597be76c1ccf31576c1c5ddd4f9d399184d0a6c1 (patch) | |
| tree | 9ccd8d9e7c1aa6487175ddcb4ab9986845f08811 | |
| parent | 23ba3b02b1988205043253aee9ba91ed802f01c5 (diff) | |
| download | gitlab-ce-597be76c1ccf31576c1c5ddd4f9d399184d0a6c1.tar.gz | |
Doc improvements for DB migrations in Auto DevOps
| -rw-r--r-- | doc/topics/autodevops/index.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index f67d35dac9e..f4f37241659 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -442,8 +442,8 @@ executed somewhere else, it cannot be accessed again. > [Introduced][ce-21955] in GitLab 11.4 -Database initialization and migrations can be configured to run within -the application pod by setting the project variables `DB_INITIALIZE` and +Database initialization and migrations for PostgreSQL can be configured to run +within the application pod by setting the project variables `DB_INITIALIZE` and `DB_MIGRATE` respectively. If present, `DB_INITIALIZE` will be run as a shell command within an application pod as a helm @@ -453,7 +453,7 @@ post-install hook. Note that this means that if any deploy succeeds, If present, `DB_MIGRATE` will be run as a shell command within an application pod as a helm pre-upgrade hook. -For example, in a rails application : +For example, in a Rails application: * `DB_INITIALIZE` can be set to `cd /app && RAILS_ENV=production bin/setup` @@ -605,8 +605,8 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac | `BUILDPACK_URL` | The buildpack's full URL. It can point to either Git repositories or a tarball URL. For Git repositories, it is possible to point to a specific `ref`, for example `https://github.com/heroku/heroku-buildpack-ruby.git#v142` | | `SAST_CONFIDENCE_LEVEL` | The minimum confidence level of security issues you want to be reported; `1` for Low, `2` for Medium, `3` for High; defaults to `3`.| | `DEP_SCAN_DISABLE_REMOTE_CHECKS` | Whether remote Dependency Scanning checks are disabled; defaults to `"false"`. Set to `"true"` to disable checks that send data to GitLab central servers. [Read more about remote checks](https://gitlab.com/gitlab-org/security-products/dependency-scanning#remote-checks).| -| `DB_INITIALIZE` | From GitLab 11.4, this variable can be used to specify the command to run to initialize the application's database. Run inside the application pod. | -| `DB_MIGRATE` | From GitLab 11.4, this variable can be used to specify the command to run to migrate the application's database. Run inside the application pod. | +| `DB_INITIALIZE` | From GitLab 11.4, this variable can be used to specify the command to run to initialize the application's database. It runs inside the application pod. | +| `DB_MIGRATE` | From GitLab 11.4, this variable can be used to specify the command to run to migrate the application's database. It runs inside the application pod. | | `STAGING_ENABLED` | From GitLab 10.8, this variable can be used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). | | `CANARY_ENABLED` | From GitLab 11.0, this variable can be used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments). | | `INCREMENTAL_ROLLOUT_ENABLED`| From GitLab 10.8, this variable can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. | |