This CI config entry location in configuration Hash.

* master: (352 commits)
  Display last commit of deleted branch in push events (!4699)
  add changelog
  add missing attribute to attr_encrypted so it is fully backwards-compatible
  Add "GitLab team members only" to diagram link
  doc: note that .gitattributes uses default branch
  use the conf lexer so we have highlighted comments
  first draft of docs
  support cgi style options, such as erb?parent=json
  move the path alias to a more appropriate location
  make #custom_language private
  appease rubocop
  add an alias for Snippet#path
  appease rubocop
  check the tag so that an instance will pass too
  fix the spec, using project.change_head
  Revert "bump the master sha for gitlab-test!9"
  bump the master sha for gitlab-test!9
  add custom highlighting via .gitattributes
  Rename Licenses API to License Templates API
  Check for conflict with wiki projects when creating a new project.
  ...

Refactor GitLab architecture document

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

See merge request !3694

Display last commit of deleted branch in push events

## What does this MR do?

Display the last commit of a deleted branch in the push events of a project.

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

Is the change in `app/models/event.rb` the correct way to display a two-line event for deleted branches?

## Why was this MR needed?

It is easier to restore an accidentally deleted branch if the commit hash is displayed in the push events.

## What are the relevant issue numbers?

Fixes #18659

## Screenshots

### Before garbage collection

![before-gc](/uploads/5674cd53e1564d48b7f2f8406ea0fbed/before-gc.png)

### After garbage collection

![after-gc](/uploads/80950c1932feeb3b69d0fc11b8f7acf4/after-gc.png)

See merge request !4699

Fix encrypted data backwards compatibility after upgrading attr_encrypted gem

Adds missing attribute to attr_encrypted so it is fully backwards-compatible. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19073

See merge request !4963

Add custom highlighting via .gitattributes

## What does this MR do?
Allows user control of language selection via a `gitlab-language` entry in `.gitattributes`

## Are there points in the code the reviewer needs to double check?
(paired with @stanhu)

## Why was this MR needed?
Guessing languages by filename is fraught and often wrong. In one project, `foo.pl` may be perl, and in another it may be prolog. Users might have a Thingfile that needs ruby highlighting, or depend on things that can't work in general, like `*.C` (capitalized) mapping to C++ instead of C.

This allows the user to override language choice so they never have to look at a mis-highlighted file.

## What are the relevant issue numbers?
https://github.com/jneen/rouge/issues/494
https://gitlab.com/gitlab-org/gitlab-ce/issues/13818 (*.tpl can't in general map to Smarty)
https://gitlab.com/gitlab-org/gitlab-ce/issues/13615 (in cases we don't have a language and mis-identify it, users could map to 'text' to turn off highlighting)

## Screenshots (if relevant)

## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added (N/A)
- [x] Tests
  - [x] Added for this feature/bug
  - [x] All builds are passing
- [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 you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

See merge request !4606

This reverts commit b435d7405364d28ec364072f4437512da2876762.

paired with @stanhu

Rename Licenses API to License Templates API

## What does this MR do?

Earlier I renamed this in EE, thinking license templates was an EE-only feature. This backports that change to CE. Thanks to @vsizov for pointing out this error.

See https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/400 for the EE merge request. 

See merge request !4957

Check for conflict with wiki projects when creating a new project.

## What does this MR do?
Check for conflict with wiki projects when creating a new project
## Are there points in the code the reviewer needs to double check?
No
## Why was this MR needed?
To avoid exposing the information from the wiki repository of other project
## What are the relevant issue numbers?
#18398 
## Screenshots (if relevant)
![Screen_Shot_2016-06-24_at_6.03.49_PM](/uploads/7bf55e5159bf0c2b653b8f4f941f72fc/Screen_Shot_2016-06-24_at_6.03.49_PM.png)
## Does this MR meet the acceptance criteria?

- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry 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
  - [x] All builds are passing
- [ ] 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 you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)

See merge request !4918

Fix visibility of snippets when searching

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/18997

See merge request !1972

Fix an information disclosure when requesting access to a group containing private projects

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19102.

The commit speaks for itself:

    Fix an information disclosure when requesting access to a group containing private projects
    
    The issue was with the `User#groups` and `User#projects` associations
    which goes through the `User#group_members` and `User#project_members`.
    
    Initially I chose to use a secure approach by storing the requester's
    user ID in `Member#created_by_id` instead of `Member#user_id` because I
    was aware that there was a security risk since I didn't know the
    codebase well enough.
    
    Then during the review, we decided to change that and directly store the
    requester's user ID into `Member#user_id` (for the sake of simplifying
    the code I believe), meaning that every `group_members` / `project_members`
    association would include the requesters by default...
    
    My bad for not checking that all the `group_members` / `project_members`
    associations and the ones that go through them (e.g. `Group#users` and
    `Project#users`) were made safe with the `where(requested_at: nil)` /
    `where(members: { requested_at: nil })` scopes.
    
    Now they are all secure.

See merge request !1973

Use `have_http_status` matcher where possible

See merge request !4955