Add latest changes from gitlab-org/gitlab@master

app/assets/stylesheets/framework/filters.scss

@@ -190,6 +190,7 @@
   min-width: 0;
   border: 1px solid $border-color;
   background-color: $white-light;
+  border-radius: $border-radius-default 0 0 $border-radius-default;
   @include media-breakpoint-down(sm) {
     flex: 1 1 auto;
@@ -287,7 +288,7 @@
 .filtered-search-history-dropdown-toggle-button {
   flex: 1;
   width: auto;
-  border-radius: 0;
+  border-radius: $border-radius-default 0 0 $border-radius-default;
   border: 0;
   border-right: 1px solid $border-color;
   color: $gl-text-color-secondary;
@@ -296,8 +297,7 @@
   &:hover,
   &:focus {
     color: $gl-text-color;
-    border-color: $blue-300;
-    outline: none;
+    border-color: $border-color;
   }
   svg {

app/models/error_tracking/project_error_tracking_setting.rb

@@ -73,7 +73,9 @@ module ErrorTracking
     end
     def sentry_client
-      Sentry::Client.new(api_url, token)
+      strong_memoize(:sentry_client) do
+        Sentry::Client.new(api_url, token)
+      end
     end
     def sentry_external_url

app/models/sentry_issue.rb

@@ -6,9 +6,15 @@ class SentryIssue < ApplicationRecord
   validates :issue, uniqueness: true, presence: true
   validates :sentry_issue_identifier, presence: true
+  after_create_commit :enqueue_sentry_sync_job
+
   def self.for_project_and_identifier(project, identifier)
     joins(:issue)
       .where(issues: { project_id: project.id })
       .find_by_sentry_issue_identifier(identifier)
   end
+
+  def enqueue_sentry_sync_job
+    ErrorTrackingIssueLinkWorker.perform_async(issue.id)
+  end
 end

app/views/admin/runners/index.html.haml

@@ -47,7 +47,7 @@
         .filtered-search-box
           = dropdown_tag(_('Recent searches'),
             options: { wrapper_class: 'filtered-search-history-dropdown-wrapper',
-            toggle_class: 'filtered-search-history-dropdown-toggle-button',
+            toggle_class: 'btn filtered-search-history-dropdown-toggle-button',
             dropdown_class: 'filtered-search-history-dropdown',
             content_class: 'filtered-search-history-dropdown-content' }) do
             .js-filtered-search-history-dropdown{ data: { full_path: admin_runners_path } }

app/views/shared/issuable/_search_bar.html.haml

@@ -21,7 +21,7 @@
             - if type != :boards_modal && type != :boards
               = dropdown_tag(_('Recent searches'),
                 options: { wrapper_class: "filtered-search-history-dropdown-wrapper",
-                toggle_class: "filtered-search-history-dropdown-toggle-button",
+                toggle_class: "btn filtered-search-history-dropdown-toggle-button",
                 dropdown_class: "filtered-search-history-dropdown",
                 content_class: "filtered-search-history-dropdown-content" }) do
                 .js-filtered-search-history-dropdown{ data: { full_path: search_history_storage_prefix } }

app/workers/all_queues.yml

@@ -143,6 +143,7 @@
 - delete_user
 - email_receiver
 - emails_on_push
+- error_tracking_issue_link
 - expire_build_instance_artifacts
 - git_garbage_collect
 - gitlab_shell

app/workers/error_tracking_issue_link_worker.rb

+# frozen_string_literal: true
+
+# Creates a link in Sentry between a Sentry issue and a GitLab issue.
+# If the link already exists, no changes will occur.
+# If a link to a different GitLab issue exists, a new link
+#   will still be created, but will not be visible in Sentry
+#   until the prior link is deleted.
+class ErrorTrackingIssueLinkWorker
+  include ApplicationWorker
+  include ExclusiveLeaseGuard
+  include Gitlab::Utils::StrongMemoize
+
+  feature_category :error_tracking
+  worker_has_external_dependencies!
+
+  LEASE_TIMEOUT = 15.minutes
+
+  attr_reader :issue
+
+  def perform(issue_id)
+    @issue = Issue.find_by_id(issue_id)
+
+    return unless issue && error_tracking && sentry_issue_id
+
+    try_obtain_lease do
+      logger.info("Linking Sentry issue #{sentry_issue_id} to GitLab issue #{issue.id}")
+
+      if integration_id.nil?
+        logger.info("Sentry integration unavailable for #{error_tracking.api_url}")
+
+        break
+      end
+
+      sentry_client.create_issue_link(integration_id, sentry_issue_id, issue)
+    rescue Sentry::Client::Error
+      logger.info("Failed to link Sentry issue #{sentry_issue_id} to GitLab issue #{issue.id}")
+    end
+  end
+
+  private
+
+  def error_tracking
+    strong_memoize(:error_tracking) do
+      issue.project.error_tracking_setting
+    end
+  end
+
+  def sentry_issue_id
+    strong_memoize(:sentry_issue_id) do
+      issue.sentry_issue.sentry_issue_identifier
+    end
+  end
+
+  def sentry_client
+    error_tracking.sentry_client
+  end
+
+  def integration_id
+    strong_memoize(:integration_id) do
+      repo&.integration_id
+    end
+  end
+
+  def repo
+    sentry_client
+      .repos(organization_slug)
+      .find { |repo| repo.project_id == issue.project_id && repo.status == 'active' }
+  end
+
+  def organization_slug
+    error_tracking.organization_slug
+  end
+
+  def project_url
+    ::Gitlab::Routing.url_helpers.project_url(issue.project)
+  end
+
+  def lease_key
+    "link_sentry_issue_#{sentry_issue_id}_gitlab_#{issue.id}"
+  end
+
+  def lease_timeout
+    LEASE_TIMEOUT
+  end
+end

changelogs/unreleased/28965-fix-filter-hover-state.yml

+---
+title: Add border radius and remove blue outline on recent searches filter
+merge_request: 23266
+author:
+type: fixed

changelogs/unreleased/cilium-managed-apps.yml

+---
+title: Add cilium to the managed cluster apps template
+merge_request: 22557
+author:
+type: added

changelogs/unreleased/dz-rename-custom-hooks.yml

+---
+title: Rename Custom hooks to Server hooks
+merge_request: 23064
+author:
+type: changed

changelogs/unreleased/sy-sync-issues-with-sentry.yml

+---
+title: Sync GitLab issue back to Sentry when created in GitLab
+merge_request: 23007
+author:
+type: added

config/sidekiq_queues.yml

@@ -101,6 +101,7 @@
   - [group_export, 1]
   - [self_monitoring_project_create, 2]
   - [self_monitoring_project_delete, 2]
+  - [error_tracking_issue_link, 2]
   # EE-specific queues
   - [analytics, 1]

doc/administration/custom_hooks.md

-# Custom server-side Git hooks **(CORE ONLY)**
-NOTE: **Note:**
-Custom Git hooks must be configured on the filesystem of the GitLab
-server. Only GitLab server administrators will be able to complete these tasks.
-Please explore [webhooks] and [CI] as an option if you do not
-have filesystem access. For a user configurable Git hook interface, see
-[Push Rules](../push_rules/push_rules.md),
-available in GitLab Enterprise Edition.
-
-NOTE: **Note:**
-Custom Git hooks won't be replicated to secondary nodes if you use [GitLab Geo](geo/replication/index.md)
-
-Git natively supports hooks that are executed on different actions.
-Examples of server-side Git hooks include pre-receive, post-receive, and update.
-See [Git SCM Server-Side Hooks][hooks] for more information about each hook type.
-
-As of GitLab Shell version 2.2.0 (which requires GitLab 7.5+), GitLab
-administrators can add custom Git hooks to any GitLab project.
-
-## Create a custom Git hook for a repository
-
-Server-side Git hooks are typically placed in the repository's `hooks`
-subdirectory. In GitLab, hook directories are symlinked to the GitLab Shell
-`hooks` directory for ease of maintenance between GitLab Shell upgrades.
-Custom hooks are implemented differently, but the behavior is exactly the same
-once the hook is created. Follow the steps below to set up a custom hook for a
-repository:
-
-1. Pick a project that needs a custom Git hook.
-1. On the GitLab server, navigate to the project's repository directory.
-   For an installation from source the path is usually
-   `/home/git/repositories/<group>/<project>.git`. For Omnibus installs the path is
-   usually `/var/opt/gitlab/git-data/repositories/<group>/<project>.git`.
-1. Create a new directory in this location called `custom_hooks`.
-1. Inside the new `custom_hooks` directory, create a file with a name matching
-   the hook type. For a pre-receive hook the file name should be `pre-receive`
-   with no extension.
-1. Make the hook file executable and make sure it's owned by Git.
-1. Write the code to make the Git hook function as expected. Hooks can be
-   in any language. Ensure the 'shebang' at the top properly reflects the language
-   type. For example, if the script is in Ruby the shebang will probably be
-   `#!/usr/bin/env ruby`.
-
-That's it! Assuming the hook code is properly implemented the hook will fire
-as appropriate.
-
-## Set a global Git hook for all repositories
-
-To create a Git hook that applies to all of your repositories in
-your instance, set a global Git hook. Since GitLab will look inside the GitLab Shell
-`hooks` directory for global hooks, adding any hook there will apply it to all repositories.
-Follow the steps below to properly set up a custom hook for all repositories:
-
-1. On the GitLab server, navigate to the configured custom hook directory. The
-   default is in the GitLab Shell directory. The GitLab Shell `hook` directory
-   for an installation from source the path is usually
-   `/home/git/gitlab-shell/hooks`. For Omnibus installs the path is usually
-    `/opt/gitlab/embedded/service/gitlab-shell/hooks`.
-   To look in a different directory for the global custom hooks,
-   set `custom_hooks_dir` in the GitLab Shell config. For
-   Omnibus installations, this can be set in `gitlab.rb`; and in source
-   installations, this can be set in `gitlab-shell/config.yml`.
-1. Create a new directory in this location. Depending on your hook, it will be
-   either a `pre-receive.d`, `post-receive.d`, or `update.d` directory.
-1. Inside this new directory, add your hook. Hooks can be
-   in any language. Ensure the 'shebang' at the top properly reflects the language
-   type. For example, if the script is in Ruby the shebang will probably be
-   `#!/usr/bin/env ruby`.
-1. Make the hook file executable and make sure it's owned by Git.
-
-Now test the hook to see that it's functioning properly.
-
-## Chained hooks support
-
-> [Introduced][93] in GitLab Shell 4.1.0 and GitLab 8.15.
-
-Hooks can be also global or be set per project directories and support a chained
-execution of the hooks.
-
-NOTE: **Note:**
-`<hook_name>.d` would need to be either `pre-receive.d`,
-`post-receive.d`, or `update.d` to work properly. Any other names will be ignored.
-
-NOTE: **Note:**
-Files in `.d` directories need to be executable and not match the backup file
-pattern (`*~`).
-
-The hooks are searched and executed in this order:
-
-1. `gitlab-shell/hooks` directory as known to Gitaly
-1. `<project>.git/hooks/<hook_name>` -  executed by `git` itself, this is symlinked to `gitlab-shell/hooks/<hook_name>`
-1. `<project>.git/custom_hooks/<hook_name>` - per project hook (this is already existing behavior)
-1. `<project>.git/custom_hooks/<hook_name>.d/*` - per project hooks
-1. `<project>.git/hooks/<hook_name>.d/*` OR `<custom_hooks_dir>/<hook_name.d>/*` - global hooks: all executable files (minus editor backup files)
-
-The hooks of the same type are executed in order and execution stops on the
-first script exiting with a non-zero value.
-
-## Custom error messages
-
-> [Introduced][5073] in GitLab 8.10.
-
-To have custom error messages appear in GitLab's UI when the commit is
-declined or an error occurs during the Git hook, your script should:
-
-- Send the custom error messages to either the script's `stdout` or `stderr`.
-- Prefix each message with `GL-HOOK-ERR:` with no characters appearing before the prefix.
-
-### Example custom error message
-
-This hook script written in bash will generate the following message in GitLab's UI:
-
-```bash
-#!/bin/sh
-echo "GL-HOOK-ERR: My custom error message.";
-exit 1
-```
-
-![Custom message from custom Git hook](img/custom_hooks_error_msg.png)
-
-[CI]: ../ci/README.md
-[hooks]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#Server-Side-Hooks
-[webhooks]: ../user/project/integrations/webhooks.md
-[5073]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5073
-[93]: https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/93
+---
+redirect_to: 'server_hooks.md'
+---
+This document was moved to [another location](server_hooks.md).

doc/administration/gitaly/index.md

@@ -352,9 +352,9 @@ coming in. One sure way to trigger a Gitaly request is to clone a repository
 from your GitLab server over HTTP.
 DANGER: **Danger:**
-If you have [custom server-side Git hooks](../custom_hooks.md) configured,
+If you have [Server hooks](../server_hooks.md) configured,
 either per repository or globally, you must move these to the Gitaly node.
-If you have multiple Gitaly nodes, copy your custom hook(s) to all nodes.
+If you have multiple Gitaly nodes, copy your server hook(s) to all nodes.
 ### Disabling the Gitaly service in a cluster environment

doc/administration/index.md

@@ -166,7 +166,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 ## Git configuration options
-- [Custom Git hooks](custom_hooks.md): Custom Git hooks (on the filesystem) for when webhooks aren't enough.
+- [Server hooks](server_hooks.md): Server hooks (on the filesystem) for when webhooks aren't enough.
 - [Git LFS configuration](lfs/lfs_administration.md): Learn how to configure LFS for GitLab.
 - [Housekeeping](housekeeping.md): Keep your Git repositories tidy and fast.
 - [Configuring Git Protocol v2](git_protocol.md): Git protocol version 2 support.

doc/administration/server_hooks.md

+---
+type: reference, howto
+disqus_identifier: 'https://docs.gitlab.com/ee/administration/custom_hooks.html'
+---
+
+# Server hooks **(CORE ONLY)**
+
+> **Notes:**
+>
+> - Server hooks were [introduced](https://gitlab.com/gitlab-org/gitlab/issues/196051) in GitLab 12.8 replacing Custom Hooks.
+> - Server hooks must be configured on the filesystem of the GitLab server. Only GitLab server administrators will be able to complete these tasks. Please explore [webhooks](../user/project/integrations/webhooks.md) and [GitLab CI/CD](../ci/README.md) as an option if you do not have filesystem access. For a user-configurable Git hook interface, see [Push Rules](../push_rules/push_rules.md), available in GitLab Starter **(STARTER)**.
+> - Server hooks won't be replicated to secondary nodes if you use [GitLab Geo](geo/replication/index.md).
+
+Git natively supports hooks that are executed on different actions.
+Examples of server-side Git hooks include pre-receive, post-receive, and update.
+See [Git SCM Server-Side Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks#Server-Side-Hooks) for more information about each hook type.
+
+As of GitLab Shell version 2.2.0 (which requires GitLab 7.5+), GitLab
+administrators can add custom Git hooks to any GitLab project.
+
+## Create a server hook for a repository
+
+Server-side Git hooks are typically placed in the repository's `hooks`
+subdirectory. In GitLab, hook directories are symlinked to the GitLab Shell
+`hooks` directory for ease of maintenance between GitLab Shell upgrades.
+Server hooks are implemented differently, but the behavior is exactly the same
+once the hook is created. Follow the steps below to set up a server hook for a
+repository:
+
+1. Pick a project that needs a server hook.
+1. On the GitLab server, navigate to the project's repository directory.
+   For an installation from source the path is usually
+   `/home/git/repositories/<group>/<project>.git`. For Omnibus installs the path is
+   usually `/var/opt/gitlab/git-data/repositories/<group>/<project>.git`.
+1. Create a new directory in this location called `custom_hooks`.
+1. Inside the new `custom_hooks` directory, create a file with a name matching
+   the hook type. For a pre-receive hook the file name should be `pre-receive`
+   with no extension.
+1. Make the hook file executable and make sure it's owned by Git.
+1. Write the code to make the server hook function as expected. Hooks can be
+   in any language. Ensure the 'shebang' at the top properly reflects the language
+   type. For example, if the script is in Ruby the shebang will probably be
+   `#!/usr/bin/env ruby`.
+
+That's it! Assuming the hook code is properly implemented the hook will fire
+as appropriate.
+
+## Set a global server hook for all repositories
+
+To create a Git hook that applies to all of your repositories in
+your instance, set a global server hook. Since GitLab will look inside the GitLab Shell
+`hooks` directory for global hooks, adding any hook there will apply it to all repositories.
+Follow the steps below to properly set up a server hook for all repositories:
+
+1. On the GitLab server, navigate to the configured custom hook directory. The
+   default is in the GitLab Shell directory. The GitLab Shell `hook` directory
+   for an installation from source the path is usually
+   `/home/git/gitlab-shell/hooks`. For Omnibus installs the path is usually
+    `/opt/gitlab/embedded/service/gitlab-shell/hooks`.
+   To look in a different directory for the global custom hooks,
+   set `custom_hooks_dir` in the GitLab Shell config. For
+   Omnibus installations, this can be set in `gitlab.rb`; and in source
+   installations, this can be set in `gitlab-shell/config.yml`.
+1. Create a new directory in this location. Depending on your hook, it will be
+   either a `pre-receive.d`, `post-receive.d`, or `update.d` directory.
+1. Inside this new directory, add your hook. Hooks can be
+   in any language. Ensure the 'shebang' at the top properly reflects the language
+   type. For example, if the script is in Ruby the shebang will probably be
+   `#!/usr/bin/env ruby`.
+1. Make the hook file executable and make sure it's owned by Git.
+
+Now test the hook to check whether it is functioning properly.
+
+## Chained hooks support
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-shell/merge_requests/93) in GitLab Shell 4.1.0 and GitLab 8.15.
+
+Hooks can be also global or be set per project directories and support a chained
+execution of the hooks.
+
+NOTE: **Note:**
+`<hook_name>.d` would need to be either `pre-receive.d`,
+`post-receive.d`, or `update.d` to work properly. Any other names will be ignored.
+
+NOTE: **Note:**
+Files in `.d` directories need to be executable and not match the backup file
+pattern (`*~`).
+
+The hooks are searched and executed in this order:
+
+1. `gitlab-shell/hooks` directory as known to Gitaly.
+1. `<project>.git/hooks/<hook_name>` -  executed by `git` itself, this is symlinked to `gitlab-shell/hooks/<hook_name>`.
+1. `<project>.git/custom_hooks/<hook_name>` - per-project hook (this was kept as the already existing behavior).
+1. `<project>.git/custom_hooks/<hook_name>.d/*` - per-project hooks.
+1. `<project>.git/hooks/<hook_name>.d/*` OR `<custom_hooks_dir>/<hook_name.d>/*` - global hooks: all executable files (except editor backup files).
+
+The hooks of the same type are executed in order and execution stops on the
+first script exiting with a non-zero value.
+
+## Custom error messages
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/5073) in GitLab 8.10.
+
+To have custom error messages appear in GitLab's UI when the commit is
+declined or an error occurs during the Git hook, your script should:
+
+- Send the custom error messages to either the script's `stdout` or `stderr`.
+- Prefix each message with `GL-HOOK-ERR:` with no characters appearing before the prefix.
+
+### Example custom error message
+
+This hook script written in bash will generate the following message in GitLab's UI:
+
+```bash
+#!/bin/sh
+echo "GL-HOOK-ERR: My custom error message.";
+exit 1
+```
+
+![Custom message from custom Git hook](img/custom_hooks_error_msg.png)

doc/development/documentation/styleguide.md

@@ -256,12 +256,18 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
     Some features are also objects. For example, "GitLab's Merge Requests support X" and
     "Create a new merge request for Z."
+- Use common contractions when it helps create a friendly and informal tone, especially in tutorials and [UIs](https://design.gitlab.com/content/punctuation/#contractions).
+  - Do use contractions like: _it's_, _can't_, _wouldn't_, _you're_, _you've_, _haven't_, don't, _we're_, _that's_, and _won't_. Contractions in instructional documentation such as tutorials can help create a friendly and informal tone.
+  - Avoid less common contractions such as: _he'd_, _it'll_, _should've_, and _there'd_.
+  - Do not use contractions in reference documentation. Examples:
+    - You cannot set a limit higher than 1000.
+    - For `parameter1`, the default is 10.
+  - Do not use contractions with a proper noun and a verb, such as _GitLab's creating X_.
+  - Avoid using contractions when you need to emphasize a negative, such as "Do **not** install X with Y."
+
 - Avoid use of the future tense:
   - Instead of "after you execute this command, GitLab will display the result", use "after you execute this command, GitLab displays the result".
   - Only use the future tense to convey when the action or result will actually occur at a future time.
-- Do not use contractions:
-  - Instead of "don't," "can't," "doesn't," and so on, use "do not," "cannot," or "does not."
-  - Possible exceptions are cases when a more familiar tone is desired, such as a blog post or other casual context.
 - Do not use slashes to clump different words together or as a replacement for the word "or":
   - Instead of "and/or," consider using "or," or use another sensible construction.
   - Other examples include "clone/fetch," author/assignee," and "namespace/repository name." Break apart any such instances in an appropriate way.

doc/hooks/custom_hooks.md

 ---
-redirect_to: '../administration/custom_hooks.md'
+redirect_to: '../administration/server_hooks.md'
 ---
 # Custom Git Hooks
-This document was moved to [administration/custom_hooks.md](../administration/custom_hooks.md).
+This document was moved to [administration/server_hooks.md](../administration/server_hooks.md).

doc/integration/github.md

@@ -4,57 +4,31 @@ You can integrate your GitLab instance with GitHub.com as well as GitHub Enterpr
 ## Enabling GitHub OAuth
-To enable GitHub OmniAuth provider, you must use GitHub's credentials for your GitLab instance.
-To get the credentials (a pair of Client ID and Client Secret), you must register an application as an OAuth App on GitHub.
-1. Sign in to GitHub.
-1. Navigate to your individual user or organization settings, depending on how you want the application registered. It does not matter if the application is registered as an individual or an organization - that is entirely up to you.
-   - For individual accounts, select **Developer settings** from the left menu, then select **OAuth Apps**.
-   - For organization accounts, directly select **OAuth Apps** from the left menu.
-1. Select **Register an application** (if you don't have any OAuth App) or **New OAuth App** (if you already have OAuth Apps).
-   ![Register OAuth App](img/github_app_entry.png)
-1. Provide the required details.
-   - Application name: This can be anything. Consider something like `<Organization>'s GitLab` or `<Your Name>'s GitLab` or something else descriptive.
-   - Homepage URL: The URL of your GitLab installation. For example, `https://gitlab.example.com`.
-   - Application description: Fill this in if you wish.
-   - Authorization callback URL: `http(s)://${YOUR_DOMAIN}/users/auth`. Please make sure the port is included if your GitLab instance is not configured on default port.
-   ![Register OAuth App](img/github_register_app.png)
-   NOTE: Be sure to append `/users/auth` to the end of the callback URL
-   to prevent a [OAuth2 convert
-   redirect](http://tetraph.com/covert_redirect/) vulnerability.
-1. Select **Register application**.
-1. You should now see a pair of **Client ID** and **Client Secret** near the top right of the page (see screenshot).
-   Keep this page open as you continue configuration.
-   ![GitHub app](img/github_app.png)
-1. On your GitLab server, open the configuration file.
-
-   For Omnibus package:
-
-   ```sh
-   sudo editor /etc/gitlab/gitlab.rb
-   ```
-
-   For installations from source:
-
-   ```sh
-   cd /home/git/gitlab
-
-   sudo -u git -H editor config/gitlab.yml
-   ```
-
-1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
-
-1. Add the provider configuration:
-
-   For Omnibus package:
+To enable the GitHub OmniAuth provider, you'll need an OAuth 2 Client ID and Client Secret from GitHub. To get these credentials, sign into GitHub and follow their procedure for [Creating an OAuth App](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/).
+When you create an OAuth 2 app in GitHub, you'll need the following information:
+- The URL of your GitLab instance, such as `https://gitlab.example.com`.
+- The authorization callback URL; in this case, `https://gitlab.example.com/users/auth`. Include the port number if your GitLab instance uses a non-default port.
+NOTE: **Note:**
+To prevent an [OAuth2 covert redirect](http://tetraph.com/covert_redirect/) vulnerability, append `/users/auth` to the end of the GitHub authorization callback URL.
+See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
+Once you have configured the GitHub provider, you'll need the following information, which you'll need to substitute in the GitLab configuration file, in the steps shown next.
+| Setting from GitHub  |  Substitute in the GitLab configuration file | Description |
+|:---------------------|:-----------------------------------------------|:------------|
+| Client ID            | `YOUR_APP_ID`     |  OAuth 2 Client ID     |
+| Client Secret        | `YOUR_APP_SECRET` |  OAuth 2 Client Secret |
+| URL                  | `https://github.example.com/` |  GitHub Deployment URL |
+Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
+**For Omnibus installations**
+1. Edit `/etc/gitlab/gitlab.rb`:
    For GitHub.com:
@@ -83,7 +57,15 @@ To get the credentials (a pair of Client ID and Client Secret), you must registe
    ]
    ```
-   For installation from source:
+   **Replace `https://github.example.com/` with your GitHub URL.**
+
+1. Save the file and [reconfigure](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+
+---
+
+**For installations from source**
+
+1. Navigate to your repository and edit `config/gitlab.yml`:
    For GitHub.com:
@@ -102,20 +84,15 @@ To get the credentials (a pair of Client ID and Client Secret), you must registe
      args: { scope: 'user:email' } }
    ```
-   __Replace `https://github.example.com/` with your GitHub URL.__
-
-1. Change `YOUR_APP_ID` to the Client ID from the GitHub application page from step 6.
-1. Change `YOUR_APP_SECRET` to the Client Secret from the GitHub application page from step 6.
-1. Save the configuration file.
-1. [Reconfigure GitLab][] or [restart GitLab][] 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 a GitHub icon below the regular sign in form.
-Click the icon to begin the authentication process. GitHub will ask the user to sign in and authorize the GitLab application.
-If everything goes well the user will be returned to GitLab and will be signed in.
+   **Replace `https://github.example.com/` with your GitHub URL.**
+1. Save the file and [restart](../administration/restart_gitlab.html#installations-from-source) GitLab for the changes to take effect.
+---
+1. Refresh the GitLab sign in page. You should now see a GitHub icon below the regular sign in form.
+1. Click the icon to begin the authentication process. GitHub will ask the user to sign in and authorize the GitLab application.
 ## GitHub Enterprise with self-signed Certificate