From eebe8541e60e3ada52ad9b8e09c3f6d7fba6cbee Mon Sep 17 00:00:00 2001 From: Mayra Cabrera Date: Tue, 1 May 2018 15:55:24 -0500 Subject: [PATCH 1/2] Include documentation about STAGING_ENABLED variable for AutoDevops Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/38549 --- doc/topics/autodevops/index.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 1fe995386812c4..a2e2de42a15432 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -498,6 +498,7 @@ 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).| +| `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). | TIP: **Tip:** Set up the replica variables using a @@ -564,6 +565,19 @@ service: internalPort: 5000 ``` +#### Deploy policy for staging and production environments + +> [Introduced][ci-yml-160] in GitLab 10.8. + +The normal behavior of Auto DevOps is to use Continuous Deployment, pushing automatically to `production` every time +a new pipeline is run on `master`. But there are cases where people want to use a staging environment and deploy to +production manually, for this scenario we introduce the `$STAGING_ENABLED` environment variable. + +If `$STAGING_ENABLED` is defined in your project then the application will be automatically deployed to a `staging` +environment, and a `production_manual` job will be enabled for you when you're ready to manually deploy to production. +Otherwise if `$STAGING_ENABLED` is not defined, then the application will be automatically deployed to the `production` +environment. + ## Currently supported languages NOTE: **Note:** @@ -653,3 +667,4 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/ [Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml [GitLab Omnibus Helm Chart]: ../../install/kubernetes/gitlab_omnibus.md [ee]: https://about.gitlab.com/products/ +[ci-yml-160]: https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/160 -- GitLab From 6c52bd9dae87309846707d9f1beda9532a22b0d7 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 2 May 2018 16:18:47 +0200 Subject: [PATCH 2/2] Copyedit Auto DevOps deploy policy --- doc/topics/autodevops/index.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index a2e2de42a15432..143e55a3684e8e 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -567,16 +567,19 @@ service: #### Deploy policy for staging and production environments -> [Introduced][ci-yml-160] in GitLab 10.8. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/160) +in GitLab 10.8. -The normal behavior of Auto DevOps is to use Continuous Deployment, pushing automatically to `production` every time -a new pipeline is run on `master`. But there are cases where people want to use a staging environment and deploy to -production manually, for this scenario we introduce the `$STAGING_ENABLED` environment variable. +The normal behavior of Auto DevOps is to use Continuous Deployment, pushing +automatically to the `production` environment every time a new pipeline is run +on the default branch. However, there are cases where you might want to use a +staging environment and deploy to production manually. For this scenario, the +`STAGING_ENABLED` environment variable was introduced. -If `$STAGING_ENABLED` is defined in your project then the application will be automatically deployed to a `staging` -environment, and a `production_manual` job will be enabled for you when you're ready to manually deploy to production. -Otherwise if `$STAGING_ENABLED` is not defined, then the application will be automatically deployed to the `production` -environment. +If `STAGING_ENABLED` is defined in your project (e.g., set `STAGING_ENABLED` to +`1` as a secret variable), then the application will be automatically deployed +to a `staging` environment, and a `production_manual` job will be created for +you when you're ready to manually deploy to production. ## Currently supported languages @@ -667,4 +670,3 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/ [Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml [GitLab Omnibus Helm Chart]: ../../install/kubernetes/gitlab_omnibus.md [ee]: https://about.gitlab.com/products/ -[ci-yml-160]: https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/160 -- GitLab