Replace Ruby 2.1/2.2/2.3 with Ruby 2.6 (and 2.7)

Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>

doc/administration/packages/container_registry.md

@@ -625,7 +625,7 @@ mounting the docker-daemon and setting `privileged = false` in the Runner's
 
 ```toml
   [runners.docker]
-    image = "ruby:2.1"
+    image = "ruby:2.6"
     privileged = false
     volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
 ```

doc/ci/docker/using_docker_images.md

@@ -32,14 +32,14 @@ A one-line example can be seen below:
 sudo gitlab-runner register \
   --url "https://gitlab.example.com/" \
   --registration-token "PROJECT_REGISTRATION_TOKEN" \
-  --description "docker-ruby-2.1" \
+  --description "docker-ruby:2.6" \
   --executor "docker" \
-  --docker-image ruby:2.1 \
+  --docker-image ruby:2.6 \
   --docker-services postgres:latest \
   --docker-services mysql:latest
 ```
 
-The registered runner will use the `ruby:2.1` Docker image and will run two
+The registered runner will use the `ruby:2.6` Docker image and will run two
 services, `postgres:latest` and `mysql:latest`, both of which will be
 accessible during the build process.
 
@@ -194,7 +194,7 @@ services that you want to use during build time:
 
 ```yaml
 default:
-  image: ruby:2.2
+  image: ruby:2.6
 
   services:
     - postgres:9.3
@@ -214,15 +214,15 @@ default:
   before_script:
     - bundle install
 
-test:2.1:
-  image: ruby:2.1
+test:2.6:
+  image: ruby:2.6
   services:
   - postgres:9.3
   script:
   - bundle exec rake spec
 
-test:2.2:
-  image: ruby:2.2
+test:2.7:
+  image: ruby:2.7
   services:
   - postgres:9.4
   script:
@@ -235,7 +235,7 @@ for `image` and `services`:
 ```yaml
 default:
   image:
-    name: ruby:2.2
+    name: ruby:2.6
     entrypoint: ["/bin/bash"]
 
   services:
@@ -277,7 +277,7 @@ services:
   command: ["postgres"]
 
 image:
-  name: ruby:2.2
+  name: ruby:2.6
   entrypoint: ["/bin/bash"]
 
 before_script:
@@ -773,7 +773,7 @@ time.
 
 1. Create any service container: `mysql`, `postgresql`, `mongodb`, `redis`.
 1. Create cache container to store all volumes as defined in `config.toml` and
-   `Dockerfile` of build image (`ruby:2.1` as in above example).
+   `Dockerfile` of build image (`ruby:2.6` as in above example).
 1. Create build container and link any service container to build container.
 1. Start build container and send job script to the container.
 1. Run job script.
@@ -818,11 +818,11 @@ Finally, create a build container by executing the `build_script` file we
 created earlier:
 
 ```sh
-docker run --name build -i --link=service-mysql:mysql --link=service-postgres:postgres ruby:2.1 /bin/bash < build_script
+docker run --name build -i --link=service-mysql:mysql --link=service-postgres:postgres ruby:2.6 /bin/bash < build_script
 ```
 
 The above command will create a container named `build` that is spawned from
-the `ruby:2.1` image and has two services linked to it. The `build_script` is
+the `ruby:2.6` image and has two services linked to it. The `build_script` is
 piped using STDIN to the bash interpreter which in turn executes the
 `build_script` in the `build` container.
 

doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md

@@ -71,12 +71,12 @@ gitlab-runner register \
   --non-interactive \
   --url "https://gitlab.com/" \
   --registration-token "PROJECT_REGISTRATION_TOKEN" \
-  --description "ruby-2.2" \
+  --description "ruby:2.6" \
   --executor "docker" \
-  --docker-image ruby:2.2 \
+  --docker-image ruby:2.6 \
   --docker-postgres latest
 ```
 
