For reasons unknown, the logs of a web hook were paginated in memory.
This would result in the "Edit" page of a web hook timing out once it
has more than a few thousand log entries.
This commit makes the following changes:
1. We use LIMIT/OFFSET to paginate the data, instead of doing this in
memory.
2. We limit the logs to the last two days, just like the documentation
says (instead of retrieving everything).
3. We change the indexes on "web_hook_logs" so the query to get the data
can perform a backwards index scan, without the need for a Filter.
These changes combined ensure that Projects::HooksController#edit no
longer times out.
This commit does a number of things:
1. Reduces the number of queries needed by perform a single query to get all
the tuples for the relevant rows.
2. Uses a transaction to query the tuple counts to ensure that the data
is retrieved from the primary.
Closes#46742
Uses PostgreSQL tuple estimates to provide a much faster yet approximate
count. See https://wiki.postgresql.org/wiki/Slow_Counting for more details.
We only use this fast method if the table has been analyzed or vacuumed
within the last hour.
Closes#46255
If form does not have import sources checkboxes we should not reset
import sources to empty. This fixes issue when import sources got reset
after user modifies unrelated settings section like GitLab pages
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
The `RAILS5=1 rspec spec/controllers/admin/application_settings_controller_spec.rb`
command throws the error:
Failures:
1) Admin::ApplicationSettingsController PUT #update falls back to defaults when settings are omitted
Failure/Error: import_sources = params[:application_setting][:import_sources]
NoMethodError:
undefined method `[]' for nil:NilClass
# ./app/controllers/admin/application_settings_controller.rb:62:in `application_setting_params'
This commit fixes it.
When the database is in a read-only state, display a banner on each
page informing the user they cannot write to that GitLab instance.
Closesgitlab-org/gitlab-ce#43937.
This ensures that we have more visibility in the number of SQL queries
that are executed in web requests. The current threshold is hardcoded to
100 as we will rarely (maybe once or twice) change it.
In production and development we use Sentry if enabled, in the test
environment we raise an error. This feature is also only enabled in
production/staging when running on GitLab.com as it's not very useful to
other users.
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.
[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
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.
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.