BigW Consortium Gitlab

  1. 09 Oct, 2017 3 commits
  2. 07 Oct, 2017 1 commit
  3. 06 Oct, 2017 1 commit
    • Create idea of read-only database · d1366971
      Toon Claes authored
      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.
      
      Closes gitlab-org/gitlab-ce#37534.
  4. 05 Oct, 2017 6 commits
  5. 04 Oct, 2017 3 commits
  6. 03 Oct, 2017 1 commit
  7. 23 Sep, 2017 1 commit
  8. 14 Sep, 2017 1 commit
  9. 07 Sep, 2017 1 commit
  10. 06 Sep, 2017 6 commits
  11. 31 Aug, 2017 1 commit
    • `current_application_settings` belongs on `Gitlab::CurrentSettings` · 5883ce95
      Sean McGivern authored
      The initializers including this were doing so at the top level, so every object
      loaded after them had a `current_application_settings` method. However, if
      someone had rack-attack enabled (which was loaded before these initializers), it
      would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
      have that method.
      
      To fix this:
      
      1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
         `Object.new.current_application_settings` to work.
      2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
         like that in several places.
      3. Change the initializers to use that new form.
  12. 30 Aug, 2017 2 commits
  13. 29 Aug, 2017 5 commits
  14. 28 Aug, 2017 1 commit
  15. 25 Aug, 2017 1 commit
  16. 22 Aug, 2017 4 commits
  17. 17 Aug, 2017 2 commits