Add latest changes from gitlab-org/gitlab@12-3-auto-deploy-20190916stable-branch-foss-test

11 files changed, 13 insertions, 28 deletions

diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 93317d310db..4da527154ad 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -515,7 +515,7 @@ If you're running multiple Runners you will have to modify all configuration fil
 >   login to GitLab's Container Registry.
 
 Once you've built a Docker image, you can push it up to the built-in
-[GitLab Container Registry](../../user/packages/container_registry/index.md).
+[GitLab Container Registry](../../user/project/container_registry.md).
 Some things you should be aware of:
 
 - You must [log in to the container registry](#authenticating-to-the-container-registry)
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index 0d78e1f6953..925653f9fdf 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -43,7 +43,7 @@ few important details:
 In the following example, kaniko is used to:
 
 1. Build a Docker image.
-1. Then push it to [GitLab Container Registry](../../user/packages/container_registry/index.md).
+1. Then push it to [GitLab Container Registry](../../user/project/container_registry.md).
 
 The job will run only when a tag is pushed. A `config.json` file is created under
 `/kaniko/.docker` with the needed GitLab Container Registry credentials taken from the
diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index 32f9ab2205a..b41fd7971d6 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -679,7 +679,7 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 ### Scoping environments with specs
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
-> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/30779) in GitLab 12.2.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30779) to Core in Gitlab 12.2.
 
 You can limit the environment scope of a variable by
 defining which environments it can be available for.
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index d79821ff258..808e4285f2f 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -437,7 +437,7 @@ We used `docker-php-ext-install` (provided by the official PHP Docker image) to
 
 #### Setting Up GitLab Container Registry
 
-Now that we have our `Dockerfile` let's build and push it to our [GitLab Container Registry](../../../user/packages/container_registry/index.md).
+Now that we have our `Dockerfile` let's build and push it to our [GitLab Container Registry](../../../user/project/container_registry.md).
 
 > The registry is the place to store and tag images for later use. Developers may want to maintain their own registry for private, company images, or for throw-away images used only in testing. Using GitLab Container Registry means you don't need to set up and administer yet another service or use a public registry.
 
@@ -445,7 +445,7 @@ On your GitLab project repository navigate to the **Registry** tab.
 
 ![container registry page empty image](img/container_registry_page_empty_image.png)
 
