There are 2 problems with this spec:
1. It checks for default visiblity level however there is not code in
controller to handle such default. Same check can be performed on model
directly.
2. It passes empty application_setting hash while controller requires
application_setting not to be empty by using `require` with `permit`
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Implements the client side for gitlab-org/gitaly#819. Which is a server
info command. This checks the server version and git binairy version on
the server.
A small UI was added for administrators, so they can check the status of
the Gitaly server. This is done for each storage the monolith knows.
Because of this commit, gitlab-org/gitlab-ce!15580 is now closed. That
MR removed the Git version too, but didn't replace it with anything.
Moving the check out of the general requests, makes sure we don't have
any slowdown in the regular requests.
To keep the process performing this checks small, the check is still
performed inside a unicorn. But that is called from a process running
on the same server.
Because the checks are now done outside normal request, we can have a
simpler failure strategy:
The check is now performed in the background every
`circuitbreaker_check_interval`. Failures are logged in redis. The
failures are reset when the check succeeds. Per check we will try
`circuitbreaker_access_retries` times within
`circuitbreaker_storage_timeout` seconds.
When the number of failures exceeds
`circuitbreaker_failure_count_threshold`, we will block access to the
storage.
After `failure_reset_time` of no checks, we will clear the stored
failures. This could happen when the process that performs the checks
is not running.
Resolves#24576
Modify the guard clause of the `ApplicationController#require_email`
before action to skip requests where an admin is impersonating the
current user.
If notification_email is blank, it's set from email. If an admin
attempted to create a user with an invalid email, an error would be
displayed for both fields. Only validate the notification_email if it's
different from email.
There is a race condition in DestroyGroupService now that projects are deleted asynchronously:
1. User attempts to delete group
2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
4. Projects::DestroyService runs later but the can?(current_user,
:remove_project) is `false` because the user no longer has permission to
destroy projects with no namespace.
5. This leaves the project in pending_delete state with no namespace/group.
Projects without a namespace or group also adds another problem: it's not possible to destroy the container
registry tags, since container_registry_path_with_namespace is the wrong value.
The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService.
Closes#17893