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

* add parent_id field to namespaces table to store relation with nested groups
* create routes table to keep information about full path of every group and project
* project/group lookup by full path from routes table

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

When a merge request can only be merged when all discussions are
resolved. This feature allows to easily delegate those discussions to a
new issue, while marking them as resolved in the merge request.

The user is presented with a new issue, prepared with mentions of all
unresolved discussions, including the first unresolved note of the
discussion, time and link to the note.

When the issue is created, the discussions in the merge request will get
a system note directing the user to the newly created issue.

By passing commit data to this worker we remove the need for querying
the Git repository for every job. This in turn reduces the time spent
processing each job.

The migration included migrates jobs from the old format to the new
format. For this to work properly it requires downtime as otherwise
workers may start producing errors until they're using a newer version
of the worker code.

when we care only about the number of commits

We do not have to instantiate all objects in this case.

The implicit interface of project services states that the "execute"
method is meant to be called when project hooks are executed.
Currently JiraService does not support any project events even though
JiraService#supported_events says that "commit" and "merge_request"
are supported. They are only used to render correct options in
JIRA configuration screen, but they are not supported.
Because of that, this commit makes "execute" method a no-op.

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

Replace issue access checks with use of IssuableFinder

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

## Which fixes are in this MR?

⚠️ - 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

### Issue lookup with access check

Using `visible_to_user` likely makes these security issues too. See [Code smells](#code-smells).

- [x] 🚦 app/finders/notes_finder.rb:15 [`visible_to_user`]
- [x] 🚥 app/views/layouts/nav/_project.html.haml:73 [`visible_to_user`] [`.count`]
- [x] ✅ app/services/merge_requests/build_service.rb:84 [`issue.try(:confidential?)`]
- [x] ✅ lib/api/issues.rb:112 [`visible_to_user`]
  - CHANGELOG: Prevented API returning issues set to 'Only team members' to everyone
- [x] ✅ lib/api/helpers.rb:126 [`can?(current_user, :read_issue, issue)`] Maybe here too?
- [x] ✅ lib/gitlab/search_results.rb:53 [`visible_to_user`]

### Previous discussions
- [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#b2ff264eddf9819d7693c14ae213d941494fe2b3_128_126
- [ ] https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2024/diffs#7b6375270d22f880bdcb085e47b519b426a5c6c7_87_87

See merge request !2031

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

Fix label creation non members

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

See merge request !2006

We only know the tag SHA after we create the tag.
This means that we pass a different value to the hooks that happen before
creating the tag, and a different value to the hooks that happen after
creating the tag.

This is not an ideal situation, but it is a trade-off we decided to
make. For discussion of the alternatives please refer to
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7700#note_18982873

"pre-receive" and "update" hooks always get the SHA of the commit
that the tag points to. "post-receive" gets the tag SHA if it is
an annotated tag or the commit SHA if it is an lightweight tag.
Currently we always create annotated tags if UI is used.

Flushing the events cache worked by updating a recent number of rows in
the "events" table. This has the result that on PostgreSQL a lot of dead
tuples are produced on a regular basis. This in turn means that
PostgreSQL will spend considerable amounts of time vacuuming this table.
This in turn can lead to an increase of database load.

For GitLab.com we measured the impact of not using events caching and
found no measurable increase in response timings. Meanwhile not flushing
the events cache lead to the "events" table having no more dead tuples
as now rows are only inserted into this table.

As a result of this we are hereby removing events caching as it does not
appear to help and only increases database load.

For more information see the following comment:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6578#note_18864037

Rails by default use autoload for all dirs from app folder.
require_relative not needed. See ActiveSupport::Dependencies.autoload_paths

This refactors repository caching so it's possible to selectively
refresh certain caches, instead of just expiring and refreshing
everything.

To allow this the various methods that were cached (e.g. "tag_count" and
"readme") use a similar pattern that makes expiring and refreshing
their data much easier.

In this new setup caches are refreshed as follows:

1. After a commit (but before running ProjectCacheWorker) we expire some
   basic caches such as the commit count and repository size.

2. ProjectCacheWorker will recalculate the commit count, repository
   size, then refresh a specific set of caches based on the list of
   files changed in a push payload.

This requires a bunch of changes to the various methods that may be
cached. For one, data should not be cached if a branch used or the
entire repository does not exist. To prevent all these methods from
handling this manually this is taken care of in
Repository#cache_method_output. Some methods still manually check for
the existence of a repository but this result is also cached.

With selective flushing implemented ProjectCacheWorker no longer uses an
exclusive lease for all of its work. Instead this worker only uses a
lease to limit the number of times the repository size is updated as
this is a fairly expensive operation.

This reverts commit f913170e.

Merge request !7163 caused an error message to appear on the Merge
Request form when it was first loaded by the user. This commit fixes
that regression bug.

Closes #23150

The intended flow is:

  Soft-delete group (sync) -> Delete group projects (async) -> Hard-delete group (async)

The soft-delete was run in a transaction, which was committed only after
the async job (for hard-deletion) was kicked off. There was a race
condition here - the soft-delete transaction could complete _after_ the
hard delete completed, leaving a soft-deleted record in the database.

This commit removes this race condition. There is no need to run the
soft-delete in a transaction. The soft-delete completes before the async
job is kicked off.

This is the structure Kamil proposed, which leaves us with a bunch of
smaller classes. This commits deletes outdated files and tests
everything from the SlashCommandService and down (child classes and
subcommands)

Now, each subcommand has its own service, plus I've introduced
presenters to be able to delegate the generation of the views.

This commit includes a couple of thing:
- A chatops controller
- Mattermost::CommandService
- Mattermost::Commands::(IssueService|MergeRequestService)

The controller is the point where mattermost, and later slack will have
to fire their payload to. This in turn will execute the CommandService.

Thats where the authentication and authorization should happen. So far
this is not yet implemented. This should happen in later commits.

Per subcommand, in case of `/gitlab issue show 123` issue whould be the
subcommand, there is a service to parse the data, and fetch the
resource. The resource is passed back to the CommandService which
structures the data.