Add latest changes from gitlab-org/gitlab@13-10-stable-eev13.10.0-rc41

10 files changed, 37 insertions, 255 deletions

diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md
index b48dd561a66..fc6807fd191 100644
--- a/doc/ci/examples/README.md
+++ b/doc/ci/examples/README.md
@@ -25,7 +25,6 @@ The following table lists examples with step-by-step tutorials that are containe
 | Use case                      | Resource |
 |-------------------------------|----------|
 | Browser performance testing   | [Browser Performance Testing with the Sitespeed.io container](../../user/project/merge_requests/browser_performance_testing.md). |
-| Clojure                       | [Test a Clojure application with GitLab CI/CD](test-clojure-application.md). |
 | Deployment with Dpl           | [Using `dpl` as deployment tool](deployment/README.md). |
 | GitLab Pages                  | See the [GitLab Pages](../../user/project/pages/index.md) documentation for a complete example of deploying a static site. |
 | End-to-end testing            | [End-to-end testing with GitLab CI/CD and WebdriverIO](end_to_end_testing_webdriverio/index.md). |
@@ -35,8 +34,6 @@ The following table lists examples with step-by-step tutorials that are containe
 | PHP with Laravel, Envoy       | [Test and deploy Laravel applications with GitLab CI/CD and Envoy](laravel_with_gitlab_and_envoy/index.md). |
 | PHP with npm, SCP             | [Running Composer and npm scripts with deployment via SCP in GitLab CI/CD](deployment/composer-npm-deploy.md). |
 | PHP with PHPunit, `atoum`       | [Testing PHP projects](php.md). |
-| Python on Heroku              | [Test and deploy a Python application with GitLab CI/CD](test-and-deploy-python-application-to-heroku.md). |
-| Ruby on Heroku                | [Test and deploy a Ruby application with GitLab CI/CD](test-and-deploy-ruby-application-to-heroku.md). |
 | Secrets management with Vault | [Authenticating and Reading Secrets With HashiCorp Vault](authenticating-with-hashicorp-vault/index.md). |
 
 ### Contributed examples
@@ -47,10 +44,13 @@ separate example projects:
 
 | Use case                      | Resource |
 |-------------------------------|----------|
