1 files changed, 0 insertions, 89 deletions
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 9c98f9c98c6..a3481f58c6c 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -28,11 +28,8 @@ If you want a quick introduction to GitLab CI, follow our
     - [only and except](#only-and-except)
     - [tags](#tags)
     - [when](#when)
-    - [environment](#environment)
     - [artifacts](#artifacts)
         - [artifacts:name](#artifacts-name)
-        - [artifacts:when](#artifacts-when)
-        - [artifacts:expire_in](#artifacts-expire_in)
     - [dependencies](#dependencies)
     - [before_script and after_script](#before_script-and-after_script)
 - [Hidden jobs](#hidden-jobs)
@@ -355,7 +352,6 @@ job_name:
 | cache         | no | Define list of files that should be cached between subsequent runs |
 | before_script | no | Override a set of commands that are executed before build |
 | after_script  | no | Override a set of commands that are executed after build |
-| environment   | no | Defines a name of environment to which deployment is done by this build |
 
 ### script
 
@@ -527,31 +523,6 @@ The above script will:
 1. Execute `cleanup_build_job` only when `build_job` fails
 2. Always execute `cleanup_job` as the last step in pipeline.
 
-### environment
-
->**Note:**
-Introduced in GitLab v8.9.0.
-
-`environment` is used to define that job does deployment to specific environment.
-This allows to easily track all deployments to your environments straight from GitLab.
-
-If `environment` is specified and no environment under that name does exist a new one will be created automatically.
-
-The `environment` name must contain only letters, digits, '-' and '_'.
-
----
-
-**Example configurations**
-
-```
-deploy to production:
-  stage: deploy
-  script: git push production HEAD:master
-  environment: production
-```
-
-The `deploy to production` job will be marked as doing deployment to `production` environment.
-
 ### artifacts
 
 >**Notes:**
@@ -680,66 +651,6 @@ job:
     untracked: true
 ```
 
-#### artifacts:when
-
->**Note:**
-Introduced in GitLab 8.9 and GitLab Runner v1.3.0.
-
-`artifacts:when` is used to upload artifacts on build failure or despite the
-failure.
-
-`artifacts:when` can be set to one of the following values:
-
-1. `on_success` - upload artifacts only when build succeeds. This is the default
-1. `on_failure` - upload artifacts only when build fails
-1. `always` - upload artifacts despite the build status
-
----
-
-**Example configurations**
-
-To upload artifacts only when build fails.
-
-```yaml
-job:
-  artifacts:
-    when: on_failure
-```
-
-#### artifacts:expire_in
-
->**Note:**
-Introduced in GitLab 8.9 and GitLab Runner v1.3.0.
-
-`artifacts:expire_in` is used to remove uploaded artifacts after specified time.
-By default artifacts are stored on GitLab forver.
-`expire_in` allows to specify after what time the artifacts should be removed.
-The artifacts will expire counting from the moment when they are uploaded and stored on GitLab.
-
-After artifacts uploading you can use the **Keep** button on build page to keep the artifacts forever.
-
-Artifacts are removed every hour, but they are not accessible after expire date.
-
-The value of `expire_in` is a elapsed time. The example of parsable values:
-- '3 mins 4 sec'
-- '2 hrs 20 min'
-- '2h20min'
-- '6 mos 1 day'
-- '47 yrs 6 mos and 4d'
-- '3 weeks and 2 days'
-
----
-
-**Example configurations**
-
-To expire artifacts after 1 week from the moment that they are uploaded:
-
-```yaml
-job:
-  artifacts:
-    expire_in: 1 week
-```
-
 ### dependencies
 
 >**Note:**