BigW Consortium Gitlab

  1. 02 Feb, 2018 1 commit
  2. 11 Jan, 2018 1 commit
  3. 14 Dec, 2017 1 commit
    • Import gitlab_projects.rb from gitlab-shell · 4b785df2
      Nick Thomas authored
      By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid
      200ms of startup time for each gitlab_projects subprocess we are eliminating.
      
      By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and
      any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can
      also manage these git processes more cleanly, and avoid sending SIGKILL to them
  4. 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.
  5. 28 Jun, 2017 1 commit
  6. 26 Jun, 2017 1 commit
  7. 09 Jan, 2017 1 commit