+| Clojure                       | [Test a Clojure application with GitLab CI/CD](https://gitlab.com/gitlab-examples/clojure-web-application). |
 | Game development              | [DevOps and Game Development with GitLab CI/CD](https://gitlab.com/gitlab-examples/gitlab-game-demo/). |
 | Java with Maven               | [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://gitlab.com/gitlab-examples/maven/simple-maven-example). |
 | Java with Spring Boot         | [Deploy a Spring Boot application to Cloud Foundry with GitLab CI/CD](https://gitlab.com/gitlab-examples/spring-gitlab-cf-deploy-demo). |
 | Parallel testing Ruby & JS    | [GitLab CI/CD parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). |
+| Python on Heroku              | [Test and deploy a Python application with GitLab CI/CD](https://gitlab.com/gitlab-examples/python-getting-started). |
+| Ruby on Heroku                | [Test and deploy a Ruby application with GitLab CI/CD](https://gitlab.com/gitlab-examples/ruby-getting-started). |
 | Scala on Heroku               | [Test and deploy a Scala application to Heroku](https://gitlab.com/gitlab-examples/scala-sbt). |
 
 ## CI/CD templates
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
index 2d8c92a1a74..40ba7cff5f9 100644
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@@ -53,7 +53,9 @@ The JWT's payload looks like this:
   "job_id": "1212",                              #
   "ref": "auto-deploy-2020-04-01",               # Git ref for this job
   "ref_type": "branch",                          # Git ref type, branch or tag
-  "ref_protected": "true"                        # true if this git ref is protected, false otherwise
+  "ref_protected": "true",                       # true if this git ref is protected, false otherwise
+  "environment": "production",                   # Environment this job deploys to, if present (GitLab 13.9 and later)
+  "environment_protected": "true"                # true if deployed environment is protected, false otherwise (GitLab 13.9 and later)
 }
 ```
 
@@ -178,7 +180,7 @@ $ vault write auth/jwt/config \
 
 For the full list of available configuration options, see Vault's [API documentation](https://www.vaultproject.io/api/auth/jwt#configure).
 
-The following job, when run for the `master` branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
+The following job, when run for the default branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
 
 ```yaml
 read_secrets:
diff --git a/doc/ci/examples/deployment/README.md b/doc/ci/examples/deployment/README.md
index 779ca98084f..4d2c22a17f0 100644
--- a/doc/ci/examples/deployment/README.md
+++ b/doc/ci/examples/deployment/README.md
@@ -116,7 +116,7 @@ We also use two secure variables:
 ## Storing API keys
 
 To add secure variables, navigate to your project's
-**Settings > CI / CD > Variables**. The variables that are defined
+**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
@@ -128,4 +128,4 @@ 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 variables](../../variables/README.md).
+Read more about the [CI/CD variables](../../variables/README.md).
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 2d7ba2bc759..62607320410 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -122,7 +122,7 @@ Therefore, for a production environment we use additional steps to ensure that a
 
 Since this was a WordPress project, I gave real life code snippets. Some further ideas you can pursue:
 
-- Having a slightly different script for `master` branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
+- Having a slightly different script for the default branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
 - Instead of pushing it live, you can push it to WordPress official repository (with creating a SVN commit, etc.).
 - You could generate i18n text domains on the fly.
 
diff --git a/doc/ci/examples/end_to_end_testing_webdriverio/index.md b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
index e20e86e8936..07bad3afc65 100644
--- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md
+++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
@@ -50,14 +50,14 @@ infrastructure is up and running, and that your units of code work well together
 [Selenium](https://www.selenium.dev/) is a piece of software that can control web browsers, e.g., to make them
 visit a specific URL or interact with elements on the page. It can be programmatically controlled
 from a variety of programming languages. In this article we're going to be using the
-[WebdriverIO](https://webdriver.io/) JavaScript bindings, but the general concept should carry over
+[WebdriverIO](http://v4.webdriver.io/) JavaScript bindings, but the general concept should carry over
 pretty well to
 [other programming languages supported by Selenium](https://www.selenium.dev/documentation/en/legacy_docs/selenium_rc/).
 
 ## Writing tests
 
 You can write tests using
-[several testing frameworks supported by WebdriverIO](https://webdriver.io/guide/testrunner/frameworks.html).
+[several testing frameworks supported by WebdriverIO](http://v4.webdriver.io/guide/testrunner/frameworks.html).
 We will be using [Jasmine](https://jasmine.github.io/) here:
 
 ```javascript
@@ -82,14 +82,14 @@ multiple tests, such as making sure you are logged in.
 
 The function `it` defines an individual test.
 
-[The `browser` object](https://webdriver.io/guide/testrunner/browserobject.html) is WebdriverIO's
-special sauce. It provides most of [the WebdriverIO API methods](https://webdriver.io/api.html) that are the key to
+[The `browser` object](http://v4.webdriver.io/guide/testrunner/browserobject.html) is WebdriverIO's
+special sauce. It provides most of [the WebdriverIO API methods](http://v4.webdriver.io/docs/api/) that are the key to
 steering the browser. In this case, we can use
-[`browser.url`](https://webdriver.io/api/protocol/url.html) to visit `/page-that-does-not-exist` to
-hit our 404 page. We can then use [`browser.getUrl`](https://webdriver.io/api/property/getUrl.html)
+[`browser.url`](http://v4.webdriver.io/api/protocol/url.html) to visit `/page-that-does-not-exist` to
+hit our 404 page. We can then use [`browser.getUrl`](http://v4.webdriver.io/api/property/getUrl.html)
 to verify that the current page is indeed at the location we specified. To interact with the page,
 we can simply pass CSS selectors to
-[`browser.element`](https://webdriver.io/api/protocol/element.html) to get access to elements on the
+[`browser.element`](http://v4.webdriver.io/api/protocol/element.html) to get access to elements on the
 page and to interact with them - for example, to click on the link back to the home page.
 
 The simple test shown above
@@ -111,9 +111,9 @@ you can use [the Webpack Dev Server WebdriverIO plugin](https://www.npmjs.com/pa
 that automatically starts a development server before executing the tests.
 
 The WebdriverIO documentation has
-[an overview of all configuration options](https://webdriver.io/guide/getstarted/configuration.html), but the
+[an overview of all configuration options](http://v4.webdriver.io/guide/getstarted/configuration.html), but the
 easiest way to get started is to start with
-[WebdriverIO's default configuration](https://webdriver.io/guide/testrunner/configurationfile.html), which
+[WebdriverIO's default configuration](http://v4.webdriver.io/guide/testrunner/configurationfile.html), which
 provides an overview of all available options. The two options that are going to be most relevant now are the
 `specs` option, which is an array of paths to your tests, and the `baseUrl` option, which points to where your app is
 running. And finally, we will need to tell WebdriverIO in which browsers we would like to run our
@@ -186,7 +186,7 @@ e2e:chrome:
 
 Now that we have a job to run the end-to-end tests in, we need to tell WebdriverIO how to connect to
 the Selenium servers running alongside it. We've already cheated a bit above by
-passing the value of the [`host`](https://webdriver.io/guide/getstarted/configuration.html#host)
+passing the value of the [`host`](http://v4.webdriver.io/guide/getstarted/configuration.html#host)
 option as an argument to `npm run confidence-check` on the command line.
 However, we still need to tell WebdriverIO which browser is available for it to use.
 
@@ -253,7 +253,7 @@ production project, see:
 - [Flockademic's `.gitlab-ci.yml`](https://gitlab.com/Flockademic/Flockademic/blob/dev/.gitlab-ci.yml)
 - [Flockademic's tests](https://gitlab.com/Flockademic/Flockademic/tree/dev/__e2e__)
 
-There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](https://webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
+There's plenty more that WebdriverIO can do. For example, you can configure a [`screenshotPath`](http://v4.webdriver.io/guide/getstarted/configuration.html#screenshotPath) to tell WebdriverIO to take
 a screenshot when tests are failing. Then tell GitLab CI/CD to store those
 [artifacts](../../yaml/README.md#artifacts), and you'll be able to see what went
 wrong within GitLab.
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 a02a5347734..2acd7315630 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -128,7 +128,7 @@ We'll use this variable in the `.gitlab-ci.yml` later, to easily connect to our
 
 ![variables page](img/variables_page.png)
 
-We also need to add the public key to **Project** > **Settings** > **Repository** as a [Deploy Key](../../../ssh/README.md#deploy-keys), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project).
+We also need to add the public key to **Project** > **Settings** > **Repository** as a [Deploy Key](../../../user/project/deploy_keys/index.md), which gives us the ability to access our repository from the server through [SSH protocol](../../../gitlab-basics/command-line-commands.md#start-working-on-your-project).
 
 ```shell
 # As the deployer user on the server
@@ -619,7 +619,7 @@ deploy_production:
     - master
 ```
 
-You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/), to final test your application before deploying to production.
+You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/), to final test your application before deploying to production.
 
 ### Turn on GitLab CI/CD
 
diff --git a/doc/ci/examples/semantic-release.md b/doc/ci/examples/semantic-release.md
index c0fc93fe1b3..28a0080626a 100644
--- a/doc/ci/examples/semantic-release.md
+++ b/doc/ci/examples/semantic-release.md
@@ -91,7 +91,7 @@ As part of publishing a package, semantic-release increases the version number i
 1. Navigate to **Project > Settings > Access Tokens**.
 1. Give the token a name, and select the `api` scope.
 1. Click **Create project access token** and copy its value.
-1. Navigate to **Project > Settings > CI / CD > Variables**.
+1. Navigate to **Project > Settings > CI/CD > Variables**.
 1. Click **Add Variable**.
 1. In the **Key** field, enter `GITLAB_TOKEN`. In the **Value** field, paste the token created above. Check the **Mask variable** option and click **Add variable**.
 
@@ -126,7 +126,7 @@ Test the pipeline by creating a commit with a message like:
 fix: testing patch releases
 ```
 
-Push the commit to `master`. The pipeline should create a new release (`v1.0.0`) on the project's **Releases** page and publish a new version of the package to the project's **Package Registry** page.
+Push the commit to the default branch. The pipeline should create a new release (`v1.0.0`) on the project's **Releases** page and publish a new version of the package to the project's **Package Registry** page.
 
 To create a minor release, use a commit message like:
 
diff --git a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
index 28d00362309..4a6555a58a6 100644
--- a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
@@ -1,101 +1,8 @@
 ---
-stage: Verify
-group: Continuous Integration
-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: 'README.md#contributed-examples'
 ---
 
-# Test and deploy a Python application with GitLab CI/CD
+This document was moved to [another location](README.md#contributed-examples).
 
-This example will guide you how to run tests in your Python application and deploy it automatically as Heroku application.
-
-You can also view or fork the complete [example source](https://gitlab.com/ayufan/python-getting-started).
-
-## Configure project
-
-This is what the `.gitlab-ci.yml` file looks like for this project:
-
-```yaml
-stages:
-  - test
-  - deploy
-
-test:
-  stage: test
-  script:
-    # this configures Django application to use attached postgres database that is run on `postgres` host
-    - export DATABASE_URL=postgres://postgres:@postgres:5432/python-test-app
-    - apt-get update -qy
-    - apt-get install -y python-dev python-pip
-    - pip install -r requirements.txt
-    - python manage.py test
-
-staging:
-  stage: deploy
-  script:
-    - apt-get update -qy
-    - apt-get install -y ruby-dev
-    - gem install dpl
-    - dpl --provider=heroku --app=gitlab-ci-python-test-staging --api-key=$HEROKU_STAGING_API_KEY
-  only:
-    - master
-
-production:
-  stage: deploy
-  script:
-    - apt-get update -qy
-    - apt-get install -y ruby-dev
-    - gem install dpl
-    - dpl --provider=heroku --app=gitlab-ci-python-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY
-  only:
-    - tags
-```
-
-This project has three jobs:
-
-- `test` - used to test Django application.
-- `staging` - used to automatically deploy staging environment every push to `master` branch.
-- `production` - used to automatically deploy production environment for every created tag.
-
-## Store API keys
-
-You'll need to create two variables in **Settings > CI/CD > Variables** in your GitLab project:
-
-- `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app.
-- `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
-
-Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/account).
-
-## Create Heroku application
-
-For each of your environments, you'll need to create a new Heroku application.
-You can do this through the [Dashboard](https://dashboard.heroku.com/).
-
-## Create a runner
-
-First install [Docker Engine](https://docs.docker.com/installation/).
-
-To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/index.html).
-You can use public runners available on `gitlab.com` or you can register your own:
-
-```shell
-cat > /tmp/test-config.template.toml << EOF
-[[runners]]
-[runners.docker]
-[[runners.docker.services]]
-name = "postgres:latest"
-EOF
-
-gitlab-runner register \
-  --non-interactive \
-  --url "https://gitlab.com/" \
-  --registration-token "PROJECT_REGISTRATION_TOKEN" \
-  --description "python-3.5" \
-  --executor "docker" \
-  --template-config /tmp/test-config.template.toml \
-  --docker-image python:3.5
-```
-
-With the command above, you create a runner that uses the [`python:3.5`](https://hub.docker.com/_/python) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database.
-
-To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.
+<!-- This redirect file can be deleted after 2021-06-01. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
index 5bf0b3d01be..4a6555a58a6 100644
--- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
@@ -1,97 +1,8 @@
 ---
-stage: Verify
-group: Continuous Integration
-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: 'README.md#contributed-examples'
 ---
 
-# Test and deploy a Ruby application with GitLab CI/CD
+This document was moved to [another location](README.md#contributed-examples).
 
-This example will guide you through how to run tests in your Ruby on Rails application and deploy it automatically as a Heroku application.
-
-You can also view or fork the complete [example source](https://gitlab.com/ayufan/ruby-getting-started) and view the logs of its past [CI jobs](https://gitlab.com/ayufan/ruby-getting-started/-/jobs?scope=finished).
-
-## Configure the project
-
-This is what the `.gitlab-ci.yml` file looks like for this project:
-
-```yaml
-test:
-  stage: test
-  script:
-    - apt-get update -qy
-    - apt-get install -y nodejs
-    - bundle install --path /cache
-    - bundle exec rake db:create RAILS_ENV=test
-    - bundle exec rake test
-
-staging:
-  stage: deploy
-  script:
-    - gem install dpl --pre
-    - dpl heroku api --app=gitlab-ci-ruby-test-staging --api-key=$HEROKU_STAGING_API_KEY
-  only:
-    - master
-
-production:
-  stage: deploy
-  script:
-    - gem install dpl --pre
-    - dpl heroku api --app=gitlab-ci-ruby-test-prod --api-key=$HEROKU_PRODUCTION_API_KEY
-  only:
-    - tags
-```
-
-This project has three jobs:
-
-- `test` - used to test Rails application.
-- `staging` - used to automatically deploy staging environment every push to `master` branch.
-- `production` - used to automatically deploy production environment for every created tag.
-
-## Store API keys
-
-You'll need to create two CI/CD variables in your project's **Settings > CI/CD > Variables** and do not check **Protect variable** or **Mask variable**:
-
-- `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app.
-- `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
-
-Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/account).
-
-## Create Heroku application
-
-For each of your environments, you'll need to create a new Heroku application.
-You can do this through the [Heroku Dashboard](https://dashboard.heroku.com/).
-
-## Create a runner
-
-First install [Docker Engine](https://docs.docker.com/installation/).
-
-To build this project you also need to have [GitLab Runner](https://docs.gitlab.com/runner/).
-You can use public runners available on `gitlab.com` or register your own. Start by
-creating a template configuration file to pass complex configuration:
-
-```shell
-cat > /tmp/test-config.template.toml << EOF
-[[runners]]
-[runners.docker]
-[[runners.docker.services]]
-name = "postgres:latest"
-EOF
-```
-
-Finally, register the runner, passing the newly-created template configuration file:
-
-```shell
-gitlab-runner register \
-  --non-interactive \
-  --url "https://gitlab.com/" \
-  --registration-token "PROJECT_REGISTRATION_TOKEN" \
-  --description "ruby:2.6" \
-  --executor "docker" \
-  --template-config /tmp/test-config.template.toml \
-  --docker-image ruby:2.6
-```
-
-With the command above, you create a runner that uses the [`ruby:2.6`](https://hub.docker.com/_/ruby) image and uses a [PostgreSQL](https://hub.docker.com/_/postgres) database.
-
-To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.
+<!-- This redirect file can be deleted after 2021-06-01. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/ci/examples/test-clojure-application.md b/doc/ci/examples/test-clojure-application.md
index b6691930a2c..8aa1fb21275 100644
--- a/doc/ci/examples/test-clojure-application.md
+++ b/doc/ci/examples/test-clojure-application.md
@@ -1,46 +1,8 @@
 ---
-stage: Verify
-group: Continuous Integration
-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: 'README.md#contributed-examples'
 ---
 
-NOTE:
-This document has not been updated recently and could be out of date. For the latest documentation, see the [GitLab CI/CD](../README.md) page and the [GitLab CI/CD Pipeline Configuration Reference](../yaml/README.md).
+This document was moved to [another location](README.md#contributed-examples).
 
-# Test a Clojure application with GitLab CI/CD
-
-This example will guide you how to run tests on your Clojure application.
-
-You can view or fork the [example source](https://gitlab.com/dzaporozhets/clojure-web-application) and view the logs of its past [CI jobs](https://gitlab.com/dzaporozhets/clojure-web-application/builds?scope=finished).
-
-## Configure the project
-
-This is what the `.gitlab-ci.yml` file looks like for this project:
-
-```yaml
-variables:
-  POSTGRES_DB: sample-test
-  DATABASE_URL: "postgresql://postgres@postgres:5432/sample-test"
-
-before_script:
-  - apt-get update -y
-  - apt-get install default-jre postgresql-client -y
-  - wget https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein
-  - chmod a+x lein
-  - export LEIN_ROOT=1
-  - PATH=$PATH:.
-  - lein deps
-  - lein migratus migrate
-
-test:
-  script:
-    - lein test
-```
-
-In `before_script`, we install JRE and [Leiningen](https://leiningen.org/).
-
-The sample project uses the [migratus](https://github.com/yogthos/migratus) library to manage database migrations, and
-we have added a database migration as the last step of `before_script`.
-
-You can use public runners available on `gitlab.com` for testing your application with this configuration.
+<!-- This redirect file can be deleted after 2021-05-26. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->