Skip to content
Snippets Groups Projects
  1. Mar 19, 2020
  2. Mar 17, 2020
  3. Mar 11, 2020
  4. Mar 06, 2020
  5. Mar 05, 2020
  6. Mar 04, 2020
  7. Mar 03, 2020
  8. Feb 28, 2020
  9. Feb 27, 2020
  10. Feb 25, 2020
  11. Feb 19, 2020
  12. Feb 14, 2020
  13. Feb 13, 2020
  14. Jan 29, 2020
  15. Jan 23, 2020
  16. Jan 20, 2020
  17. Jan 16, 2020
  18. Dec 10, 2019
  19. Dec 02, 2019
  20. Nov 19, 2019
  21. Oct 18, 2019
  22. Oct 17, 2019
  23. Sep 25, 2019
  24. Sep 18, 2019
  25. Sep 13, 2019
  26. Sep 10, 2019
  27. Jun 28, 2019
  28. Mar 28, 2019
  29. Jan 24, 2019
  30. Dec 20, 2018
  31. Nov 05, 2018
    • Yorick Peterse's avatar
      Rewrite SnippetsFinder to improve performance · d171ff60
      Yorick Peterse authored
      This completely rewrites the SnippetsFinder class from the ground up in
      order to improve its performance. The old code was beyond salvaging. It
      was complex, included various Rails 5 workarounds, comments that
      shouldn't be necessary, and most important of all: it produced a really
      poorly performing database query.
      
      As a result, I opted for rewriting the finder from scratch, instead of
      trying to patch the existing code. Instead of trying to reuse as many
      existing methods as possible, I opted for defining new methods
      specifically meant for the SnippetsFinder. This requires some extra code
      here and there, but allows us to have much more control over the
      resulting SQL queries. It is these changes that then allow us to produce
      a _much_ more efficient query.
      
      To illustrate how bad the old query was, we will use my own snippets as
      an example. Currently I have 52 snippets, most of which are global ones.
      To retrieve these, you would run the following Ruby code:
      
          user = User.find_by(username: 'yorickpeterse')
      
          SnippetsFinder.new(user, author: user).execute
      
      On GitLab.com the resulting query will take between 10 and 15 seconds to
      run, producing the query plan found at
      https://explain.depesz.com/s/Y5IX. Apart from the long execution time,
      the total number of buffers (the sum of all shared hits) is around 185
      GB, though the real number is probably (hopefully) much lower as I doubt
      simply summing these numbers produces the true total number of buffers
      used.
      
      The new query's plan can be found at https://explain.depesz.com/s/wHdN,
      and this query takes between 10 and 100-ish milliseconds to run. The
      total number of buffers used is only about 30 MB.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/52639
      Unverified
      d171ff60
  32. Oct 23, 2018
    • Jan Provaznik's avatar
      Redact unsubscribe links in issuable texts · c1c14964
      Jan Provaznik authored
      It's possible that user pastes accidentally also unsubscribe link
      which is included in footer of notification emails. This unsubscribe
      link contains personal token which attacker then use to act as the
      original user (e.g. for sending comments under his/her identity).
      c1c14964
  33. Sep 17, 2018
    • Yorick Peterse's avatar
      Added FromUnion to easily select from a UNION · 8a72f5c4
      Yorick Peterse authored
      This commit adds the module `FromUnion`, which provides the class method
      `from_union`. This simplifies the process of selecting data from the
      result of a UNION, and reduces the likelihood of making mistakes. As a
      result, instead of this:
      
          union = Gitlab::SQL::Union.new([foo, bar])
      
          Foo.from("(#{union.to_sql}) #{Foo.table_name}")
      
      We can now write this instead:
      
          Foo.from_union([foo, bar])
      
      This commit also includes some changes to make this new setup work
      properly. For example, a bug in Rails 4
      (https://github.com/rails/rails/issues/24193) would break the use of
      `from("sub-query-here").includes(:relation)` in certain cases. There was
      also a CI query which appeared to repeat a lot of conditions from an
      outer query on an inner query, which isn't necessary.
      
      Finally, we include a RuboCop cop to ensure developers use this new
      module, instead of using Gitlab::SQL::Union directly.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/51307
      Verified
      8a72f5c4
  34. Jul 30, 2018
    • 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
      f1d3ea63
  35. Jul 26, 2018
  36. Mar 07, 2018
    • Jan Provaznik's avatar
      Add discussion API · dcdfa04b
      Jan Provaznik authored
      * adds basic discussions API for issues and snippets
      * reorganizes notes specs (so same tests can be used for all noteable types - issues, MRs, snippets)
      dcdfa04b
Loading