This significantly improves performance when a user pushes many references.
project.path_locks.any? doesn't cache the output and runs `SELECT 1 AS one
FROM "path_locks" WHERE project_id = N` each time. When there are thousands
of refs being pushed, this can time out the unicorn worker.
CE port for https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6159.
This will make it clearer to users which account is being used to make
the API/git call. So they know which account needs to be used to
accept the terms.
Closes#46649
When terms are enforced, but the user has not accepted the terms
access to the API & git is rejected with a message directing the user
to the web app to accept the terms.
[10.3] Migrate `can_push` column from `keys` to `deploy_keys_project`
See merge request gitlab/gitlabhq!2276
(cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c)
1f2bd3c0 Backport to 10.3
Replaces all the explicit include metadata syntax in the specs (tag:
true) into the implicit one (:tag).
Added a cop to prevent future errors and handle autocorrection.
In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo
secondary node). But in GitLab CE it also might be useful to have the
"read-only" idea around. So port it back to GitLab CE.
Also having the principle of read-only in GitLab CE would hopefully
lead to less errors introduced, doing write operations when there
aren't allowed for read-only calls.
Closesgitlab-org/gitlab-ce#37534.
`allowed_key_types` is removed and the `minimum_<type>_bits` fields are
renamed to `<tech>_key_restriction`. A special sentinel value (`-1`) signifies
that the key type is disabled.
This also feeds through to the UI - checkboxes per key type are out, inline
selection of "forbidden" and "allowed" (i.e., no restrictions) are in.
As with the previous model, unknown key types are disallowed, even if the
underlying ssh daemon happens to support them. The defaults have also been
changed from the lowest known bit size to "no restriction". So if someone
does happen to have a 768-bit RSA key, it will continue to work on upgrade, at
least until the administrator restricts them.
This is an amalgamation of:
* Cory Hinshaw: Initial implementation !5552
* Rémy Coutable: Updates !9350
* Nick Thomas: Resolve conflicts and add ED25519 support !13712
- Adds a new `ProjectMovedError` class to encapsulate that error
condition. Inherits from `NotFoundError` so existing rescues should
continue to work.
- Separating that condition out of `NotFoundError` allowed us to
simplify the `raise_not_found` helper and avoid repeating the literal
string.
- Spec makes use of `ERROR_MESSAGES` hash to avoid repeating literal
error message strings.
No external behavior change.
This allows `GitHttpController` to set the HTTP status based on the type of error. Alternatively, we could have added an attribute to GitAccessStatus, but this pattern seemed appropriate.
FFaker can generate data that randomly break our test suite. This
simplifies our factories and use sequences which are more predictive.
Signed-off-by: Rémy Coutable <remy@rymai.me>
These specs never ran due to incorrect indentation: the `context` blocks
were inside the `before`.
Additionally, `GitHooksService` now has to yield itself to callers, and
`GitAccess` never appears to have had an `allowed?` method.