debian-mirror-gitlab/doc/administration/repository_checks.md
2022-06-21 17:19:12 +05:30

3.6 KiB

stage group info type
Create Gitaly To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments reference

Repository checks (FREE SELF)

You can use git fsck to verify the integrity of all data committed to a repository. GitLab administrators can trigger this check for a project using the GitLab UI:

  1. On the top bar, select Menu > Admin.
  2. On the left sidebar, select Overview > Projects.
  3. Select the project to check.
  4. In the Repository check section, select Trigger repository check.

The checks run asynchronously so it may take a few minutes before the check result is visible on the project page in the Admin Area. If the checks fail, see what to do.

This setting is off by default, because it can cause many false alarms.

Enable periodic checks

Instead of checking repositories manually, GitLab can be configured to run the checks periodically:

  1. On the top bar, select Menu > Admin.
  2. On the left sidebar, select Settings > Repository (/admin/application_settings/repository).
  3. Expand the Repository maintenance section.
  4. Enable Enable repository checks.

When enabled, GitLab periodically runs a repository check on all project repositories and wiki repositories to detect possible data corruption. A project is checked no more than once per month. Administrators can configure the frequency of repository checks. To edit the frequency:

  • For Omnibus GitLab installations, edit gitlab_rails['repository_check_worker_cron'] in /etc/gitlab/gitlab.rb.
  • For source-based installations, edit [gitlab.cron_jobs.repository_check_worker] in /home/git/gitlab/config/gitlab.yml.

If any projects fail their repository checks, all GitLab administrators receive an email notification of the situation. By default, this notification is sent out once a week at midnight at the start of Sunday.

Repositories with known check failures can be found at /admin/projects?last_repository_check_failed=1.

What to do if a check failed

If a repository check fails, locate the error in the repocheck.log file on disk at:

  • /var/log/gitlab/gitlab-rails for Omnibus GitLab installations.
  • /home/git/gitlab/log for installations from source.

If periodic repository checks cause false alarms, you can clear all repository check states:

  1. On the top bar, select Menu > Admin.
  2. On the left sidebar, select Settings > Repository (/admin/application_settings/repository).
  3. Expand the Repository maintenance section.
  4. Select Clear all repository checks.

Run a check using the command line

You can run git fsck using the command line on repositories on Gitaly servers. To locate the repositories:

  1. Go to the storage location for repositories. For Omnibus GitLab installations, repositories are stored by default in the /var/opt/gitlab/git-data/repositories directory.
  2. Identify the subdirectory that contains the repository that you need to check.

To run a check (for example):

sudo /opt/gitlab/embedded/bin/git -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck

You can also run Rake tasks for checking Git repositories, which can be used to run git fsck against all repositories and generate repository checksums, as a way to compare repositories on different servers.