Merge branch 'ce-to-ee-2018-09-10' into 'master'

CE upstream - 2018-09-10 15:21 UTC

Closes omnibus-gitlab#2334

See merge request gitlab-org/gitlab-ee!7306

GITLAB_SHELL_VERSION

-8.3.0
+8.3.1

changelogs/unreleased/21371-avatar-fix.yml

+---
+title: "Vertically centres landscape avatars."
+merge_request: 21371
+author: Vicary Archangel
+type: fixed

doc/api/jobs.md

@@ -33,7 +33,9 @@ Example of response
     },
     "coverage": null,
     "created_at": "2015-12-24T15:51:21.727Z",
+    "started_at": "2015-12-24T17:54:24.729Z",
     "finished_at": "2015-12-24T17:54:24.921Z",
+    "duration": 0.192,
     "artifacts_expire_at": "2016-01-23T17:54:24.921Z",
     "id": 6,
     "name": "rspec:other",
@@ -47,7 +49,6 @@ Example of response
     "artifacts": [],
     "runner": null,
     "stage": "test",
-    "started_at": "2015-12-24T17:54:24.729Z",
     "status": "failed",
     "tag": false,
     "web_url": "https://example.com/foo/bar/-/jobs/6",
@@ -78,6 +79,9 @@ Example of response
     },
     "coverage": null,
     "created_at": "2015-12-24T15:51:21.802Z",
+    "started_at": "2015-12-24T17:54:27.722Z",
+    "finished_at": "2015-12-24T17:54:27.895Z",
+    "duration": 0.173,
     "artifacts_file": {
       "filename": "artifacts.zip",
       "size": 1000
@@ -88,7 +92,6 @@ Example of response
       {"file_type": "trace", "size": 1500, "filename": "job.log", "file_format": "raw"},
       {"file_type": "junit", "size": 750, "filename": "junit.xml.gz", "file_format": "gzip"}
     ],
-    "finished_at": "2015-12-24T17:54:27.895Z",
     "artifacts_expire_at": "2016-01-23T17:54:27.895Z",
     "id": 7,
     "name": "teaspoon",
@@ -102,7 +105,6 @@ Example of response
     "artifacts": [],
     "runner": null,
     "stage": "test",
-    "started_at": "2015-12-24T17:54:27.722Z",
     "status": "failed",
     "tag": false,
     "web_url": "https://example.com/foo/bar/-/jobs/7",
@@ -158,7 +160,9 @@ Example of response
     },
     "coverage": null,
     "created_at": "2015-12-24T15:51:21.727Z",
+    "started_at": "2015-12-24T17:54:24.729Z",
     "finished_at": "2015-12-24T17:54:24.921Z",
+    "duration": 0.192,
     "artifacts_expire_at": "2016-01-23T17:54:24.921Z",
     "id": 6,
     "name": "rspec:other",
@@ -172,7 +176,6 @@ Example of response
     "artifacts": [],
     "runner": null,
     "stage": "test",
-    "started_at": "2015-12-24T17:54:24.729Z",
     "status": "failed",
     "tag": false,
     "web_url": "https://example.com/foo/bar/-/jobs/6",
@@ -203,6 +206,9 @@ Example of response
     },
     "coverage": null,
     "created_at": "2015-12-24T15:51:21.802Z",
+    "started_at": "2015-12-24T17:54:27.722Z",
+    "finished_at": "2015-12-24T17:54:27.895Z",
+    "duration": 0.173,
     "artifacts_file": {
       "filename": "artifacts.zip",
       "size": 1000
@@ -213,7 +219,6 @@ Example of response
       {"file_type": "trace", "size": 1500, "filename": "job.log", "file_format": "raw"},
       {"file_type": "junit", "size": 750, "filename": "junit.xml.gz", "file_format": "gzip"}
     ],
-    "finished_at": "2015-12-24T17:54:27.895Z",
     "artifacts_expire_at": "2016-01-23T17:54:27.895Z",
     "id": 7,
     "name": "teaspoon",
@@ -227,7 +232,6 @@ Example of response
     "artifacts": [],
     "runner": null,
     "stage": "test",
-    "started_at": "2015-12-24T17:54:27.722Z",
     "status": "failed",
     "tag": false,
     "web_url": "https://example.com/foo/bar/-/jobs/7",
