Read about our upcoming Code of Conduct on this issue

This instance was upgraded to Heptapod 0.28.0 today

  1. 21 Aug, 2019 1 commit
    • George Koltsov's avatar
      Add SortingPreference concern · 3c45523d4c1c
      George Koltsov authored
      Sorting preference functionality has been extracted
      from `IssuableCollections` to a new `SortingPreference`
      concern in order to reuse this functionality in projects
      (and groups in the future).
      3c45523d4c1c
  2. 06 Aug, 2019 1 commit
  3. 18 Jun, 2019 2 commits
  4. 28 May, 2019 1 commit
  5. 08 Apr, 2019 1 commit
  6. 04 Apr, 2019 1 commit
    • Sean McGivern's avatar
      Extend CTE search optimisation to projects · 6a5ac2ef25dd
      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.
      6a5ac2ef25dd
  7. 26 Feb, 2019 1 commit
  8. 25 Feb, 2019 1 commit
  9. 22 Feb, 2019 1 commit
  10. 21 Feb, 2019 1 commit
  11. 28 Jan, 2019 1 commit
    • Mario de la Ossa's avatar
      Save sorting preference for Issues/MRs in BE · 7df1020f4fa6
      Mario de la Ossa authored
      In order to let users' sorting preferences transfer between devices, we
      save the preference for issues and MRs (one preference for issues, one
      for MRs) in the backend inside the UserPreference object
      7df1020f4fa6
  12. 12 Dec, 2018 1 commit
  13. 06 Dec, 2018 1 commit
  14. 03 Dec, 2018 1 commit
  15. 30 Nov, 2018 1 commit
    • Sean McGivern's avatar
      Add a flag to use a subquery for group issues search · 0aee72a79c49
      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.
      0aee72a79c49
  16. 14 Nov, 2018 1 commit
  17. 19 Sep, 2018 1 commit
    • gfyoung's avatar
      Enable frozen string in app/controllers/**/*.rb · ee72286c9404
      gfyoung authored
      Enables frozen string for the following:
      
      * app/controllers/*.rb
      * app/controllers/admin/**/*.rb
      * app/controllers/boards/**/*.rb
      * app/controllers/ci/**/*.rb
      * app/controllers/concerns/**/*.rb
      
      Partially addresses #47424.
      ee72286c9404
  18. 11 Sep, 2018 1 commit
  19. 04 Sep, 2018 1 commit
  20. 21 Aug, 2018 1 commit
  21. 07 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Force Postgres to avoid trigram indexes when in a group · 662bcc085924
      Sean McGivern authored
      When filtering issues with a search string in a group, we observed on GitLab.com
      that Postgres was using an inefficient query plan, preferring the (global)
      trigram indexes on description and title, rather than using a filter on the
      restricted set of issues within the group.
      
      Change the callers of the IssuableFinder to use a CTE in this case to fence the
      rest of the query from the LIKE filters, so that the optimiser is forced to
      perform the filter in the order we prefer.
      
      This will only force the use of a CTE when:
      
      1. The use_cte_for_search params is truthy.
      2. We are using Postgres.
      3. We have passed the `search` param.
      
      The third item is important - searching issues using the search box does not use
      the finder in this way, but contructs a query and appends `full_search` to
      that. For some reason, this query does not suffer from the same issue.
      
      Currenly, we only pass this param when filtering issuables (issues or MRs) in a
      group context.
      662bcc085924
  22. 06 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Simplify issuable finder queries · 88ec34f46eb6
      Sean McGivern authored
      We had `item_project_ids` to help make slow queries on the dashboard faster, but
      this isn't necessary any more - the queries are plenty fast, and we forbid
      searching the dashboard without filters.
      88ec34f46eb6
  23. 28 Apr, 2018 1 commit
  24. 24 Apr, 2018 1 commit
  25. 02 Mar, 2018 1 commit
    • Jan Provaznik's avatar
      Support additional LabelsFinder parameters for group labels · bfb1b792f1a0
      Jan Provaznik authored
      In some situations (listing labels for epics) we want to
      list only group ancestor labels, this is already supported
      in LabelsFinder we just need to enable additional parameters.
      
      Also `set_issuables_index` method now loads project labels only if
      @project is set (which is not used for epic group labels).
      bfb1b792f1a0
  26. 21 Feb, 2018 1 commit
    • Sean McGivern's avatar
      Refactor IssuableFinder to extract model-specific logic · 8bd617d3949f
      Sean McGivern authored
      By extracting a new `filter_items` method, we can override that in the
      IssuesFinder and MergeRequestsFinder separately, so we don't need checks that
      the model is the correct one, because we can just use the class we're in to know
      that.
      
      We can do the same for the VALID_PARAMS constant, by making it a class method.
      8bd617d3949f
  27. 01 Feb, 2018 1 commit
  28. 30 Jan, 2018 1 commit
    • Jan Provaznik's avatar
      Make pagination optional for issuables · 44c3ae871626
      Jan Provaznik authored
      On epics roadmap page we list all epics in the given time frame
      without pagination (at least for the first iteration), in this
      case it would be nice to use the existing issuables index logic
      except pagination (see MR gitlab-ee!4281). For this reason this
      patch allows to easily disable pagination.
      
      Related gitlab-ee!4281
      44c3ae871626
  29. 23 Nov, 2017 1 commit
    • Sean McGivern's avatar
      Use latest_merge_request_diff association · 8f7f03910539
      Sean McGivern authored
      Compared to the merge_request_diff association:
      
      1. It's simpler to query. The query uses a foreign key to the
         merge_request_diffs table, so no ordering is necessary.
      2. It's faster for preloading. The merge_request_diff association has to load
         every diff for the MRs in the set, then discard all but the most recent for
         each. This association means that Rails can just query for N diffs from N
         MRs.
      3. It's more complicated to update. This is a bidirectional foreign key, so we
         need to update two tables when adding a diff record. This also means we need
         to handle this as a special case when importing a GitLab project.
      
      There is some juggling with this association in the merge request model:
      
      * `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
      * `MergeRequest#merge_request_diff` reuses
        `MergeRequest#latest_merge_request_diff` unless:
          * Arguments are passed. These are typically to force-reload the association.
          * It doesn't exist. That means we might be trying to implicitly create a
            diff. This only seems to happen in specs.
          * The association is already loaded. This is important for the reasons
            explained in the comment, which I'll reiterate here: if we a) load a
            non-latest diff, then b) get its `merge_request`, then c) get that MR's
            `merge_request_diff`, we should get the diff we loaded in c), even though
            that's not the latest diff.
      
      Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
      but not quite all.
      8f7f03910539
  30. 22 Nov, 2017 1 commit
  31. 17 Nov, 2017 1 commit
  32. 07 Nov, 2017 1 commit
  33. 06 Nov, 2017 1 commit
  34. 26 Sep, 2017 1 commit
  35. 23 Sep, 2017 1 commit
  36. 18 Sep, 2017 2 commits
  37. 07 Sep, 2017 1 commit
  38. 05 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Re-use issue/MR counts for the pagination system · 518ba0ce3153
      Yorick Peterse authored
      This changes the issue and MR index pages so the pagination system
      re-uses the output of the COUNT(*) query used to calculate the number of
      rows per state (opened, closed, etc). This removes the need for an
      additional COUNT(*) on both pages.
      518ba0ce3153