Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7508#note_18730091

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7508#note_18622559

I didn't write an exhaustive one because we already have it on
HasStatus, from:

https://gitlab.com/gitlab-org/gitlab-ce/commit/b6a7a4783435a7fa34f26dbf3b16ab8e7ed21b88

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7508#note_18622499

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7508#note_18622469

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7508#note_18622182

* upstream/master: (162 commits)
  Grapify the repository API
  Fix wrong link URL
  Add note pointing to limitations section in environments.md
  Clarify the limitation for special chars is for Review Apps
  Change order of limitations list in environments.md
  Add an example of invalid characters to branches for review apps
  Grammar fix in environments.md: s/base/basis
  Add changelog entry for #24276 / !7500
  Allow registering users where the username contains dots (.).
  bump rouge to 2.0.7
  Fix indentation
  Update copy.md with issue guideline updates and merge request guidelines
  Refactor github import to reduce number of API calls
  Fix missing URL from environments docs
  Check all namespaces on validation of new username.
  Allow sorting groups in API
  Use the public CE repo URL instead of the one used in the runner
  Fix typos
  Fix wrong changelog item
  Add missing item for 8.13.6
  ...

Grapify repository api

See merge request !7534

Use the public CE repo URL instead of the one used in the runner

See the commit message to understand the reason of this change.

See merge request !7555

Allow registering users where the username contains dots (.)

## What does this MR do?

- Allow registering users whose usernames contains dots `.`
- This can currently be done by registering with a username containing no dots, and then editing the username to have dots in the user's profile settings.

## Does this MR meet the acceptance criteria?