@@ -281,7 +285,9 @@ Example of response
   },
   "coverage": null,
   "created_at": "2015-12-24T15:51:21.880Z",
+  "started_at": "2015-12-24T17:54:30.733Z",
   "finished_at": "2015-12-24T17:54:31.198Z",
+  "duration": 0.465,
   "artifacts_expire_at": "2016-01-23T17:54:31.198Z",
   "id": 8,
   "name": "rubocop",
@@ -295,7 +301,6 @@ Example of response
   "artifacts": [],
   "runner": null,
   "stage": "test",
-  "started_at": "2015-12-24T17:54:30.733Z",
   "status": "failed",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/8",
@@ -319,6 +324,7 @@ Example of response
 ## Get job artifacts
 
 > **Notes**:
+>
 > - [Introduced][ce-2893] in GitLab 8.5.
 > - The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346]
 >   in [GitLab Premium][ee] 9.5.
@@ -367,6 +373,7 @@ Response:
 ## Download the artifacts archive
 
 > **Notes**:
+>
 > - [Introduced][ce-5347] in GitLab 8.10.
 > - The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346]
 >   in [GitLab Premium][ee] 9.5.
@@ -506,14 +513,15 @@ Example of response
   },
   "coverage": null,
   "created_at": "2016-01-11T10:13:33.506Z",
-  "finished_at": "2016-01-11T10:14:09.526Z",
+  "started_at": "2016-01-11T10:14:09.526Z",
+  "finished_at": null,
+  "duration": 8,
   "id": 42,
   "name": "rubocop",
   "ref": "master",
   "artifacts": [],
   "runner": null,
   "stage": "test",
-  "started_at": null,
   "status": "canceled",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/42",
@@ -553,14 +561,15 @@ Example of response
   },
   "coverage": null,
   "created_at": "2016-01-11T10:13:33.506Z",
+  "started_at": null,
   "finished_at": null,
+  "duration": null,
   "id": 42,
   "name": "rubocop",
   "ref": "master",
   "artifacts": [],
   "runner": null,
   "stage": "test",
-  "started_at": null,
   "status": "pending",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/42",
@@ -613,6 +622,7 @@ Example of response
   "created_at": "2016-01-11T10:13:33.506Z",
   "started_at": "2016-01-11T10:13:33.506Z",
   "finished_at": "2016-01-11T10:15:10.506Z",
+  "duration": 97.0,
   "status": "failed",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/42",
@@ -665,6 +675,7 @@ Example response:
   "created_at": "2016-01-11T10:13:33.506Z",
   "started_at": "2016-01-11T10:13:33.506Z",
   "finished_at": "2016-01-11T10:15:10.506Z",
+  "duration": 97.0,
   "status": "failed",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/42",
@@ -704,14 +715,15 @@ Example of response
   },
   "coverage": null,
   "created_at": "2016-01-11T10:13:33.506Z",
+  "started_at": null,
   "finished_at": null,
+  "duration": null,
   "id": 42,
   "name": "rubocop",
   "ref": "master",
   "artifacts": [],
   "runner": null,
   "stage": "test",
-  "started_at": null,
   "status": "started",
   "tag": false,
   "web_url": "https://example.com/foo/bar/-/jobs/42",

doc/ci/caching/index.md

@@ -24,14 +24,14 @@ Don't mix the caching with passing artifacts between stages. Caching is not
 designed to pass artifacts between stages. Cache is for runtime dependencies
 needed to compile the project:
 
-- `cache` - **Use for temporary storage for project dependencies.** Not useful
+- `cache`: **Use for temporary storage for project dependencies.** Not useful
   for keeping intermediate build results, like `jar` or `apk` files.
   Cache was designed to be used to speed up invocations of subsequent runs of a
   given job, by keeping things like dependencies (e.g., npm packages, Go vendor
   packages, etc.) so they don't have to be re-fetched from the public internet.
   While the cache can be abused to pass intermediate build results between stages,
   there may be cases where artifacts are a better fit.
-- `artifacts` - **Use for stage results that will be passed between stages.**
+- `artifacts`: **Use for stage results that will be passed between stages.**
   Artifacts were designed to upload some compiled/generated bits of the build,
   and they can be fetched by any number of concurrent Runners. They are
   guaranteed to be available and are there to pass data between jobs. They are
@@ -57,19 +57,20 @@ control exactly where artifacts are passed around.
 
 In summary:
 
