An error occurred fetching the project authors.
  1. 06 Nov, 2020 1 commit
  2. 05 Nov, 2020 1 commit
  3. 19 Oct, 2020 1 commit
  4. 16 Oct, 2020 1 commit
  5. 14 Oct, 2020 2 commits
    • Nick Thomas's avatar
      1593c81f
    • Nick Thomas's avatar
      Recover gracefully when issuable counts are too expensive · 517a05c7
      Nick Thomas authored
      On the MR list page, we like to display how many issues were found from
      the filtered search query *in total*. However, especially when the
      filter includes conditions on the MR title or description, this can be
      very expensive to calculate, and involve reading gigabytes of text data
      from the database.
      
      As long as the data is already in the page cache, this usually finishes
      within the 15-second timeout on GitLab.com, but if the database cache
      is cold, a statement timeout is the usual occurrence.
      
      More generally, it's not very clever to spend so much time calculating
      a piece of information with marginal value.
      
      This MR applies a shorter limit to the counting statements and provides
      for graceful fallback to a '?' value, with a nice tooltip, if the query
      times out. This means we're able to view the results in a reasonable
      time, rather than the page taking a long time to load, or not loading
      at all.
      517a05c7
  6. 05 Aug, 2020 1 commit
  7. 17 Jul, 2020 1 commit
  8. 13 Jul, 2020 1 commit
  9. 27 May, 2020 1 commit
    • Felipe Artur's avatar
      Refactor issuable metadata · 3c118b6b
      Felipe Artur authored
      Turn IssuableMetadata concern into a class.
      This refactoring allows EE only metadata to have its
      logic on ee folder.
      3c118b6b
  10. 14 Nov, 2019 1 commit
    • Igor's avatar
      Execute limited request for diff commits instead of preloading · 92778fcf
      Igor authored
      The number of diff commits can be overwhelming sometimes and
      preloading them and iterating over them using map
      can be very expensive
      
      We'd better make multiple limited requests (even if it's N+1)
      then running into a subtle case when thousands of elements
      are loaded into memory and iterated
      92778fcf
  11. 10 Sep, 2019 1 commit
    • Markus Koller's avatar
      Add controller concern for paginated collections · f1926b32
      Markus Koller authored
      We had similar code in a few places to redirect to the last page if
      the given page number is out of range. This unifies the handling in a
      new controller concern and adds usage of it in all snippet listings.
      f1926b32
  12. 21 Aug, 2019 2 commits
  13. 06 Aug, 2019 1 commit
  14. 30 Jul, 2019 1 commit
    • Yorick Peterse's avatar
      Inject EE modules in a CE compatible fashion · 1112fec4
      Yorick Peterse authored
      All instances of injecting an EE specific module have been changed to
      use the new methods for this: prepend_if_ee, extend_if_ee, and
      include_if_ee. This allows these lines to be included in CE, even when
      the modules to inject do not exist. This in turn allows us to backport
      these lines to CE and keep them there, instead of having to strip them
      out.
      1112fec4
  15. 21 Jun, 2019 1 commit
  16. 18 Jun, 2019 2 commits
  17. 29 May, 2019 1 commit
  18. 28 May, 2019 1 commit
  19. 09 Apr, 2019 1 commit
    • Oswaldo Ferreira's avatar
      Support multi-assignees on merge requests · 4aaf0534
      Oswaldo Ferreira authored
      This mainly handles the search and replace approach
      to using assignees instead assignee for merge requests.
      
      It reuses existing logic from Issuable, where now
      issues _and_ merge requests handles multiple assignees.
      
      The feature is behind a feature flag, though, there's no
      way to switch back and forth to using the old and new tables.
      That's because we'd need a "sync" approach: Once the feature
      is off, we'd have to sync old table with new table, once it's
      on, new table with old table. Using the new
      `merge_request_assignees` altogether will make things simpler to
      handle, even though it's a bit "riskier".
      4aaf0534
  20. 08 Apr, 2019 1 commit
  21. 04 Apr, 2019 1 commit
    • Sean McGivern's avatar
      Extend CTE search optimisation to projects · 10ceb33b
      Sean McGivern authored
      When we use the `search` param on an `IssuableFinder`, we can run into
      issues. We have trigram indexes to support these searches. On
      GitLab.com, we often see Postgres's optimiser prioritise the (global)
      trigram indexes over the index on `project_id`. For group and project
      searches, we know that it will be quicker to filter by `project_id`
      first, as it returns fewer rows in most cases.
      
      For group issues search, we ran into this issue previously, and went
      through the following iterations:
      
      1. Use a CTE on the project IDs as an optimisation fence. This prevents
         the planner from disregarding the index on `project_id`.
         Unfortunately it breaks some types of sorting, like priority and
         popularity, as they sort on a joined table.
      2. Use a subquery for listing issues, and a CTE for counts. The subquery
         - in the case of group lists - didn't help as much as the CTE, but
         was faster than not including it. We can safely use a CTE for counts
         as they don't have sorting.
      
      Now, however, we're seeing the same issue in a project context. The
      subquery doesn't help at all there (it would only return one row, after
      all). In an attempt to keep total code complexity under control, this
      commit removes the subquery optimisation and applies the CTE
      optimisation only for sorts we know that are safe.
      
      This means that for more complicated sorts (like priority and
      popularity), the search will continue to be very slow. If this is a
      high-priority issue, we can consider introducing further optimisations,
      but this finder is already very complicated and additional complexity
      has a cost.
      
      The group CTE optimisation is controlled by the same feature flag as
      before, `attempt_group_search_optimizations`, which is enabled by
      default. The new project CTE optimisation is controlled by a new feature
      flag, `attempt_project_search_optimizations`, which is disabled by
      default.
      10ceb33b
  22. 26 Feb, 2019 2 commits
  23. 25 Feb, 2019 2 commits
  24. 22 Feb, 2019 1 commit
  25. 21 Feb, 2019 1 commit
  26. 28 Jan, 2019 2 commits
  27. 24 Jan, 2019 1 commit
  28. 18 Dec, 2018 1 commit
  29. 12 Dec, 2018 2 commits
    • Yorick Peterse's avatar
      Reinstate changes lost due to automatic merging · 749ebc1c
      Yorick Peterse authored
      The automatic merging code used `--strategy=ours`, which turned out to
      be incorrect; instead we wanted `--strategy=recursive
      --strategy-option=ours`. This small difference results in merging
      throwing away _all_ EE changes in favour of CE changes, instead of only
      doing this for conflicts.
      
      This commit ensures that EE has all the appropriate changes. The diff
      was generated by cherry picking all merge commits made since two days
      ago, picking them with `--strategy=recursive --strategy-option=ours`.
      749ebc1c
    • Felipe Artur's avatar
      b80dca82
  30. 06 Dec, 2018 1 commit
  31. 05 Dec, 2018 1 commit
  32. 03 Dec, 2018 1 commit
  33. 30 Nov, 2018 1 commit
    • Sean McGivern's avatar
      Add a flag to use a subquery for group issues search · 7fd5dbf9
      Sean McGivern authored
      We already had a flag to use a CTE, but this broke searching in some
      cases where we need to sort by a joined table. Disabling the CTE flag
      makes searches much slower.
      
      The new flag, to use a subquery, makes them slightly slower than the
      CTE, while maintaining correctness. If both it and the CTE flag are
      enabled, the subquery takes precedence.
      7fd5dbf9