-You may need to [enable Container Registry](../../../user/packages/container_registry/index.md#enable-the-container-registry-for-your-project) to your project to see this tab. You'll find it under your project's **Settings > General > Permissions**.
+You may need to [enable Container Registry](../../../user/project/container_registry.md#enable-the-container-registry-for-your-project) to your project to see this tab. You'll find it under your project's **Settings > General > Permissions**.
 
 To start using Container Registry on our machine, we first need to login to the GitLab registry using our GitLab username and password:
 
diff --git a/doc/ci/introduction/img/gitlab_workflow_example_extended_11_11.png b/doc/ci/introduction/img/gitlab_workflow_example_extended_11_11.png
new file mode 100644
index 00000000000..a0874f66eaa
--- /dev/null
+++ b/doc/ci/introduction/img/gitlab_workflow_example_extended_11_11.png
diff --git a/doc/ci/introduction/img/gitlab_workflow_example_extended_v12_3.png b/doc/ci/introduction/img/gitlab_workflow_example_extended_v12_3.png
deleted file mode 100644
index 6e1066d4868..00000000000
--- a/doc/ci/introduction/img/gitlab_workflow_example_extended_v12_3.png
+++ /dev/null
diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md
index b15978a0aaa..366aca3442e 100644
--- a/doc/ci/introduction/index.md
+++ b/doc/ci/introduction/index.md
@@ -174,7 +174,7 @@ If we take a deeper look into the basic workflow, we can see
 the features available in GitLab at each stage of the DevOps
 lifecycle, as shown on the illustration below.
 
-![Deeper look into the basic CI/CD workflow](img/gitlab_workflow_example_extended_v12_3.png)
+![Deeper look into the basic CI/CD workflow](img/gitlab_workflow_example_extended_11_11.png)
 
 If you look at the image from the left to the right,
 you'll see some of the features available in GitLab
@@ -187,9 +187,9 @@ according to each stage (Verify, Package, Release).
    - Perform a series of tests, such as [Container Scanning](../../user/application_security/container_scanning/index.md) **(ULTIMATE)**, [Dependency Scanning](../../user/application_security/dependency_scanning/index.md) **(ULTIMATE)**, and [JUnit tests](../junit_test_reports.md).
    - Deploy your changes with [Review Apps](../review_apps/index.md) to preview the app changes on every branch.
 1. **Package**:
-   - Store Docker images with [Container Registry](../../user/packages/container_registry/index.md).
-   - Store NPM packages with [NPM Registry](../../user/packages/npm_registry/index.md). **(PREMIUM)**
-   - Store Maven artifacts with [Maven Repository](../../user/packages/maven_repository/index.md). **(PREMIUM)**
+   - Store Docker images with [Container Registry](../../user/project/container_registry.md).
+   - Store NPM packages with [NPM Registry](../../user/project/packages/npm_registry.md). **(PREMIUM)**
+   - Store Maven artifacts with [Maven Repository](../../user/project/packages/maven_repository.md). **(PREMIUM)**
 1. **Release**:
    - Continuous Deployment, automatically deploying your app to production.
    - Continuous Delivery, manually click to deploy your app to production.
diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md
index 29eba5ea928..ace1204511e 100644
--- a/doc/ci/jenkins/index.md
+++ b/doc/ci/jenkins/index.md
@@ -27,7 +27,7 @@ There are some high level differences between the products worth mentioning:
 - The `.gitlab-ci.yml` file is checked in to the root of your repository, much like a Jenkinsfile, but
   is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most
   analagous to the declarative Jenkinsfile format.
-- GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
+- GitLab comes with a [container registry](../../user/project/container_registry.md), and we recommend using
   container images to set up your build environment.
 
 ## Groovy vs. YAML
@@ -209,7 +209,7 @@ Because GitLab is integrated tightly with git, SCM polling options for triggers
 
 GitLab does not support a separate `tools` directive. Our best-practice reccomendation is to use pre-built
 container images, which can be cached, and can be built to already contain the tools you need for your pipelines. Pipelines can
-be set up to automatically build these images as needed and deploy them to the [container registry](../../user/packages/container_registry/index.md).
+be set up to automatically build these images as needed and deploy them to the [container registry](../../user/project/container_registry.md).
 
 If you're not using container images with Docker/Kubernetes, for example on Mac or FreeBSD, then the `shell` executor does require you to
 set up your environment either in advance or as part of the jobs. You could create a `before_script`
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
index 4e486af9b29..f62a4660713 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -277,6 +277,6 @@ removed with one of the future versions of GitLab.
 [ee]: https://about.gitlab.com/pricing/
 [variables]: ../variables/README.md
 [predef]: ../variables/README.md#predefined-environment-variables
-[registry]: ../../user/packages/container_registry/index.md
+[registry]: ../../user/project/container_registry.md
 [permissions]: ../../user/permissions.md#job-permissions
 [trigapi]: ../../api/pipeline_triggers.md
diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md
index e3ff3385f97..5a8de3dd4d1 100644
--- a/doc/ci/variables/predefined_variables.md
+++ b/doc/ci/variables/predefined_variables.md
@@ -126,5 +126,5 @@ future GitLab releases.**
 | `GITLAB_FEATURES`                       | 10.6   | all    | The comma separated list of licensed features available for your instance and plan |
 
 [gitlab-deploy-token]: ../../user/project/deploy_tokens/index.md#gitlab-deploy-token
-[registry]: ../../user/packages/container_registry/index.md
+[registry]: ../../user/project/container_registry.md
 [dependent-repositories]: ../../user/project/new_ci_build_permissions_model.md#dependent-repositories
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index aa188facebd..5014d294a9a 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -110,7 +110,6 @@ The following table lists available parameters for jobs:
 | [`dependencies`](#dependencies)                    | Other jobs that a job depends on so that you can pass artifacts between them.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | [`coverage`](#coverage)                            | Code coverage settings for a given job.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 | [`retry`](#retry)                                  | When and how many times a job can be auto-retried in case of a failure.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| [`timeout`](#timeout)                              | Define a custom timeout that would take precedence over the project-wide one.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
 | [`parallel`](#parallel)                            | How many instances of a job should be run in parallel.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | [`trigger`](#trigger-premium)                      | Defines a downstream pipeline trigger.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | [`include`](#include)                              | Allows this job to include external YAML files. Also available: `include:local`, `include:file`, `include:template`, and `include:remote`.                                                                                                                                                                                                                                                                                                                                                                                                                                              |
@@ -1996,20 +1995,6 @@ Possible values for `when` are:
 - `missing_dependency_failure`: Retry if a dependency was missing.
 - `runner_unsupported`: Retry if the runner was unsupported.
 
-### timeout
-
-`timeout` allows you to configure a timeout for a specific job:
-
-```yaml
-build:
-  script: build.sh
-  timeout: 3 hours 30 minutes
-
-test:
-  script: rspec
-  timeout: 3h 30m
-```
-
 ### `parallel`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22631) in GitLab 11.5.