-With the command above, you create a Runner that uses the [ruby:2.2](https://hub.docker.com/_/ruby) image and uses a [postgres](https://hub.docker.com/_/postgres) database.
+With the command above, you create a Runner that uses the [ruby:2.6](https://hub.docker.com/_/ruby) image and uses a [postgres](https://hub.docker.com/_/postgres) database.
 
 To access the PostgreSQL database, connect to `host: postgres` as user `postgres` with no password.

doc/ci/yaml/README.md

@@ -3628,7 +3628,7 @@ having their own custom `script` defined:
 
 ```yaml
 .job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
-  image: ruby:2.1
+  image: ruby:2.6
   services:
     - postgres
     - redis
@@ -3650,13 +3650,13 @@ given hash into the current one", and `*` includes the named anchor
 
 ```yaml
 .job_template:
-  image: ruby:2.1
+  image: ruby:2.6
   services:
     - postgres
     - redis
 
 test1:
-  image: ruby:2.1
+  image: ruby:2.6
   services:
     - postgres
     - redis
@@ -3664,7 +3664,7 @@ test1:
     - test1 project
 
 test2:
-  image: ruby:2.1
+  image: ruby:2.6
   services:
     - postgres
     - redis

doc/development/performance.md

@@ -382,7 +382,7 @@ end
 ## String Freezing
 
 In recent Ruby versions calling `freeze` on a String leads to it being allocated
-only once and re-used. For example, on Ruby 2.3 this will only allocate the
+only once and re-used. For example, on Ruby 2.3 or later this will only allocate the
 "foo" String once:
 
 ```ruby

doc/user/project/pages/getting_started_part_four.md

 ---
-last_updated: 2019-06-04
+last_updated: 2020-01-06
 type: reference, howto
 ---
 
@@ -158,7 +158,7 @@ first thing GitLab Runner will look for in your `.gitlab-ci.yml` is a
 your container to run that script:
 
 ```yaml
-image: ruby:2.3
+image: ruby:2.7
 
 pages:
   script:
@@ -170,9 +170,9 @@ pages:
 ```
 
 In this case, you're telling the Runner to pull this image, which
-contains Ruby 2.3 as part of its file system. When you don't specify
+contains Ruby 2.7 as part of its file system. When you don't specify
 this image in your configuration, the Runner will use a default
-image, which is Ruby 2.1.
+image, which is Ruby 2.6.
 
 If your SSG needs [NodeJS](https://nodejs.org/) to build, you'll
 need to specify which image you want to use, and this image should
@@ -198,7 +198,7 @@ To do that, we need to add another line to our CI, telling the Runner
 to only perform that _job_ called `pages` on the `master` branch `only`:
 
 ```yaml
-image: ruby:2.3
+image: ruby:2.6
 
 pages:
   script:
@@ -221,7 +221,7 @@ and deploy. To specify which stage your _job_ is running,
 simply add another line to your CI:
 
 ```yaml
-image: ruby:2.3
+image: ruby:2.6
 
 pages:
   stage: deploy
@@ -244,7 +244,7 @@ let's add another task (_job_) to our CI, telling it to
 test every push to other branches, `except` the `master` branch:
 
 ```yaml
-image: ruby:2.3
+image: ruby:2.6
 
 pages:
   stage: deploy
@@ -294,7 +294,7 @@ every single _job_. In our example, notice that we run
 We don't need to repeat it:
 
 ```yaml
-image: ruby:2.3
+image: ruby:2.6
 
 before_script:
   - bundle install
@@ -329,7 +329,7 @@ cache Jekyll dependencies in a `vendor` directory
 when we run `bundle install`:
 
 ```yaml
-image: ruby:2.3
+image: ruby:2.6
 
 cache:
   paths:

doc/user/project/pages/introduction.md

 ---
 type: reference
-last_updated: 2018-06-04
+last_updated: 2020-01-06
 ---
 
 # Exploring GitLab Pages
@@ -156,7 +156,7 @@ Below is a copy of `.gitlab-ci.yml` where the most significant line is the last
 one, specifying to execute everything in the `pages` branch:
 
 ```
-image: ruby:2.1
+image: ruby:2.6
 
 pages:
   script: