Merge branch 'master' into pipeline-ui-updatespipeline-ui-updates

* master: (259 commits)
  Exclude non existent repository storages.
  fixed minor animation glitch in mini pipeline graph animation
  Update Bitbucket callback URL documentation
  Update build step for KaTeX.
  Add KaTeX fonts to assets paths and precompile
  Replace url('...') to url(font-path('...'))
  Rname katex.css to katex.scss
  Revert conflicting EE changes
  Added Autodeploy script for OpenShift
  Whitelist next project names: notes, services
  Put back progress bar CSS
  Remove unneeded bundle refs.
  Adds entry to changelog
  Reduce MR widget title by one pixel
  Use same font size for all items in issue title
  Adds background color for disabled state to merge when succeeds dropdown
  Filter protocol-relative URLs in ExternalLinkFilter. Fixes issue #22742.
  Move javascript for widget check to ci_bundle.
  Introduce "Set up autodeploy" button to help configure GitLab CI for deployment
  Whitelist next project names: help, ci, admin, search
  ...

25 files changed, 398 insertions, 25 deletions

diff --git a/doc/README.md b/doc/README.md
index a60a5359540..ee69684b53b 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -34,6 +34,7 @@
 - [Integration](integration/README.md) How to integrate with systems such as JIRA, Redmine, Twitter.
 - [Issue closing pattern](administration/issue_closing_pattern.md) Customize how to close an issue from commit messages.
 - [Koding](administration/integration/koding.md) Set up Koding to use with GitLab.
+- [Web terminals](administration/integration/terminal.md) Provide terminal access to environments from within GitLab.
 - [Libravatar](customization/libravatar.md) Use Libravatar instead of Gravatar for user avatars.
 - [Log system](administration/logs.md) Log system.
 - [Environment Variables](administration/environment_variables.md) to configure GitLab.
diff --git a/doc/administration/auth/README.md b/doc/administration/auth/README.md
index 2fc5d0355b5..13bd501e397 100644
--- a/doc/administration/auth/README.md
+++ b/doc/administration/auth/README.md
@@ -6,7 +6,7 @@ providers.
 - [LDAP](ldap.md) Includes Active Directory, Apple Open Directory, Open LDAP,
   and 389 Server
 - [OmniAuth](../../integration/omniauth.md) Sign in via Twitter, GitHub, GitLab.com, Google,
-  Bitbucket, Facebook, Shibboleth, Crowd and Azure
+  Bitbucket, Facebook, Shibboleth, Crowd, Azure and Authentiq ID
 - [CAS](../../integration/cas.md) Configure GitLab to sign in using CAS
 - [SAML](../../integration/saml.md) Configure GitLab as a SAML 2.0 Service Provider
 - [Okta](okta.md) Configure GitLab to sign in using Okta
diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md
new file mode 100644
index 00000000000..3f39539da95
--- /dev/null
+++ b/doc/administration/auth/authentiq.md
@@ -0,0 +1,69 @@
+# Authentiq OmniAuth Provider
+
+To enable the Authentiq OmniAuth provider for passwordless authentication you must register an application with Authentiq.
+
+Authentiq will generate a Client ID and the accompanying Client Secret for you to use.
+
+1. Get your Client credentials (Client ID and Client Secret) at [Authentiq](https://www.authentiq.com/register).
+
+2. On your GitLab server, open the configuration file:
+
+    For omnibus installation
+    ```sh
+    sudo editor /etc/gitlab/gitlab.rb
+    ```
+
+    For installations from source:
+
+    ```sh
+    sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
+    ```
+    
+3. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings to enable single sign-on and add Authentiq as an OAuth provider. 
+
+4. Add the provider configuration for Authentiq:
+    
+    For Omnibus packages:
+
+    ```ruby
+    gitlab_rails['omniauth_providers'] = [
+      {
+        "name" => "authentiq",
+        "app_id" => "YOUR_CLIENT_ID",
+        "app_secret" => "YOUR_CLIENT_SECRET",
+        "args" => { 
+               scope: 'aq:name email~rs aq:push'
+         }
+      }
+    ]
+    ```
+    
+    For installations from source:
+    
+    ```yaml
+    - { name: 'authentiq',
+        app_id: 'YOUR_CLIENT_ID',
+        app_secret: 'YOUR_CLIENT_SECRET',
+        args: {
+               scope: 'aq:name email~rs aq:push'
+              }
+      }
+    ```
+    
+    
+5. The `scope` is set to request the user's name, email (required and signed), and permission to send push notifications to sign in on subsequent visits.
+See [OmniAuth Authentiq strategy](https://github.com/AuthentiqID/omniauth-authentiq#scopes-and-redirect-uri-configuration) for more information on scopes and modifiers.
+
+6. Change 'YOUR_CLIENT_ID' and 'YOUR_CLIENT_SECRET' to the Client credentials you received in step 1.
+
+7. Save the configuration file.
+
+8. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source)
+   for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
+
+On the sign in page there should now be an Authentiq icon below the regular sign in form. Click the icon to begin the authentication process. 
+
+- If the user has the Authentiq ID app installed in their iOS or Android device, they can scan the QR code, decide what personal details to share and sign in to your GitLab installation. 
+- If not they will be prompted to download the app and then follow the procedure above. 
+
+If everything goes right, the user will be returned to GitLab and will be signed in.
\ No newline at end of file
diff --git a/doc/administration/high_availability/load_balancer.md b/doc/administration/high_availability/load_balancer.md
index 136f570ac27..1824829903c 100644
--- a/doc/administration/high_availability/load_balancer.md
+++ b/doc/administration/high_availability/load_balancer.md
@@ -10,11 +10,11 @@ you need to use with GitLab.
 
 ## Basic ports
 
-| LB Port | Backend Port | Protocol   |
-| ------- | ------------ | --------   |
-| 80      | 80           | HTTP       |
-| 443     | 443          | HTTPS [^1] |
-| 22      | 22           | TCP        |
+| LB Port | Backend Port | Protocol        |
+| ------- | ------------ | --------------- |
+| 80      | 80           | HTTP  [^1]      |
+| 443     | 443          | HTTPS [^1] [^2] |
+| 22      | 22           | TCP             |
 
 ## GitLab Pages Ports
 
@@ -25,8 +25,8 @@ GitLab Pages requires a separate VIP. Configure DNS to point the
 
 | LB Port | Backend Port | Protocol |
 | ------- | ------------ | -------- |
-| 80      | Varies [^2]  | HTTP     |
-| 443     | Varies [^2]  | TCP [^3] |
+| 80      | Varies [^3]  | HTTP     |
+| 443     | Varies [^3]  | TCP [^4] |
 
 ## Alternate SSH Port
 
@@ -50,13 +50,19 @@ Read more on high-availability configuration:
 1. [Configure NFS](nfs.md)
 1. [Configure the GitLab application servers](gitlab.md)
 
-[^1]: When using HTTPS protocol for port 443, you will need to add an SSL
+[^1]: [Web terminal](../../ci/environments.md#web-terminals) support requires
+      your load balancer to correctly handle WebSocket connections. When using
+      HTTP or HTTPS proxying, this means your load balancer must be configured
+      to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the
+      [web terminal](../integration/terminal.md) integration guide for
+      more details.
+[^2]: When using HTTPS protocol for port 443, you will need to add an SSL
       certificate to the load balancers. If you wish to terminate SSL at the
       GitLab application server instead, use TCP protocol.
-[^2]: The backend port for GitLab Pages depends on the
+[^3]: The backend port for GitLab Pages depends on the
       `gitlab_pages['external_http']` and `gitlab_pages['external_https']`
       setting. See [GitLab Pages documentation][gitlab-pages] for more details.
-[^3]: Port 443 for GitLab Pages should always use the TCP protocol. Users can
+[^4]: Port 443 for GitLab Pages should always use the TCP protocol. Users can
       configure custom domains with custom SSL, which would not be possible
       if SSL was terminated at the load balancer.
 
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
new file mode 100644
index 00000000000..a1d1bb03b50
--- /dev/null
+++ b/doc/administration/integration/terminal.md
@@ -0,0 +1,73 @@
+# Web terminals
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
+in GitLab 8.15. Only project masters and owners can access web terminals.
+
+With the introduction of the [Kubernetes](../../project_services/kubernetes.md)
+project service, GitLab gained the ability to store and use credentials for a
+Kubernetes cluster. One of the things it uses these credentials for is providing
+access to [web terminals](../../ci/environments.html#web-terminals)
+for environments.
+
+## How it works
+
+A detailed overview of the architecture of web terminals and how they work
+can be found in [this document](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/doc/terminal.md).
+In brief:
+
+* GitLab relies on the user to provide their own Kubernetes credentials, and to
+  appropriately label the pods they create when deploying.
+* When a user navigates to the terminal page for an environment, they are served
+  a JavaScript application that opens a WebSocket connection back to GitLab.
+* The WebSocket is handled in [Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
+   rather than the Rails application server.
+* Workhorse queries Rails for connection details and user permissions; Rails
+  queries Kubernetes for them in the background, using [Sidekiq](../troubleshooting/sidekiq.md)
+* Workhorse acts as a proxy server between the user's browser and the Kubernetes
+  API, passing WebSocket frames between the two.
+* Workhorse regularly polls Rails, terminating the WebSocket connection if the
+  user no longer has permission to access the terminal, or if the connection
+  details have changed.
+
+##  Enabling and disabling terminal support
+
+As web terminals use WebSockets, every HTTP/HTTPS reverse proxy in front of
+Workhorse needs to be configured to pass the `Connection` and `Upgrade` headers
+through to the next one in the chain. If you installed Gitlab using Omnibus, or
+from source, starting with GitLab 8.15, this should be done by the default
+configuration, so there's no need for you to do anything.
+
+However, if you run a [load balancer](../high_availability/load_balancer.md) in
+front of GitLab, you may need to make some changes to your configuration. These
+guides document the necessary steps for a selection of popular reverse proxies:
+
+* [Apache](https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html)
+* [NGINX](https://www.nginx.com/blog/websocket-nginx/)
+* [HAProxy](http://blog.haproxy.com/2012/11/07/websockets-load-balancing-with-haproxy/)
+* [Varnish](https://www.varnish-cache.org/docs/4.1/users-guide/vcl-example-websockets.html)
+
+Workhorse won't let WebSocket requests through to non-WebSocket endpoints, so
+it's safe to enable support for these headers globally. If you'd rather had a
+narrower set of rules, you can restrict it to URLs ending with `/terminal.ws`
+(although this may still have a few false positives).
+
+If you installed from source, or have made any configuration changes to your
+Omnibus installation before upgrading to 8.15, you may need to make some
+changes to your configuration. See the  [8.14 to 8.15 upgrade](../../update/8.14-to-8.15.md#nginx-configuration)
+document for more details.
+
+If you'd like to disable web terminal support in GitLab, just stop passing
+the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
+proxy in the chain. For most users, this will be the NGINX server bundled with
+Omnibus Gitlab, in which case, you need to:
+
+* Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
+* Ensure the whole block is uncommented, and then comment out or remove the
+  `Connection` and `Upgrade` lines.
+
+For your own load balancer, just reverse the configuration changes recommended
+by the above guides.
+
+When these headers are not passed through, Workhorse will return a
+`400 Bad Request` response to users attempting to use a web terminal. In turn,
+they will receive a `Connection failed` message.
diff --git a/doc/api/repositories.md b/doc/api/repositories.md
index bcf8b955044..727617f1ecc 100644
--- a/doc/api/repositories.md
+++ b/doc/api/repositories.md
@@ -2,7 +2,8 @@
 
 ## List repository tree
 
-Get a list of repository files and directories in a project.
+Get a list of repository files and directories in a project. This endpoint can
+be accessed without authentication if the repository is publicly accessible.
 
 ```
 GET /projects/:id/repository/tree
@@ -71,7 +72,8 @@ Parameters:
 
 ## Raw file content
 
-Get the raw file contents for a file by commit SHA and path.
+Get the raw file contents for a file by commit SHA and path. This endpoint can
+be accessed without authentication if the repository is publicly accessible.
 
 ```
 GET /projects/:id/repository/blobs/:sha
@@ -85,7 +87,8 @@ Parameters:
 
 ## Raw blob content
 
-Get the raw file contents for a blob by blob SHA.
+Get the raw file contents for a blob by blob SHA. This endpoint can be accessed
+without authentication if the repository is publicly accessible.
 
 ```
 GET /projects/:id/repository/raw_blobs/:sha
@@ -98,7 +101,8 @@ Parameters:
 
 ## Get file archive
 
-Get an archive of the repository
+Get an archive of the repository. This endpoint can be accessed without
+authentication if the repository is publicly accessible.
 
 ```
 GET /projects/:id/repository/archive
@@ -111,6 +115,9 @@ Parameters:
 
 ## Compare branches, tags or commits
 
+This endpoint can be accessed without authentication if the repository is
+publicly accessible.
+
 ```
 GET /projects/:id/repository/compare
 ```
@@ -163,7 +170,8 @@ Response:
 
 ## Contributors
 
-Get repository contributors list
+Get repository contributors list. This endpoint can be accessed without
+authentication if the repository is publicly accessible.
 
 ```
 GET /projects/:id/repository/contributors
diff --git a/doc/api/repository_files.md b/doc/api/repository_files.md
index b8c9eb2c9a8..8a6baed5987 100644
--- a/doc/api/repository_files.md
+++ b/doc/api/repository_files.md
@@ -6,7 +6,9 @@
 
 ## Get file from repository
 
-Allows you to receive information about file in repository like name, size, content. Note that file content is Base64 encoded.
+Allows you to receive information about file in repository like name, size,
+content. Note that file content is Base64 encoded. This endpoint can be accessed
+without authentication if the repository is publicly accessible.
 
 ```
 GET /projects/:id/repository/files
diff --git a/doc/ci/README.md b/doc/ci/README.md
index 73bd2516d46..6a9495f8892 100644
--- a/doc/ci/README.md
+++ b/doc/ci/README.md
@@ -23,6 +23,7 @@
 - [CI/CD pipelines settings](../user/project/pipelines/settings.md)
 - [Review Apps](review_apps/index.md)
 - [Git submodules](git_submodules.md) Using Git submodules in your CI jobs
+- [Autodeploy](autodeploy/index.md)
 
 ## Breaking changes
 
diff --git a/doc/ci/autodeploy/img/autodeploy_button.png b/doc/ci/autodeploy/img/autodeploy_button.png
new file mode 100644
index 00000000000..9e2cd57a0ba
--- /dev/null
+++ b/doc/ci/autodeploy/img/autodeploy_button.png
diff --git a/doc/ci/autodeploy/img/autodeploy_dropdown.png b/doc/ci/autodeploy/img/autodeploy_dropdown.png
new file mode 100644
index 00000000000..1486a8ec0ea
--- /dev/null
+++ b/doc/ci/autodeploy/img/autodeploy_dropdown.png
diff --git a/doc/ci/autodeploy/index.md b/doc/ci/autodeploy/index.md
new file mode 100644
index 00000000000..503a00969d5
--- /dev/null
+++ b/doc/ci/autodeploy/index.md
@@ -0,0 +1,39 @@
+# Autodeploy
+
+> [Introduced][mr-8135] in GitLab 8.15.
+
+Autodeploy is an easy way to configure GitLab CI for the deployment of your
+application. GitLab Community maintains a list of `.gitlab-ci.yml`
+templates for various infrastructure providers and deployment scripts
+powering them. These scripts are responsible for packaging your application,
+setting up the infrastructure and spinning up necessary services (for
+example a database).
+
+You can use [project services][project-services] to store credentials to
+your infrastructure provider and they will be available during the
+deployment.
+
+## Supported templates
+
+The list of supported autodeploy templates is available [here][autodeploy-templates].
+
+## Configuration
+
+1. Enable a deployment [project service][project-services] to store your
+credentials. For example, if you want to deploy to a Kubernetes cluster
+you have to enable [Kubernetes service][kubernetes-service].
+1. Configure GitLab Runner to use [docker-in-docker executor][docker-in-docker].
+1. Navigate to the "Project" tab and click "Set up autodeploy" button.
+   ![Autodeploy button](img/autodeploy_button.png)
+1. Select a template.
+  ![Dropdown with autodeploy templates](img/autodeploy_dropdown.png)
+1. Commit your changes and create a merge request.
+1. Test your deployment configuration using a [Review App][review-app] that was
+created automatically for you.
+
+[mr-8135]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8135
+[project-services]: ../../project_services/project_services.md
+[autodeploy-templates]: https://gitlab.com/gitlab-org/gitlab-ci-yml/tree/master/autodeploy
+[kubernetes-service]: ../../project_services/kubernetes.md
+[docker-in-docker]: ../docker/using_docker_build.md#use-docker-in-docker-executor
+[review-app]: ../review_apps/index.md
diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index bad0233a9ce..98cd29c9567 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -25,7 +25,9 @@ Environments are like tags for your CI jobs, describing where code gets deployed
 Deployments are created when [jobs] deploy versions of code to environments,
 so every environment can have one or more deployments. GitLab keeps track of
 your deployments, so you always know what is currently being deployed on your
-servers.
+servers. If you have a deployment service such as [Kubernetes][kubernetes-service]
+enabled for your project, you can use it to assist with your deployments, and
+can even access a web terminal for your environment from within GitLab!
 
 To better understand how environments and deployments work, let's consider an
 example. We assume that you have already created a project in GitLab and set up
@@ -233,6 +235,46 @@ Remember that if your environment's name is `production` (all lowercase), then
 it will get recorded in [Cycle Analytics](../user/project/cycle_analytics.md).
 Double the benefit!
 
+## Web terminals
+
+>**Note:**
+Web terminals were added in GitLab 8.15 and are only available to project
+masters and owners.
+
+If you deploy to your environments with the help of a deployment service (e.g.,
+the [Kubernetes](../project_services/kubernetes.md) service), GitLab can open
+a terminal session to your environment! This is a very powerful feature that
+allows you to debug issues without leaving the comfort of your web browser. To
+enable it, just follow the instructions given in the service documentation.
+
+Once enabled, your environments will gain a "terminal" button:
+
+![Terminal button on environment index](img/environments_terminal_button_on_index.png)
+
+You can also access the terminal button from the page for a specific environment:
+
+![Terminal button for an environment](img/environments_terminal_button_on_show.png)
+
+Wherever you find it, clicking the button will take you to a separate page to
+establish the terminal session:
+
+![Terminal page](img/environments_terminal_page.png)
+
+This works just like any other terminal - you'll be in the container created
+by your deployment, so you can run shell commands and get responses in real
+time, check the logs, try out configuration or code tweaks, etc. You can open
+multiple terminals to the same environment - they each get their own shell
+session -  and even a multiplexer like `screen` or `tmux`!  
+
+>**Note:**
+Container-based deployments often lack basic tools (like an editor), and may
+be stopped or restarted at any time. If this happens, you will lose all your
+changes! Treat this as a debugging tool, not a comprehensive online IDE. You
+can use [Koding](../administration/integration/koding.md) for online
+development.
+
+---
+
 While this is fine for deploying to some stable environments like staging or
 production, what happens for branches? So far we haven't defined anything
 regarding deployments for branches other than `master`. Dynamic environments
@@ -524,6 +566,7 @@ Below are some links you may find interesting:
 [Pipelines]: pipelines.md
 [jobs]: yaml/README.md#jobs
 [yaml]: yaml/README.md
+[kubernetes-service]: ../project_services/kubernetes.md]
 [environments]: #environments
 [deployments]: #deployments
 [permissions]: ../user/permissions.md
diff --git a/doc/ci/img/environments_terminal_button_on_index.png b/doc/ci/img/environments_terminal_button_on_index.png
new file mode 100644
index 00000000000..6f05b2aa343
--- /dev/null
+++ b/doc/ci/img/environments_terminal_button_on_index.png
diff --git a/doc/ci/img/environments_terminal_button_on_show.png b/doc/ci/img/environments_terminal_button_on_show.png
new file mode 100644
index 00000000000..9469fab99ab
--- /dev/null
+++ b/doc/ci/img/environments_terminal_button_on_show.png
diff --git a/doc/ci/img/environments_terminal_page.png b/doc/ci/img/environments_terminal_page.png
new file mode 100644
index 00000000000..fde1bf325a6
--- /dev/null
+++ b/doc/ci/img/environments_terminal_page.png
diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md
index 03b9c4bb444..f91b9d350f7 100644
--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
@@ -36,6 +36,37 @@ Clicking on a pipeline will show the builds that were run for that pipeline.
 Clicking on an individual build will show you its build trace, and allow you to
 cancel the build, retry it,  or erase the build trace.
 
+## How the pipeline duration is calculated
+
+Total running time for a given pipeline would exclude retries and pending
+(queue) time. We could reduce this problem down to finding the union of
+periods.
+
+So each job would be represented as a `Period`, which consists of
+`Period#first` as when the job started and `Period#last` as when the
+job was finished. A simple example here would be:
+
+* A (1, 3)
+* B (2, 4)
+* C (6, 7)
+
+Here A begins from 1, and ends to 3. B begins from 2, and ends to 4.
+C begins from 6, and ends to 7. Visually it could be viewed as:
+
+```
+0  1  2  3  4  5  6  7
+   AAAAAAA
+      BBBBBBB
+                  CCCC
+```
+
+The union of A, B, and C would be (1, 4) and (6, 7), therefore the
+total running time should be:
+
+```
+(4 - 1) + (7 - 6) => 4
+```
+
 ## Badges
 
 Build status and test coverage report badges are available. You can find their
diff --git a/doc/integration/README.md b/doc/integration/README.md
index f8ffa6dcb7f..ed843c0bfa9 100644
--- a/doc/integration/README.md
+++ b/doc/integration/README.md
@@ -8,7 +8,7 @@ See the documentation below for details on how to configure these services.
 - [JIRA](../project_services/jira.md) Integrate with the JIRA issue tracker
 - [External issue tracker](external-issue-tracker.md) Redmine, JIRA, etc.
 - [LDAP](ldap.md) Set up sign in via LDAP
-- [OmniAuth](omniauth.md) Sign in via Twitter, GitHub, GitLab.com, Google, Bitbucket, Facebook, Shibboleth, SAML, Crowd and Azure
+- [OmniAuth](omniauth.md) Sign in via Twitter, GitHub, GitLab.com, Google, Bitbucket, Facebook, Shibboleth, SAML, Crowd, Azure and Authentiq ID
 - [SAML](saml.md) Configure GitLab as a SAML 2.0 Service Provider
 - [CAS](cas.md) Configure GitLab to sign in using CAS
 - [OAuth2 provider](oauth_provider.md) OAuth2 application creation
diff --git a/doc/integration/bitbucket.md b/doc/integration/bitbucket.md
index 1dfc985eaea..2a14c0397ca 100644
--- a/doc/integration/bitbucket.md
+++ b/doc/integration/bitbucket.md
@@ -40,9 +40,13 @@ you to use.
     | :--- | :---------- |
     | **Name** | This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive. |
     | **Application description** | Fill this in if you wish. |
-    | **Callback URL** | Leave blank. |
+    | **Callback URL** | The URL to your GitLab installation, e.g., `https://gitlab.example.com`. |
     | **URL** | The URL to your GitLab installation, e.g., `https://gitlab.example.com`. |
 
+    NOTE: Starting in GitLab 8.15, you MUST specify a callback URL, or you will
+    see an "Invalid redirect_uri" message. For more details, see [the
+    Bitbucket documentation](https://confluence.atlassian.com/bitbucket/oauth-faq-338365710.html).
+
     And grant at least the following permissions:
 
     ```
diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md
index 8a55fce96fe..4c933cef9b7 100644
--- a/doc/integration/omniauth.md
+++ b/doc/integration/omniauth.md
@@ -30,6 +30,7 @@ contains some settings that are common for all providers.
 - [Crowd](crowd.md)
 - [Azure](azure.md)
 - [Auth0](auth0.md)
+- [Authentiq](../administration/auth/authentiq.md)
 
 ## Initial OmniAuth Configuration
 
diff --git a/doc/project_services/kubernetes.md b/doc/project_services/kubernetes.md
index fda364b864e..59d5da702f8 100644
--- a/doc/project_services/kubernetes.md
+++ b/doc/project_services/kubernetes.md
@@ -47,3 +47,17 @@ GitLab CI build environment:
 - `KUBE_TOKEN`
 - `KUBE_NAMESPACE`
 - `KUBE_CA_PEM` - only if a custom CA bundle was specified
+
+## Web terminals
+
+>**NOTE:**
+Added in GitLab 8.15. You must be the project owner or have `master` permissions
+to use terminals. Support is currently limited to the first container in the
+first pod of your environment.
+
+When enabled, the Kubernetes service adds [web terminal](../ci/environments.md#web-terminals)
+support to your environments. This is based on the `exec` functionality found in
+Docker and Kubernetes, so you get a new shell session within your existing
+containers. To use this integration, you should deploy to Kubernetes using
+the deployment variables above, ensuring any pods you create are labelled with
+`app=$CI_ENVIRONMENT_SLUG`. GitLab will do the rest!
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 39fe2409a29..5ada8748d85 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -33,6 +33,7 @@ The following table depicts the various user permission levels in a project.
 | See a container registry              |         | ✓          | ✓           | ✓        | ✓      |
 | See environments                      |         | ✓          | ✓           | ✓        | ✓      |
 | Create new environments               |         |            | ✓           | ✓        | ✓      |
+| Use environment terminals             |         |            |             | ✓        | ✓      |
 | Stop environments                     |         |            | ✓           | ✓        | ✓      |
 | See a list of merge requests          |         | ✓          | ✓           | ✓        | ✓      |
 | Manage/Accept merge requests          |         |            | ✓           | ✓        | ✓      |
diff --git a/doc/workflow/importing/README.md b/doc/workflow/importing/README.md
index 18e5d950866..2d91bee0e94 100644
--- a/doc/workflow/importing/README.md
+++ b/doc/workflow/importing/README.md
@@ -4,6 +4,7 @@
 1. [GitHub](import_projects_from_github.md)

 1. [GitLab.com](import_projects_from_gitlab_com.md)

 1. [FogBugz](import_projects_from_fogbugz.md)

+1. [Gitea](import_projects_from_gitea.md)

 1. [SVN](migrating_from_svn.md)

 

 In addition to the specific migration documentation above, you can import any

@@ -14,4 +15,3 @@ repository is too large the import can timeout.
 

 You can copy your repos by changing the remote and pushing to the new server;

 but issues and merge requests can't be imported.

-

diff --git a/doc/workflow/importing/img/import_projects_from_gitea_new_import.png b/doc/workflow/importing/img/import_projects_from_gitea_new_import.png
new file mode 100644
index 00000000000..a3f603cbd0a
--- /dev/null
+++ b/doc/workflow/importing/img/import_projects_from_gitea_new_import.png
diff --git a/doc/workflow/importing/import_projects_from_gitea.md b/doc/workflow/importing/import_projects_from_gitea.md
new file mode 100644
index 00000000000..936cee89f45
--- /dev/null
+++ b/doc/workflow/importing/import_projects_from_gitea.md
@@ -0,0 +1,80 @@
+# Import your project from Gitea to GitLab
+
+Import your projects from Gitea to GitLab with minimal effort.
+
+## Overview
+
+>**Note:**
+As of Gitea `v1.0.0`, issue & pull-request comments cannot be imported! This is
+a [known issue][issue-401] that should be fixed in a near-future.
+
+- At its current state, Gitea importer can import:
+  - the repository description (GitLab 8.15+)
+  - the Git repository data (GitLab 8.15+)
+  - the issues (GitLab 8.15+)
+  - the pull requests (GitLab 8.15+)
+  - the milestones (GitLab 8.15+)
+  - the labels (GitLab 8.15+)
+- Repository public access is retained. If a repository is private in Gitea
+  it will be created as private in GitLab as well.
+
+## How it works
+
+Since Gitea is currently not an OAuth provider, author/assignee cannot be mapped
+to users in your GitLab's instance. This means that the project creator (most of
+the times the current user that started the import process) is set as the author,
+but a reference on the issue about the original Gitea author is kept.
+
+The importer will create any new namespaces (groups) if they don't exist or in
+the case the namespace is taken, the repository will be imported under the user's
+namespace that started the import process.
+
+## Importing your Gitea repositories
+
+The importer page is visible when you create a new project.
+
+![New project page on GitLab](img/import_projects_from_new_project_page.png)
+
+Click on the **Gitea** link and the import authorization process will start.
+
+![New Gitea project import](img/import_projects_from_gitea_new_import.png)
+
+### Authorize access to your repositories using a personal access token
+
+With this method, you will perform a one-off authorization with Gitea to grant
+GitLab access your repositories:
+
+1. Go to <https://you-gitea-instance/user/settings/applications> (replace
+   `you-gitea-instance` with the host of your Gitea instance).
+1. Click **Generate New Token**.
+1. Enter a token description.
+1. Click **Generate Token**.
+1. Copy the token hash.
+1. Go back to GitLab and provide the token to the Gitea importer.
+1. Hit the **List Your Gitea Repositories** button and wait while GitLab reads
+   your repositories' information. Once done, you'll be taken to the importer
+   page to select the repositories to import.
+
+### Select which repositories to import
+
+After you've authorized access to your Gitea repositories, you will be
+redirected to the Gitea importer page.
+
+From there, you can see the import statuses of your Gitea repositories.
+
+- Those that are being imported will show a _started_ status,
+- those already successfully imported will be green with a _done_ status,
+- whereas those that are not yet imported will have an **Import** button on the
+  right side of the table.
+
+If you want, you can import all your Gitea projects in one go by hitting
+**Import all projects** in the upper left corner.
+
+![Gitea importer page](img/import_projects_from_github_importer.png)
+
+---
+
+You can also choose a different name for the project and a different namespace,
+if you have the privileges to do so.
+
+[issue-401]: https://github.com/go-gitea/gitea/issues/401
diff --git a/doc/workflow/importing/import_projects_from_github.md b/doc/workflow/importing/import_projects_from_github.md
index b3660aa8030..86a016fc6d6 100644
--- a/doc/workflow/importing/import_projects_from_github.md
+++ b/doc/workflow/importing/import_projects_from_github.md
@@ -6,8 +6,9 @@ Import your projects from GitHub to GitLab with minimal effort.
 

 >**Note:**

 If you are an administrator you can enable the [GitHub integration][gh-import]

-in your GitLab instance sitewide. This configuration is optional, users will be

-able import their GitHub repositories with a [personal access token][gh-token].

+in your GitLab instance sitewide. This configuration is optional, users will

+still be able to import their GitHub repositories with a

+[personal access token][gh-token].

 

 - At its current state, GitHub importer can import:

   - the repository description (GitLab 7.7+)

@@ -85,7 +86,7 @@ authorization with GitHub to grant GitLab access your repositories:
 1. Click **Generate token**.

 1. Copy the token hash.

 1. Go back to GitLab and provide the token to the GitHub importer.

-1. Hit the **List your GitHub repositories** button and wait while GitLab reads

+1. Hit the **List Your GitHub Repositories** button and wait while GitLab reads

    your repositories' information. Once done, you'll be taken to the importer

    page to select the repositories to import.

 

@@ -112,7 +113,6 @@ You can also choose a different name for the project and a different namespace,
 if you have the privileges to do so.

 

 [gh-import]: ../../integration/github.md "GitHub integration"

-[new-project]: ../../gitlab-basics/create-project.md "How to create a new project in GitLab"

 [gh-integration]: #authorize-access-to-your-repositories-using-the-github-integration

 [gh-token]: #authorize-access-to-your-repositories-using-a-personal-access-token

 [social sign-in]: ../../profile/account/social_sign_in.md