Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 46,780
    • Issues 46,780
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,533
    • Merge requests 1,533
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #249662
Closed
Open
Issue created Sep 15, 2020 by Andreas Brandl@abrandlContributor

Setup omnibus managed cronjob to trigger reindexing

This issue tracks the effort to create a cronjob with omnibus to trigger database index rebuilds automatically.

This should trigger a rake task (gitlab:db:reindex_auto or similar) at a set schedule. We might want to make the schedule configurable from the user perspective.

Note the rake task does not exist yet and we'd create this as a stub (no-op) if this helps to setup the cronjob (so we can later add the code to it, but it is already in place).

On GitLab.com, this cronjob should be deployed to an instance that has direct database access (no pgbouncers involved) - e.g. the same host we run database migrations on.

Assignee
Assign to
Time tracking