Removing those weird setup in assign_change_commit_vars
fixed all the failures in the tests. I still cannot say
why but clearly we need to have better names. It's so
confusing right now. We should seriously stop fiddling
those instance variables.

We merge repository checks inside it so we don't have to
check it on the call site, and we could also load the commit
for the caller. This greatly reduce code duplication.

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_20572919

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_20876648

Feedback:

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_20301332

* Simplify code around group parent access check
* Rename 'Nested groups' to 'Subgroups' tab at group#show page

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

When processing push payloads we now schedule at most the 100 most
recent commits, instead of all commits that were in a payload. This
prevents one from overloading the system by pushing thousands if not
millions of commits in a single go.

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

This adds counters for build artifacts and LFS objects, and moves
the preexisting repository_size and commit_count from the projects
table into a new project_statistics table.

The counters are displayed in the administration area for projects
and groups, and also available through the API for admins (on */all)
and normal users (on */owned)

The statistics are updated through ProjectCacheWorker, which can now
do more granular updates with the new :statistics argument.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Signed-off-by: Rémy Coutable <remy@rymai.me>

Prior to this commit the refreshing of authorized projects was done in
two steps:

1. Remove existing authorizations
2. Insert a new list of all authorizations

This can lead to a high amount of dead tuples as every time all rows are
being replaced. For example, if a user with 100 authorizations is given
access to a new project this would lead to:

* 100 rows being removed
* 101 new rows being inserted

This commit changes the way this system works so it only removes/inserts
what is necessary. Using the above example this would lead to only 1 new
row being inserted, with the initial 100 being left untouched.

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

- 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

- 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

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7333#note_20003268

if it happens. Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19747933

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19747922

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19747856

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19747793

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7237#note_19747556

The target branch of a merge request has to be a branch in the project
for which the merge request is submitted. When a branch changes in a fork,
it does not make sense to reload diffs of merge requests in the upstream
project that use the same branch name as the target branch.
Please note that it does make sense to reload diffs when the source branch
changes.

Douwe Maan authored 8 years ago and Alejandro Rodríguez committed 8 years ago

Replace MR access checks with use of MergeRequestsFinder

Split from !2024 to partially solve https://gitlab.com/gitlab-org/gitlab-ce/issues/23867

 - Potentially untested
 - No test coverage
 - Test coverage of some sort exists (a test failed when error raised)
 - Test coverage of return value (a test failed when nil used)
 - Permissions check tested

- [x]   app/finders/notes_finder.rb:17
- [x]   app/views/layouts/nav/_project.html.haml:80 [`.count`]
- [x]   app/controllers/concerns/creates_commit.rb:84
- [x]   app/controllers/projects/commits_controller.rb:24
- [x]   app/controllers/projects/compare_controller.rb:56
- [x]   app/controllers/projects/discussions_controller.rb:29
- [x]   app/controllers/projects/todos_controller.rb:27
- [x]   app/models/commit.rb:268
- [x]  lib/gitlab/search_results.rb:71

- [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_267_266 Memoize ` merged_merge_request(current_user)`
- [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_248_247 Expected side effect for `merged_merge_request!`, consider `skip_authorization: true`.
- [x] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#d1c10892daedb4d4dd3d4b12b6d071091eea83df_269_269 Scary use  of unchecked `merged_merge_request?`

See merge request !2033