1. 10 Jul, 2019 1 commit
  2. 15 Apr, 2019 1 commit
  3. 06 Feb, 2019 1 commit
  4. 03 Jan, 2019 3 commits
  5. 17 Dec, 2018 1 commit
  6. 05 Dec, 2018 2 commits
  7. 29 Oct, 2018 1 commit
  8. 22 Oct, 2018 1 commit
  9. 11 Sep, 2018 1 commit
  10. 20 Jul, 2018 1 commit
  11. 04 Jun, 2018 1 commit
  12. 01 Jun, 2018 2 commits
  13. 18 Apr, 2018 1 commit
  14. 07 Apr, 2018 8 commits
  15. 27 Mar, 2018 1 commit
  16. 05 Mar, 2018 1 commit
  17. 28 Feb, 2018 1 commit
  18. 02 Feb, 2018 1 commit
  19. 23 Nov, 2017 2 commits
  20. 17 Nov, 2017 2 commits
  21. 08 Nov, 2017 1 commit
  22. 02 Nov, 2017 2 commits
  23. 18 Sep, 2017 1 commit
  24. 01 Sep, 2017 1 commit
  25. 31 Aug, 2017 1 commit
    • Sean McGivern's avatar
      `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.
      5883ce95
  26. 21 Aug, 2017 1 commit