1. Starting version 2.11, git changed the way the pre-receive flow works.

  - Previously, the new potential objects would be added to the main repo. If the
    pre-receive passes, the new objects stay in the repo but are linked up. If
    the pre-receive fails, the new objects stay orphaned in the repo, and are
    cleaned up during the next `git gc`.

  - In 2.11, the new potential objects are added to a temporary "alternate object
    directory", that git creates for this purpose. If the pre-receive passes, the
    objects from the alternate object directory are migrated to the main repo. If
    the pre-receive fails the alternate object directory is simply deleted.

2. In our workflow, the pre-recieve script (in `gitlab-shell) calls the
   `/allowed` endpoint, which calls out directly to git to perform
   various checks. These direct calls to git do _not_ have the necessary
   environment variables set which allow access to the "alternate object
   directory" (explained above). Therefore these calls to git are not able to
   access any of the new potential objects to be added during this push.

3. We fix this by accepting the relevant environment variables
   (GIT_ALTERNATE_OBJECT_DIRECTORIES, GIT_OBJECT_DIRECTORY) on the
   `/allowed` endpoint, and then include these environment variables while
   calling out to git.

4. This commit includes (whitelisted) these environment variables while making
   the "force push" check. A `Gitlab::Git::RevList` module is extracted to
   prevent `ForcePush` from being littered with these checks.

Resolve "Add a doorkeeper scope suitable for authentication"

## What does this MR do?

- Add a single new scope (in addition to the `api` scope we've had) - `read_user`
- Allow creating OAuth applications and Personal access tokens with a scope selected
- Enforce scopes in the API

## What are the relevant issue numbers?

- Closes #20492 
- EE counterpart for this MR: gitlab-org/gitlab-ee!946

See merge request !5951

Resolve "Manual actions on pipeline graph"

## What does this MR do?
Improves the pipeline graph:
- add actions to each node
- always show the status icon
- improves style
- adds new icons to use only on the pipeline graph
- fixes tooltip body
- adds partial to render the graph node

### Hover state:
@dimitrieh 

This MR does not implements 100% of the mockups - https://gitlab-org.gitlab.io/gitlab-design/progress/dimitrie/pipelines-graphic/22604-spec-previews/#artboard0

As you can see in the mockups, each node has 2 separate hover states, one for the all content and one for the action icon.
In order to not hover the all content when we hover the action icon we would need to refactor the all HTML & CSS of all the pipeline graph, lines included.
The hover problem can be seen in the following video.
[video](https://drive.google.com/file/d/0B2xW80W4hUf0cnJoS1RGQ2hWZlU/view)

As you can see in the video, the build node is hovered even when the mouse seems to be far from the element.

It does not seem wise to me to change the HTML & CSS now for two reasons:
- we would need to rewrite almost everything;
- we will probably rewrite everything when we move this to vue.

Given the latter point, and considering it will be a bug effort to make the hover states equal to the mockups, I suggest we do that when we rewrite the all view.
This is fixable, though, but requires some effort & time.

I can, although, be missing something. @annabeldunstone do you see any quick/easy fix here?


## Screenshots (if relevant)
[video](https://drive.google.com/file/d/0B2xW80W4hUf0OFhZaXlKTW5mS3c/view?usp=sharing)

![Screen_Shot_2016-12-12_at_12.38.25](/uploads/8f015b0d476c832912e1530208f3d70d/Screen_Shot_2016-12-12_at_12.38.25.png)
![Screen_Shot_2016-12-12_at_12.38.31](/uploads/51de435f1120142d9683f06854d66507/Screen_Shot_2016-12-12_at_12.38.31.png)
![Screen_Shot_2016-12-12_at_12.38.39](/uploads/642e7348bcf46a03d13d8eac1cb7ce6b/Screen_Shot_2016-12-12_at_12.38.39.png)
![Screen_Shot_2016-12-12_at_12.40.00](/uploads/781743893bc14cf05f4b8f258e2b58ba/Screen_Shot_2016-12-12_at_12.40.00.png)


Tooltip before
![Screen_Shot_2016-12-06_at_11.29.54](/uploads/b16c0434981a89fb68c4c053c2f1d6e6/Screen_Shot_2016-12-06_at_11.29.54.png)
Tooltip after
![Screen_Shot_2016-12-06_at_11.56.03](/uploads/e5e0ede0f3f8a5434e98373ab8a72500/Screen_Shot_2016-12-06_at_11.56.03.png)


## Does this MR meet the acceptance criteria?
- [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
  - [x] Added for this feature/bug
  - [ ] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?
Closes #22604


See merge request !7931

Ensure issuable state changes only fire webhooks once

Webhooks were fired twice when issuables were reopened or closed. Once for the status change and once for the `update` operation

Closes #25339

See merge request !8101

Shorten line length of issues and mrs

Limits container width on issue and mr pages. Shortens line length to human readable length.

![Screen_Shot_2016-12-02_at_12.48.08_PM](https://gitlab.com/gitlab-org/gitlab-ce/uploads/740647c0fd6ea4f0f0aef62155992afe/Screen_Shot_2016-12-05_at_12.54.12_PM.png)

Closes #20916 
Closes #24408

See merge request !7858

Add GitLab host to 2FA QR and manual info

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/25545

See merge request !6941

Added KaTeX license and procedure to build it for Gitlab

## What does this MR do?
Adds KaTeX license and the procedure for building KaTeX for gitlab. 

## Are there points in the code the reviewer needs to double check?
Nope.

## Why was this MR needed?
Requested by @stanhu

## Screenshots (if relevant)
Not relevant. 

## Does this MR meet the acceptance criteria?

- [X] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added
- [X] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [X] API support added
- Tests
  - [X] Added for this feature/bug
  - [X] All builds are passing
- [X] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [X] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [X] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [X] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?

See merge request !8132

The two factor authentication account string only had the user's
email address. This led to ambiguous entries in two factor
code generating apps. This adds the GitLab host to the account
string in the standard format (according to Google). No matter
the code generator this change disambiguates the entry.

Mattermost Notifications Service

## What does this MR do?
closes #22269 

## Screenshots 

![mattermost](/uploads/de71c121f544a91305b6dfa6dc4c5738/mattermost.png)  
![slack](/uploads/081d75d49239319d94332abda214fb98/slack.png)

## Does this MR meet the acceptance criteria?

- [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
  - [x] Added for this feature/bug
  - [x] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)


See merge request !7764

Fix 8.15 RC1 requires quite amount of downtime

See https://gitlab.com/gitlab-org/gitlab-ce/issues/25635

See merge request !8106

Update grape to 0.18.0

## What does this MR do?

Update grape to 0.18.0. Required for the settings API.

## What are the relevant issue numbers?

#22928

See merge request !8057

Fix specs in Ruby 2.1

Ruby 2.1 requires a basename argument to `Tempfile.open`, so just call
it something that makes sense in context for the spec.

See merge request !8138

Replace static fixture for abuse_reports_spec

## What does this MR do?

Replace static HAML fixture for `abuse_reports_spec` by dynamically created one.

## What are the relevant issue numbers?

#24753

See merge request !7644

Add missing group policy spec

See merge request !8122

Made Ci::Builds to have same ref as Ci::Pipeline in dev fixtures

See merge request !8110

Update custom hooks docs and set 4.1.0

See merge request !8040

Ruby 2.1 requires a basename argument to `Tempfile.open`, so just call
it something that makes sense in context for the spec.

UX Guide: add guidance on cursor usage

Add guidance to the UX guide on when to use what mouse cursor.

See merge request !8128

If we leave this as a regular migration, we could have the following flow:

1. Application knows nothing about scopes.
2. First migration runs, all existing personal access tokens have `api` scope
3. Application still knows nothing about scopes.
4. Second migration runs, all tokens created after this point have no scope
5. Application still knows nothing about scopes.
6. Tokens created at this time _should have the API scope, but instead have no scope_
7. Application code is reloaded, application knows about scopes
8. Tokens created after this point only have no scope if the user deliberately
   chooses to have no scopes.

Point #6 is the problem here. To avoid this, we move the second migration to a
"post" migration, which runs after the application code is deployed/reloaded.

`valid_api_token?` is a better name. Scopes are just (potentially) one facet of
a "valid" token.

- Previously, AccessTokenValidationService was a module, and all its  public
methods accepted a token. It makes sense to convert it to a class which accepts
a token during initialization.

- Also rename the `sufficient_scope?` method to `include_any_scope?`

- Based on feedback from @rymai

- The `scopes_form` partial can be used in the `admin/applications` view
  as well

- Don't allow partials to access instance variables directly. Instead, pass
  in the instance variables as local variables, and use `local_assigns.fetch`
  to assert that the variables are passed in as expected.

- Change a few instances of `render :partial` to `render`

- Remove an instance of `required: false` in a view, since this is the default

- Inline many instances of a local variable (`ip = 'ip'`) in `auth_spec`

Split the existing feature spec into both feature and controller specs.
Feature specs assert on browser DOM, and controller specs assert on database
state.

- Use whitespace to separate the setup, expectation and teardown phases.

- Based on @dbalexandre's review
- Extract token validity conditions into two separate methods, for
  personal access tokens and OAuth tokens.

- The list of scopes that's displayed while creating a personal access
  token is identical to the list that's displayed while creating an OAuth
  application. Extract these into a partial.

- The list of scopes that's displayed while in the show page for an OAuth token
  in the profile settings and admin settings are identical. Extract these into
  a partial.

- Mainly whitespace changes.

- Require the migration adding the `scope` column to the
  `personal_access_tokens` table to have downtime, since API calls will
  fail if the new code is in place, but the migration hasn't run.

- Minor refactoring - load `@scopes` in a `before_action`, since we're
  doing it in three different places.

- This module is used for git-over-http, as well as JWT.

- The only valid scope here is `api`, currently.

- Move the `Oauth2::AccessTokenValidationService` class to
  `AccessTokenValidationService`, since it is now being used for
  personal access token validation as well.

- Each API endpoint declares the scopes it accepts (if any). Currently,
  the top level API module declares the `api` scope, and the `Users` API
  module declares the `read_user` scope (for GET requests).

- Move the `find_user_by_private_token` from the API `Helpers` module to
  the `APIGuard` module, to avoid littering `Helpers` with more
  auth-related methods to support `find_user_by_private_token`

* Webhooks for close and reopen events now fired in respective services only
* Prevents generic 'update' webhooks firing too

* master: (51 commits)
  Fix spec/features/admin/admin_active_tab_spec.rb
  Fix eslint errors
  Don't open Asciidoc module twice
  Add `gitlab_rails['auto_migrate'] = false` to HA docs for Redis/PG [ci skip]
  Unify margin widths
  Add $CI_ENVIRONMENT_NAME and $CI_ENVIRONMENT_SLUG
  Add Okta authentication documentation
  Create environments when the build referencing them is created
  Add an environment slug
  Make the index on environment name and project id unique, fixing up any duplicates
  Rename `issue create` slash command to `issue new`
  Add changelog for !7850.
  Update Mattermost slash commands docs to explain how to create a newline and use <kbd> for user input. See HTML5 spec: https://www.w3.org/TR/html5/text-level-semantics.html#the-kbd-element
  Improve `issue create …` slash command with user input keys to create a newline in chat clients.
  Add explicit status test, feedback:
  Don't call anything on a block, use simple if
  Use described_class and update description
  Also use latest_status, feedback:
  Fixed bug with +1 not autocompleting
  added changelog entry
  ...

UI improvements for nested group feature

See merge request !8062