Before we were using a "plumbing" Gitlab::Git method that does not go
through Gitaly migration checking.

Fix "A copy of Gitlab::Middleware::Readonly has been removed from the module tree but is still active"

Similar to #34047 and #29327

They were probably added to compensate for tests shortcomings, but now
they don't complain.

Closes gitaly#1095

Douwe Maan authored 6 years ago and Mark Fletcher committed 6 years ago

Server Side Request Forgery in Services and Web Hooks

See merge request gitlab/gitlabhq!2337

Closes #43887.

Index creation does not have an effect if the index is present already.
Index removal does not have an affect if the index is not present.

This helps to avoid patterns like this in migrations:
```
if index_exists?(...)
  remove_concurrent_index(...)
end
```

This should simplify refactoring and allow testing

Split repository search result on \n instead of $ to prevent the items of the array to start with a newline. Remove the strip from parsing the search result to keep result endlines.

Closes #44365

These can be a `BatchLoader` which is proxying a nil, while not being concrete
nils themselves.

and fixes the project description not being imported

Prevents `.gitattributes` blob lookup being repeated for every file checked at a given ref

Closes #43355

This is most a backport of
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4987/diffs but includes
other columns that use column_exists? in a way that may cause unnecessary
schema loads.

Carried over from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8857

This may lead to some being evicted and having to be cached again, but many MRs
get closed or updated in that time anyway.

Previously, we kept them all in the cache. We don't need the highlight results
for older diffs - if someone does view that (which is rare), we can do the
highlighting on the fly.

The concurrency issue originates from inserts on
`user_interacted_projects` from the app while running the post-deploy
migration.

This change comes with a strategy to lock the table while removing
duplicates and creating the unique index (and similar for FK
constraints).

Also, we'll have a non-unique index until the post-deploy migration is
finished to speed up queries during that time.

Closes #44205.

When importing from a GitLab archive, an admin can carry over the
assignations. Other users can not.

When a regular user is importing an issue with multiple assignees, the
assignee is replaced with the current user, meaning we would try to
insert current user as an assignee multiple times.

By filtering the array before storing it, the import becomes more
robust.

On .com repositories are created through Gitaly for a while now. For
customers this is not the case unless these have chosen to do so through
feature flags. By moving this to opt out, everyone will be using this.

This move is part of the migration issue
https://gitlab.com/gitlab-org/gitaly/issues/593

The bigger impact this commit will have is that tests that use a
repository through `FactoryBot.create(:project, :repository)` will now
use Gitaly to do so. As tests run on the same disk, or at least machine,
this will most probably slow them down.

Prior to this change, this method was called add_namespace, which broke
the CRUD convention and made it harder to grep for what I was looking
for. Given the change was a find and replace kind of fix, this was
changed without opening an issue and on another feature branch.

If more dynamic calls are made to add_namespace, these could've been
missed which might lead to incorrect bahaviour. However, going through
the commit log it seems thats not the case.

The same as the SQL queries, show the details of Gitaly calls in the performance
bar, as a modal that can be opened in the same way.

Also use Gitlab::Auth::OAuth::Provider.config_for to access OmniAuth config