-- Caches are disabled if not defined globally or per job (using `cache:`)
-- Caches are available for all jobs in your `.gitlab-ci.yml` if enabled globally
+- Caches are disabled if not defined globally or per job (using `cache:`).
+- Caches are available for all jobs in your `.gitlab-ci.yml` if enabled globally.
 - Caches can be used by subsequent pipelines of that very same job (a script in
   a stage) in which the cache was created (if not defined globally).
 - Caches are stored where the Runner is installed **and** uploaded to S3 if
-  [distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching)
-- Caches defined per job are only used either a) for the next pipeline of that job,
-  or b) if that same cache is also defined in a subsequent job of the same pipeline
-- Artifacts are disabled if not defined per job (using `artifacts:`)
-- Artifacts can only be enabled per job, not globally
+  [distributed cache is enabled](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching).
+- Caches defined per job are only used, either:
+  - For the next pipeline of that job.
+  - If that same cache is also defined in a subsequent job of the same pipeline.
+- Artifacts are disabled if not defined per job (using `artifacts:`).
+- Artifacts can only be enabled per job, not globally.
 - Artifacts are created during a pipeline and can be used by the subsequent
-  jobs of that currently active pipeline
-- Artifacts are always uploaded to GitLab (known as coordinator)
+  jobs of that currently active pipeline.
+- Artifacts are always uploaded to GitLab (known as coordinator).
 - Artifacts can have an expiration value for controlling disk usage (30 days by default).
 
 ## Good caching practices
@@ -97,13 +98,13 @@ or pipelines in a guaranteed manner.
 From the perspective of the Runner, in order for cache to work effectively, one
 of the following must be true:
 
-- Use a single Runner for all your jobs
-- Use multiple Runners (in autoscale mode or not) that use
+- Use a single Runner for all your jobs.
+- Use multiple Runners (in autoscale mode or not) that use.
   [distributed caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching),
-  where the cache is stored in S3 buckets (like shared Runners on GitLab.com)
+  where the cache is stored in S3 buckets (like shared Runners on GitLab.com).
 - Use multiple Runners (not in autoscale mode) of the same architecture that
   share a common network-mounted directory (using NFS or something similar)
