Merge remote-tracking branch 'origin-ee/master' into zj-object-store-artifacts

doc/administration/container_registry.md

 # GitLab Container Registry administration
 
-> [Introduced][ce-4040] in GitLab 8.8.
-
----
-
 > **Notes:**
+- [Introduced][ce-4040] in GitLab 8.8.
 - Container Registry manifest `v1` support was added in GitLab 8.9 to support
   Docker versions earlier than 1.10.
 - This document is about the admin guide. To learn how to use GitLab Container
@@ -514,8 +511,8 @@ configurable in future releases.
 
 ## Configure Container Registry notifications
 
-You can configure the Container Registry to send webhook notifications in 
-response to events happening within the registry.  
+You can configure the Container Registry to send webhook notifications in
+response to events happening within the registry.
 
 Read more about the Container Registry notifications config options in the
 [Docker Registry notifications documentation][notifications-config].
@@ -568,12 +565,25 @@ notifications:
       backoff: 1000
 ```
 
-## Changelog
+## Using self-signed certificates with Container Registry
+
+If you're using a self-signed certificate with your Container Registry, you
+might encounter issues during the CI jobs like the following:
+
+```
+Error response from daemon: Get registry.example.com/v1/users/: x509: certificate signed by unknown authority
+```
 
-**GitLab 8.8 ([source docs][8-8-docs])**
+The Docker daemon running the command expects a cert signed by a recognized CA,
+thus the error above.
 
-- GitLab Container Registry feature was introduced.
+While GitLab doesn't support using self-signed certificates with Container
+Registry out of the box, it is possible to make it work if you follow
+[Docker's documentation][docker-insecure]. You may find some additional
+information in [issue 18239][ce-18239].
 
+[ce-18239]: https://gitlab.com/gitlab-org/gitlab-ce/issues/18239
+[docker-insecure]: https://docs.docker.com/registry/insecure/#using-self-signed-certificates
 [reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure
 [restart gitlab]: restart_gitlab.md#installations-from-source
 [wildcard certificate]: https://en.wikipedia.org/wiki/Wildcard_certificate
@@ -589,4 +599,4 @@ notifications:
 [existing-domain]: #configure-container-registry-under-an-existing-gitlab-domain
 [new-domain]: #configure-container-registry-under-its-own-domain
 [notifications-config]: https://docs.docker.com/registry/notifications/
-[registry-notifications-config]: https://docs.docker.com/registry/configuration/#notifications
+[registry-notifications-config]: https://docs.docker.com/registry/configuration/#notifications
\ No newline at end of file

doc/administration/job_artifacts.md

@@ -118,6 +118,42 @@ Please note, that enabling this feature
 will have the effect that artifacts are _not_ browsable anymore through the web
 interface. This limitation will be removed in one of the upcoming releases.
 
+## Expiring artifacts
+
+If an expiry date is used for the artifacts, they are marked for deletion
+right after that date passes. Artifacts are cleaned up by the
+`expire_build_artifacts_worker` cron job which is run by Sidekiq every hour at
+50 minutes (`50 * * * *`).
+
+To change the default schedule on which the artifacts are expired, follow the
+steps below.
+
+---
+
+**In Omnibus installations:**
+
+1. Edit `/etc/gitlab/gitlab.rb` and comment out or add the following line
+
+    ```ruby
+    gitlab_rails['expire_build_artifacts_worker_cron'] = "50 * * * *"
+    ```
+
+1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+
+---
+
+**In installations from source:**
+
+1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
+   lines:
+
+    ```yaml
+    expire_build_artifacts_worker:
+      cron: "50 * * * *"
+    ```
+
+1. Save the file and [restart GitLab][] for the changes to take effect.
+
 ## Set the maximum file size of the artifacts
 
 Provided the artifacts are enabled, you can change the maximum file size of the

doc/ci/docker/using_docker_images.md

@@ -140,17 +140,58 @@ that runner.
 
 ## Define an image from a private Docker registry
 
-Starting with GitLab Runner 0.6.0, you are able to define images located to
-private registries that could also require authentication.
-
-All you have to do is be explicit on the image definition in `.gitlab-ci.yml`.
-
-```yaml
-image: my.registry.tld:5000/namespace/image:tag
-```
-
-In the example above, GitLab Runner will look at `my.registry.tld:5000` for the
-image `namespace/image:tag`.
+> **Notes:**
+- This feature requires GitLab Runner **1.8** or higher
+- For GitLab Runner versions **>= 0.6, <1.8** there was a partial
+  support for using private registries, which required manual configuration
+  of credentials on runner's host. We recommend to upgrade your Runner to
+  at least version **1.8** if you want to use private registries.
+- If the repository is private you need to authenticate your GitLab Runner in the
+  registry. Learn more about how [GitLab Runner works in this case][runner-priv-reg].
+
+As an example, let's assume that you want to use the `registry.example.com/private/image:latest`
+image which is private and requires you to login into a private container registry.
+To configure access for `registry.example.com`, follow these steps:
+
+1. Do a `docker login` on your computer:
+
+     ```bash
+     docker login registry.example.com --username my_username --password my_password
+     ```
+
+1. Copy the content of `~/.docker/config.json`
+1. Create a [secret variable] `DOCKER_AUTH_CONFIG` with the content of the
+   Docker configuration file as the value:
+
+     ```json
+     {
+         "auths": {
+             "registry.example.com": {
+                 "auth": "bXlfdXNlcm5hbWU6bXlfcGFzc3dvcmQ="
+             }
+         }
+     }
+     ```
+
+1. Do a `docker logout` on your computer if you don't need access to the
+   registry from it:
+
+     ```bash
+     docker logout registry.example.com
+     ```
+
+1. You can now use any private image from `registry.example.com` defined in
+   `image` and/or `services` in your [`.gitlab-ci.yml` file][yaml-priv-reg]:
+
+      ```yaml
+      image: my.registry.tld:5000/namespace/image:tag
+      ```
+
+      In the example above, GitLab Runner will look at `my.registry.tld:5000` for the
+      image `namespace/image:tag`.
+
+You can add configuration for as many registries as you want, adding more
+registries to the `"auths"` hash as described above.
 
 If the repository is private you need to authenticate your GitLab Runner in the
 registry. Learn how to do that on
@@ -283,4 +324,5 @@ creation.
 [tutum/wordpress]: https://hub.docker.com/r/tutum/wordpress/
 [postgres-hub]: https://hub.docker.com/r/_/postgres/
 [mysql-hub]: https://hub.docker.com/r/_/mysql/
-[runner-priv-reg]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#using-a-private-docker-registry
+[runner-priv-reg]: http://docs.gitlab.com/runner/configuration/advanced-configuration.html#using-a-private-container-registry
+[secret variable]: ../variables/README.md#secret-variables

doc/user/project/pipelines/job_artifacts.md

@@ -12,7 +12,7 @@
    to GitLab using GitLab Runner version 1.0 and up. It will not be possible to
    browse old artifacts already uploaded to GitLab.
 >- This is the user documentation. For the administration guide see
-   [administration/job_artifacts.md](../../../administration/job_artifacts.md).
+   [administration/job_artifacts](../../../administration/job_artifacts.md).
 
 Artifacts is a list of files and directories which are attached to a job
 after it completes successfully. This feature is enabled by default in all
@@ -29,25 +29,31 @@ pdf:
   artifacts:
     paths:
     - mycv.pdf
+    expire_in: 1 week
 ```
 
 A job named `pdf` calls the `xelatex` command in order to build a pdf file from
 the latex source file `mycv.tex`. We then define the `artifacts` paths which in
 turn are defined with the `paths` keyword. All paths to files and directories
