When the `changes` passed to `GitAccess` are the literal string `_any`,
which indicates that this is a pre-authorization check, we now check
whether the user can push to any branch in the project in question,
instead of running the per-change check with `oldrev` `_any`, `newrev`
`nil`, and `ref` `nil`.
Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
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.
GitLab Bot
Manoj MJ
Francisco Javier López
Douwe Maan
Tiago Botelho
Alejandro Rodríguez
Jacob Vosmaer (GitLab)
Mark Chao
Rubén Dávila
Stan Hu
Bob Van Landuyt
Mayra Cabrera
Tomasz Maczukin
Michael Kozono
James Edwards-Jones
Douwe Maan
blackst0ne
Jacopo
Toon Claes
Nick Thomas
Robert Speicher