1. 24 Jan, 2018 1 commit
  2. 17 Jan, 2018 2 commits
  3. 11 Jan, 2018 1 commit
  4. 10 Jan, 2018 1 commit
  5. 08 Jan, 2018 20 commits
  6. 04 Jan, 2018 1 commit
  7. 03 Jan, 2018 2 commits
    • Michael Kozono's avatar
      Make DeleteConflictingRedirectRoutes no-op · f6352772
      Michael Kozono authored
      Both the post-deploy and background migration.
      f6352772
    • Yorick Peterse's avatar
      Use a background migration for issues.closed_at · 78d22fb2
      Yorick Peterse authored
      In a previous attempt (rolled back in
      https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16021) we tried
      to migrate `issues.closed_at` from timestamp to timestamptz using a
      regular migration. This has a bad impact on GitLab.com and as such was
      rolled back.
      
      This commit re-implements the original migrations using generic
      background migrations, allowing us to still migrate the data in a single
      release but without a negative impact on availability.
      
      To ensure the database schema is up to date the background migrations
      are performed inline in development and test environments. We also make
      sure to not migrate that that doesn't need migrating in the first place
      or has already been migrated.
      78d22fb2
  8. 02 Jan, 2018 1 commit
  9. 21 Dec, 2017 1 commit
  10. 13 Dec, 2017 1 commit
  11. 11 Dec, 2017 2 commits
  12. 08 Dec, 2017 1 commit
    • Bob Van Landuyt's avatar
      Move the circuitbreaker check out in a separate process · f1ae1e39
      Bob Van Landuyt authored
      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.
      f1ae1e39
  13. 07 Dec, 2017 1 commit
  14. 05 Dec, 2017 1 commit
  15. 01 Dec, 2017 4 commits