-  [#24276/!7500] Unable to register names with dot
    - [x]  Implementation
    - [x]  Tests
        - [x]  Added
        - [x]  [Passing](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7500/builds)
    - [x]  Meta
        - [x]  CHANGELOG entry created
        - [x]  Documentation created/updated
        - [x]  API support added
        - [x]  Branch has no merge conflicts with `master`
        - [x]  Squashed related commits together
    - [x]  Review
        - [x]  Endboss
            - [x]  Use `Gitlab::Regex::NAMESPACE_REGEX_STR` instead of a hardcoded pattern
            - [x]  Define `NAMESPACE_REGEX_STR` in terms of `NAMESPACE_REGEX_STR_JS`
    - [ ]  Wait for merge


## What are the relevant issue numbers?

- Closes #24276

See merge request !7500

Check all namespaces on validation of new username.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/24519 and https://gitlab.com/gitlab-org/gitlab-ce/issues/24580

See merge request !7537

Fix wrong link URL

See merge request !7554

[ci skip]

Grammar fix in environments.md: s/base/basis

See merge request !7552

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

Javascript does not support the negative lookbehind assertion (?<!) used
in the Ruby regex (to disallow usernames ending in `.git` or `.atom`.

Getting the client side code to fully support this format is
non-trivial, since we'd either have to heavily complicate the
regex used, or modify the frontend code to support more complex
validation schemes (it currently uses HTML5 validations).

The pragmatic choice is to create a
`Gitlab::Regex::NAMESPACE_REGEX_STR_SIMPLE` regex to serve as a
Javascript-compatible version of `NAMESPACE_REGEX_STR`.

The client-side code will not display an error for usernames ending in
`.git` and `.atom`, but these will be caught by the server-side
validation.

bump rouge to 2.0.7

## What does this MR do?
Upgrades Rouge to 2.0.7 for various bugfixes.

## Are there points in the code the reviewer needs to double check?
See the Rouge changelog here: https://github.com/jneen/rouge/blob/v2.0.7/CHANGELOG.md

See merge request !7549

CHANGELOG: https://github.com/jneen/rouge/blob/v2.0.7/CHANGELOG.md

Resolve "Create a tab shortcut to jump directly to content"

## What does this MR do?
Adds accessibility shortcut to page, i.e. if user hits `tab` key right after the page is loaded and user has not interacted to any part of the page, the shortcut appears at top left corner of the page. Then, pressing `enter` (`spacebar` support is WIP) scrolls page to focus on content.

## Are there points in the code the reviewer needs to double check?
See if `id` attribute added to `.content` element (present in [_page.html.haml](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/views/layouts/_page.html.haml)) needs to be reviewed if it is correct approach or we already have an ID that shortcut can refer to.

## Why was this MR needed?
This feature is particularly useful for screen readers where user doesn't have to go through entire nav to reach content of page.

## Screenshots (if relevant)
![Screenshot_from_2016-11-17_17-59-22](/uploads/0eb0149f46bd35e9ce629e7a6533be53/Screenshot_from_2016-11-17_17-59-22.png)

## Does this MR meet the acceptance criteria?

- [ ] [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
  - [ ] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?


Closes #24057

See merge request !7533

Add placeholder in the color input inside the create new label popup

## What does this MR do?
Adds the missing placeholder  *"Assign custom color #FF0000"*  in the label creation popup ( example text for custom hex color).

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

## Why was this MR needed?
When creating a new label, the example text for custom hex color is missing

## Screenshots (if relevant)
Before
![before](/uploads/a3157414d59cea609118a7d711f9b9ee/before.png)

After
![Selection_051](/uploads/ca3e2089b40069e4cb6b7aa295b28cfc/Selection_051.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
  - [ ] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] 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)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

## What are the relevant issue numbers?
#24512 

See merge request !7492

Improve importing of github pull requests

Closes #24072

See merge request !7241

Update "Supported web browsers" text

## What does this MR do?

Updates the `Supported web browsers` text in the installation docs.

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

## Why was this MR needed?

Slack discussion

## Screenshots (if relevant)

## Does this MR meet the acceptance criteria?

- [ ] [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
  - [ ] Added for this feature/bug
  - [ ] All builds are passing
- [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [ ] [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 !7341

Allow sorting groups in API

Relates to #20013.

See merge request !7529

Update copy.md with issue guideline updates and merge request guidelines

Update copy.md with issue guideline updates and merge request guidelines

See merge request !7513

Update examples and labels to use sentence case.

Update copy.md  [ci skip]

Update copy.md [ci skip]

Update copy.md

Ref #24073

Fix missing URL from environments docs

See merge request !7542

[ci skip]

Fix line numbers not matching up with code in Firefox.

Firefox has had broken line number alignment for a while now, if this is a bug with Firefox they don't seem to want to fix it since its been there from 46 through 49. This fixes it.

Before:

![Screen_Shot_2016-09-22_at_3.08.44_PM](/uploads/8bb65f40e44f738c0c375b0c8ef7dea6/Screen_Shot_2016-09-22_at_3.08.44_PM.png)

After:

![Screen_Shot_2016-09-22_at_3.09.10_PM](/uploads/9e537be56886569d8a82390f2b97c42b/Screen_Shot_2016-09-22_at_3.09.10_PM.png)

Fixes #20202.

Safari/Chrome work the same as before, Snippets seems to work fine still as well.

Page tested: http://localhost:3000/gitlab-org/gitlab-ce/blob/master/app/models/project.rb

cc: @annabeldunstone

See merge request !6485

Decide on and document a convention for singletons

> The singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. 

The simplest implementation uses an object literal to contain the logic.

```javascript
gl.MyThing = {
  prop1: 'hello',
  method1: () => {}
};
```
A live example of this is [GfmAutoComplete](https://gitlab.com/gitlab-org/gitlab-ce/blob/172aab108b875e8dc9a5f1d3c2d53018eff76ea1/app/assets/javascripts/gfm_auto_complete.js.es6)

Another approach makes use of ES6 `class` syntax.
```javascript
let singleton;

class MyThing {
  constructor() {
    if (!singleton) {
       singleton = this;
       singleton.init();
     }
      return singleton;
  }

  init() {
    this.prop1 = 'hello';
  }

  method1() {}
}

gl.MyThing = MyThing;
```
A live example of this is [Sidebar](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/sidebar.js.es6)

Another functional approach to define Singleton using `Javascript Revealing Module Pattern` is like below
```javascript
/**
  *  1. It instantiates only a single object
  *  2. It is safe – it keeps the reference to the singleton inside a variable, which lives inside a lexical closure, so it is not accessible by the outside world
  *  3. It allows privacy – you can define all private methods of your singleton inside the lexical closure of the first module pattern
  *  4. No this keyword trap (no wrong context referring)
  *  5. No use of new keyword
  *  6. Easy to write test code
  */
//
const Singleton = (function () {
  // Instance stores a reference to the Singleton
  var instance;
  function init() {
    // Singleton
    // Private methods and variables
    function privateMethod(){
        console.log( "I am private" );
    }
    var privateVariable = "Im also private";
    var privateRandomNumber = Math.random();
    return {
      // Public methods and variables
      publicMethod: function () {
        console.log( "The public can see me!" );
      },
      publicProperty: "I am also public",
      getRandomNumber: function() {
        return privateRandomNumber;
      }
    };
  };
  return {
    // Get the Singleton instance if one exists
    // or create one if it doesn't
    getInstance: function () {
      if ( !instance ) {
        instance = init();
      }
      return instance;
    }
  };
})();

const singletonObj = Singleton.getInstance()

```

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

## What does this MR do? 

Creates a space for discussion and contribution for interested devs.

## Why was this MR needed?

## Screenshots (if relevant)

## Does this MR meet the acceptance criteria?

- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] All builds are passing
(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] [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 !6620

Fixing the issue of visiting a project fork url giving 500 error when not signed…

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

See merge request !7392

Support subscribing to group labels

https://gitlab.com/gitlab-org/gitlab-ce/issues/23586

See merge request !7215