-are relative to the repository that was cloned during the build.
+are relative to the repository that was cloned during the build. These uploaded
+artifacts will be kept in GitLab for 1 week as defined by the `expire_in`
+definition. You have the option to keep the artifacts from expiring via the
+[web interface](#browsing-job-artifacts). If you don't define an expiry date,
+the artifacts will be kept forever.
 
-For more examples on artifacts, follow the artifacts reference in
-[`.gitlab-ci.yml` documentation](../../../ci/yaml/README.md#artifacts).
+For more examples on artifacts, follow the [artifacts reference in
+`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifacts).
 
 ## Browsing job artifacts
 
 >**Note:**
-With GitLab 9.2, PDFs, images, videos and other formats can be previewed directly
-in the job artifacts browser without the need to download them.
+With GitLab 9.2, PDFs, images, videos and other formats can be previewed
+directly in the job artifacts browser without the need to download them.
 
-After a job finishes, if you visit the job's specific page, you can see
-that there are two buttons. One is for downloading the artifacts archive and
-the other for browsing its contents.
+After a job finishes, if you visit the job's specific page, there are three
+buttons. You can download the artifacts archive or browse its contents, whereas
+the **Keep** button appears only if you have set an [expiry date] to the
+artifacts in case you changed your mind and want to keep them.
 
 ![Job artifacts browser button](img/job_artifacts_browser_button.png)
 
@@ -145,3 +151,5 @@ information in the UI.
 
 ![Latest artifacts button](img/job_latest_artifacts_browser.png)
 
+
+[expiry date]: ../../../ci/yaml/README.md#artifacts-expire_in