-  where the cache will be stored
+  where the cache will be stored.
 
 TIP: **Tip:**
 Read about the [availability of the cache](#availability-of-the-cache)
@@ -367,19 +368,19 @@ job B:
 
 Here's what happens behind the scenes:
 
-1. Pipeline starts
-1. `job A` runs
-1. `before_script` is executed
-1. `script` is executed
-1. `after_script` is executed
+1. Pipeline starts.
+1. `job A` runs.
+1. `before_script` is executed.
+1. `script` is executed.
+1. `after_script` is executed.
 1. `cache` runs and the `vendor/` directory is zipped into `cache.zip`.
     This file is then saved in the directory based on the
     [Runner's setting](#where-the-caches-are-stored) and the `cache: key`.
-1. `job B` runs
-1. The cache is extracted (if found)
-1. `before_script` is executed
-1. `script` is executed
-1. Pipeline finishes
+1. `job B` runs.
+1. The cache is extracted (if found).
+1. `before_script` is executed.
+1. `script` is executed.
+1. Pipeline finishes.
 
 By using a single Runner on a single machine, you'll not have the issue where
 `job B` might execute on a Runner different from `job A`, thus guaranteeing the
@@ -451,13 +452,13 @@ job B:
     - vendor/
 ```
 
-1. `job A` runs
-1. `public/` is cached as cache.zip
-1. `job B` runs
-1. The previous cache, if any, is unzipped
-1. `vendor/` is cached as cache.zip and overwrites the previous one
+1. `job A` runs.
+1. `public/` is cached as cache.zip.
+1. `job B` runs.
+1. The previous cache, if any, is unzipped.
+1. `vendor/` is cached as cache.zip and overwrites the previous one.
 1. The next time `job A` runs it will use the cache of `job B` which is different
-   and thus will be ineffective
+   and thus will be ineffective.
 
 To fix that, use different `keys` for each job.
 
@@ -514,12 +515,12 @@ next run of the pipeline, the cache will be stored in a different location.
 If you want to avoid editing `.gitlab-ci.yml`, you can easily clear the cache
 via GitLab's UI:
 
-1. Navigate to your project's **CI/CD > Pipelines** page
-1. Click on the **Clear Runner caches** button to clean up the cache
+1. Navigate to your project's **CI/CD > Pipelines** page.
+1. Click on the **Clear Runner caches** button to clean up the cache.
 
     ![Clear Runners cache](img/clear_runners_cache.png)
 
-1. On the next push, your CI/CD job will use a new cache
+1. On the next push, your CI/CD job will use a new cache.
 
 Behind the scenes, this works by increasing a counter in the database, and the
 value of that counter is used to create the key for the cache by appending an

doc/ci/docker/using_docker_build.md

@@ -151,16 +151,16 @@ In order to do that, follow the steps:
       DOCKER_DRIVER: overlay2
 
     services:
-    - docker:dind
+      - docker:dind
 
     before_script:
-    - docker info
+      - docker info
 
     build:
       stage: build
       script:
-      - docker build -t my-docker-image .
-      - docker run my-docker-image /script/to/run/tests
+        - docker build -t my-docker-image .
+        - docker run my-docker-image /script/to/run/tests
     ```
 
 Docker-in-Docker works well, and is the recommended configuration, but it is
@@ -246,13 +246,13 @@ In order to do that, follow the steps:
     image: docker:stable
 
     before_script:
-    - docker info
+      - docker info
 
     build:
       stage: build
       script:
-      - docker build -t my-docker-image .
-      - docker run my-docker-image /script/to/run/tests
+        - docker build -t my-docker-image .
+        - docker run my-docker-image /script/to/run/tests
     ```
 
 While the above method avoids using Docker in privileged mode, you should be
@@ -403,7 +403,7 @@ could look like:
  build:
    image: docker:stable
    services:
-   - docker:dind
+     - docker:dind
    variables:
      DOCKER_HOST: tcp://docker:2375
      DOCKER_DRIVER: overlay2
@@ -456,13 +456,13 @@ an application-specific deploy script:
 ```yaml
 image: docker:stable
 services:
-- docker:dind
+  - docker:dind
 
 stages:
-- build
-- test
-- release
-- deploy
+  - build
+  - test
+  - release
+  - deploy
 
 variables:
   DOCKER_HOST: tcp://docker:2375

doc/development/performance.md

@@ -43,7 +43,7 @@ GitLab provides built-in tools to aid the process of improving performance:
 * [QueryRecoder](query_recorder.md) for preventing `N+1` regressions
 
 GitLab employees can use GitLab.com's performance monitoring systems located at
-<http://performance.gitlab.net>, this requires you to log in using your
+<https://dashboards.gitlab.net>, this requires you to log in using your
 `@gitlab.com` Email address. Non-GitLab employees are advised to set up their
 own InfluxDB + Grafana stack.
 

doc/raketasks/backup_restore.md

@@ -16,17 +16,27 @@ and is flexible enough to fit your needs.
 
 ### Requirements
 
-If you're using GitLab with the Omnibus package, you're all set. If you
-installed GitLab from source, make sure the following packages are installed:
-
 * rsync
 
+If you're using GitLab with the Omnibus package, you're all set. If you
+installed GitLab from source, make sure you have rsync installed.
+
 If you're using Ubuntu, you could run:
 
 ```
 sudo apt-get install -y rsync
 ```
 
+* tar
+
+Backup and restore tasks use `tar` under the hood to create and extract
+archives. Ensure you have version 1.30 or above of `tar` available in your
+system. To check the version, run:
+
+```
+tar --version
+```
+
 ### Backup timestamp
 
 >**Note:**

doc/user/gitlab_com/index.md

@@ -99,7 +99,7 @@ Below are the shared Runners settings.
 | Default Docker image                  | `ruby:2.5`                                        | -          |
 | `privileged` (run [Docker in Docker]) | `true`                                            | `false`    |
 
-[ci_version_dashboard]: https://monitor.gitlab.net/dashboard/db/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light
+[ci_version_dashboard]: https://dashboards.gitlab.com/dashboard/db/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light
 
 ### `config.toml`
 

doc/workflow/todos.md

@@ -14,7 +14,7 @@ in a simple dashboard.
 
 ---
 
-You can quickly access the Todos dashboard using the bell icon next to the
+You can quickly access the Todos dashboard using the checkmark icon next to the
 search bar in the upper right corner. The number in blue is the number of Todos
 you still have open if the count is < 100, else it's 99+. The exact number
 will still be shown in the body of the _To do_ tab.