1. 15 Apr, 2019 1 commit
  2. 11 Apr, 2019 1 commit
  3. 05 Apr, 2019 1 commit
  4. 14 Feb, 2019 1 commit
  5. 11 Jan, 2019 1 commit
  6. 19 Dec, 2018 1 commit
  7. 17 Dec, 2018 1 commit
  8. 15 Nov, 2018 1 commit
  9. 13 Nov, 2018 1 commit
  10. 01 Oct, 2018 2 commits
  11. 26 Sep, 2018 1 commit
  12. 11 Sep, 2018 1 commit
  13. 30 Aug, 2018 1 commit
  14. 17 Aug, 2018 1 commit
  15. 02 Aug, 2018 1 commit
  16. 30 Jul, 2018 2 commits
    • Bob Van Landuyt's avatar
      Show the status of a user in interactions · f1d3ea63
      Bob Van Landuyt authored
      The status is shown for
      - The author of a commit when viewing a commit
      - Notes on a commit (regular/diff)
      - The user that triggered a pipeline when viewing a pipeline
      - The author of a merge request when viewing a merge request
      - The author of notes on a merge request (regular/diff)
      - The author of an issue when viewing an issue
      - The author of notes on an issue
      - The author of a snippet when viewing a snippet
      - The author of notes on a snippet
      - A user's profile page
      - The list of members of a group/user
    • Bob Van Landuyt's avatar
      Allow users to set a status · b4c4b48a
      Bob Van Landuyt authored
      This can be done trough the API for the current user, or on the
      profile page.
  17. 24 Jul, 2018 1 commit
  18. 18 Jul, 2018 2 commits
  19. 08 May, 2018 1 commit
  20. 04 May, 2018 1 commit
  21. 07 Mar, 2018 1 commit
  22. 02 Feb, 2018 1 commit
  23. 08 Jan, 2018 1 commit
  24. 02 Jan, 2018 1 commit
  25. 23 Nov, 2017 1 commit
  26. 16 Nov, 2017 1 commit
    • Yorick Peterse's avatar
      Cache the number of user SSH keys · 3e561736
      Yorick Peterse authored
      By caching the number of personal SSH keys we reduce the number of
      queries necessary on pages such as ProjectsController#show (which can
      end up querying this data multiple times).
      The cache is refreshed/flushed whenever an SSH key is added, removed, or
      when a user is removed.
  27. 06 Nov, 2017 1 commit
  28. 22 Oct, 2017 1 commit
  29. 06 Oct, 2017 1 commit
    • to1ne's avatar
      Create idea of read-only database · d1366971
      to1ne 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.
  30. 28 Sep, 2017 5 commits
  31. 07 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Rework how recent push events are retrieved · 83355336
      Yorick Peterse authored
      Whenever you push to a branch GitLab will show a button to create a
      merge request (should one not exist already). The underlying code to
      display this data was quite inefficient. For example, it involved
      multiple slow queries just to figure out what the most recent push event
      This commit changes the way this data is retrieved so it's much faster.
      This is achieved by caching the ID of the last push event on every push,
      which is then retrieved when loading certain pages. Database queries are
      only executed if necessary and the cached data is removed automatically
      once a merge request has been created, or 2 hours after being stored.
      A trade-off of this approach is that we _only_ track the last event.
      Previously if you were to push to branch A and B then create a merge
      request for branch B we'd still show the widget for branch A. As of this
      commit this is no longer the case, instead we will only show the widget
      for the branch you pushed to most recently. Once a merge request exists
      the widget is no longer displayed. Alternative solutions are either too
      complex and/or too slow, hence the decision was made to settle for this
      Performance Impact
      In the best case scenario (= a user didn't push anything for more than 2
      hours) we perform a single Redis GET per page. Should there be cached
      data we will run a single (and lightweight) SQL query to get the
      event data from the database. If a merge request already exists we will
      run an additional DEL to remove the cache key.
      The difference in response timings can vary a bit per project. On
      GitLab.com the 99th percentile of time spent in User#recent_push hovers
      between 100 milliseconds and 1 second, while the mean hovers around 50
      milliseconds. With the changes in this MR the expected time spent in
      User#recent_push is expected to be reduced down to just a few
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/35990
  32. 06 Sep, 2017 1 commit
  33. 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.