Rename ci examples readmes to index

Part of effort to move all to indexes

Changelog: changed

doc/ci/README.md

@@ -123,7 +123,7 @@ Its feature set is listed on the table below according to DevOps stages.
 ## Examples
 
 Find example project code and tutorials for using GitLab CI/CD with a variety of app frameworks, languages, and platforms
-on the [CI Examples](examples/README.md) page.
+on the [CI Examples](examples/index.md) page.
 
 ## Administration **(FREE SELF)**
 

doc/ci/examples/deployment/README.md

 ---
-stage: Release
-group: Release
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: tutorial
+redirect_to: 'index.md'
 ---
 
-# Using Dpl as deployment tool
+This document was moved to [another location](index.md).
 
-[Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
-continuous deployment that's developed and used by Travis CI, but can also be
-used with GitLab CI/CD.
-
-Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers).
-
-## Requirements
-
-To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
-
-## Basic usage
-
-Dpl can be installed on any machine with:
-
-```shell
-gem install dpl
-```
-
-This allows you to test all commands from your local terminal, rather than
-having to test it on a CI server.
-
-If you don't have Ruby installed you can do it on Debian-compatible Linux with:
-
-```shell
-apt-get update
-apt-get install ruby-dev
-```
-
-The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more.
-To use it simply define provider and any additional parameters required by the provider.
-
-For example if you want to use it to deploy your application to Heroku, you need to specify `heroku` as provider, specify `api_key` and `app`.
-All possible parameters can be found in the [Heroku API section](https://github.com/travis-ci/dpl#heroku-api).
-
-```yaml
-staging:
-  stage: deploy
-  script:
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
-```
-
-In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
-
-To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
-
-## Using Dpl with Docker
-
-In most cases, you configured [GitLab Runner](https://docs.gitlab.com/runner/) to use your server's shell commands.
-This means that all commands are run in the context of local user (e.g. `gitlab_runner` or `gitlab_ci_multi_runner`).
-It also means that most probably in your Docker container you don't have the Ruby runtime installed.
-You must install it:
-
-```yaml
-staging:
-  stage: deploy
-  script:
-    - apt-get update -yq
-    - apt-get install -y ruby-dev
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
-  only:
-    - master
-```
-
-The first line `apt-get update -yq` updates the list of available packages,
-where second `apt-get install -y ruby-dev` installs the Ruby runtime on system.
-The above example is valid for all Debian-compatible systems.
-
-## Usage in staging and production
-
-It's pretty common in the development workflow to have staging (development) and
-production environments
-
-Let's consider the following example: we would like to deploy the `master`
-branch to `staging` and all tags to the `production` environment.
-The final `.gitlab-ci.yml` for that setup would look like this:
-
-```yaml
-staging:
-  stage: deploy
-  script:
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
-  only:
-    - master
-
-production:
-  stage: deploy
-  script:
-    - gem install dpl
-    - dpl --provider=heroku --app=my-app-production --api_key=$HEROKU_PRODUCTION_API_KEY
-  only:
-    - tags
-```
-
-We created two deploy jobs that are executed on different events:
-
-1. `staging` is executed for all commits that were pushed to `master` branch,
-1. `production` is executed for all pushed tags.
-
-We also use two secure variables:
-
-1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
-1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
-
-## Storing API keys
-
-To add secure variables, navigate to your project's
-**Settings > CI/CD > Variables**. The variables that are defined
-in the project settings are sent along with the build script to the runner.
-The secure variables are stored out of the repository. Never store secrets in
-your project's `.gitlab-ci.yml`. It is also important that the secret's value
-is hidden in the job log.
-
-You access added variable by prefixing it's name with `$` (on non-Windows runners)
-or `%` (for Windows Batch runners):
-
-1. `$VARIABLE` - use it for non-Windows runners
-1. `%VARIABLE%` - use it for Windows Batch runners
-
-Read more about the [CI/CD variables](../../variables/README.md).
+<!-- This redirect file can be deleted after 2021-09-28. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/ci/examples/deployment/index.md

+---
+stage: Release
+group: Release
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+type: tutorial
+---
+
+# Using Dpl as deployment tool
+
+[Dpl](https://github.com/travis-ci/dpl) (pronounced like the letters D-P-L) is a deploy tool made for
+continuous deployment that's developed and used by Travis CI, but can also be
+used with GitLab CI/CD.
+
+Dpl can be used to deploy to any of the [supported providers](https://github.com/travis-ci/dpl#supported-providers).
+
+## Requirements
+
+To use Dpl you need at least Ruby 1.9.3 with ability to install gems.
+
+## Basic usage
+
+Dpl can be installed on any machine with:
+
+```shell
+gem install dpl
+```
+
+This allows you to test all commands from your local terminal, rather than
+having to test it on a CI server.
+
+If you don't have Ruby installed you can do it on Debian-compatible Linux with:
+
+```shell
+apt-get update
+apt-get install ruby-dev
+```
+
+The Dpl provides support for vast number of services, including: Heroku, Cloud Foundry, AWS/S3, and more.
+To use it simply define provider and any additional parameters required by the provider.
+
+For example if you want to use it to deploy your application to Heroku, you need to specify `heroku` as provider, specify `api_key` and `app`.
+All possible parameters can be found in the [Heroku API section](https://github.com/travis-ci/dpl#heroku-api).
+
+```yaml
+staging:
+  stage: deploy
+  script:
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
+```
+
+In the above example we use Dpl to deploy `my-app-staging` to Heroku server with API key stored in `HEROKU_STAGING_API_KEY` secure variable.
+
+To use different provider take a look at long list of [Supported Providers](https://github.com/travis-ci/dpl#supported-providers).
+
+## Using Dpl with Docker
+
+In most cases, you configured [GitLab Runner](https://docs.gitlab.com/runner/) to use your server's shell commands.
+This means that all commands are run in the context of local user (e.g. `gitlab_runner` or `gitlab_ci_multi_runner`).
+It also means that most probably in your Docker container you don't have the Ruby runtime installed.
+You must install it:
+
+```yaml
+staging:
+  stage: deploy
+  script:
+    - apt-get update -yq
+    - apt-get install -y ruby-dev
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
+  only:
+    - master
+```
+
+The first line `apt-get update -yq` updates the list of available packages,
+where second `apt-get install -y ruby-dev` installs the Ruby runtime on system.
+The above example is valid for all Debian-compatible systems.
+
+## Usage in staging and production
+
+It's pretty common in the development workflow to have staging (development) and
+production environments
+
+Let's consider the following example: we would like to deploy the `master`
+branch to `staging` and all tags to the `production` environment.
+The final `.gitlab-ci.yml` for that setup would look like this:
+
+```yaml
+staging:
+  stage: deploy
+  script:
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-staging --api_key=$HEROKU_STAGING_API_KEY
+  only:
+    - master
+
+production:
+  stage: deploy
+  script:
+    - gem install dpl
+    - dpl --provider=heroku --app=my-app-production --api_key=$HEROKU_PRODUCTION_API_KEY
+  only:
+    - tags
+```
+
+We created two deploy jobs that are executed on different events:
+
+1. `staging` is executed for all commits that were pushed to `master` branch,
+1. `production` is executed for all pushed tags.
+
+We also use two secure variables:
+
+1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
+1. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
+
+## Storing API keys
+
+To add secure variables, navigate to your project's
+**Settings > CI/CD > Variables**. The variables that are defined
+in the project settings are sent along with the build script to the runner.
+The secure variables are stored out of the repository. Never store secrets in
+your project's `.gitlab-ci.yml`. It is also important that the secret's value
+is hidden in the job log.
+
+You access added variable by prefixing it's name with `$` (on non-Windows runners)
+or `%` (for Windows Batch runners):
+
+1. `$VARIABLE` - use it for non-Windows runners
+1. `%VARIABLE%` - use it for Windows Batch runners
+
+Read more about the [CI/CD variables](../../variables/README.md).

doc/ci/troubleshooting.md

@@ -52,8 +52,8 @@ and check if their values are what you expect.
 The [complete `gitlab-ci.yml` reference](yaml/README.md) contains a full list of
 every keyword you may need to use to configure your pipelines.
 
-You can also look at a large number of pipeline configuration [examples](examples/README.md)
-and [templates](examples/README.md#cicd-templates).
+You can also look at a large number of pipeline configuration [examples](examples/index.md)
+and [templates](examples/index.md#cicd-templates).
 
 ### Documentation for pipeline types
 

doc/ci/yaml/README.md

@@ -14,7 +14,7 @@ type: reference
 This document lists the configuration options for your GitLab `.gitlab-ci.yml` file.
 
 - For a quick introduction to GitLab CI/CD, follow the [quick start guide](../quick_start/index.md).
-- For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md).
+- For a collection of examples, see [GitLab CI/CD Examples](../examples/index.md).
 - To view a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab-ci.yml).
 
 When you are editing your `.gitlab-ci.yml` file, you can validate it with the

doc/development/cicd/templates.md

@@ -7,7 +7,7 @@ type: index, concepts, howto
 
 # Development guide for GitLab CI/CD templates
 
-This document explains how to develop [GitLab CI/CD templates](../../ci/examples/README.md).
+This document explains how to develop [GitLab CI/CD templates](../../ci/examples/index.md).
 
 ## Requirements for CI/CD templates
 

doc/user/admin_area/settings/continuous_integration.md

@@ -224,7 +224,7 @@ This feature is being re-evaluated in favor of a different
 We recommend that users who haven't yet implemented this feature wait for
 the new solution.
 
-You can set a [CI/CD template](../../../ci/examples/README.md#cicd-templates)
+You can set a [CI/CD template](../../../ci/examples/index.md#cicd-templates)
 as a required pipeline configuration for all projects on a GitLab instance. You can
 use a template from: