Read about our upcoming Code of Conduct on this issue

This instance was upgraded to Heptapod 0.28.0 today

  1. 05 Dec, 2018 1 commit
  2. 26 Sep, 2018 1 commit
    • gfyoung's avatar
      Enable even more frozen string in app/controllers · 73f4d7f633c9
      gfyoung authored
      Enables frozen string for some vestigial files as
      well as the following:
      
      * app/controllers/projects/**/*.rb
      * app/controllers/sherlock/**/*.rb
      * app/controllers/snippets/**/*.rb
      * app/controllers/users/**/*.rb
      
      Partially addresses #47424.
      73f4d7f633c9
  3. 13 Sep, 2018 1 commit
  4. 11 Sep, 2018 1 commit
  5. 02 Aug, 2018 1 commit
  6. 30 Jul, 2018 1 commit
    • Bob Van Landuyt's avatar
      Show the status of a user in interactions · a4d26a719e14
      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
      a4d26a719e14
  7. 04 Jul, 2018 1 commit
    • Bob Van Landuyt's avatar
      Add pipeline lists to GraphQL · 0a85b2bcbc2d
      Bob Van Landuyt authored
      This adds Keyset pagination to GraphQL lists. PoC for that is
      pipelines on merge requests and projects.
      
      When paginating a list, the base-64 encoded id of the ordering
      field (in most cases the primary key) can be passed in the `before` or
      `after` GraphQL argument.
      0a85b2bcbc2d
  8. 25 May, 2018 1 commit
  9. 24 May, 2018 1 commit
  10. 23 May, 2018 2 commits
  11. 22 May, 2018 4 commits
  12. 21 May, 2018 1 commit
  13. 17 May, 2018 3 commits
    • Yorick Peterse's avatar
      Exclude coverage data from the pipelines page · ad2321e4d0af
      Yorick Peterse authored
      When displaying a project's pipelines
      (Projects::PipelinesController#index) we now exclude the coverage data.
      This data was not used by the frontend, yet getting it would require one
      SQL query per pipeline. These queries in turn could be quite expensive
      on GitLab.com.
      ad2321e4d0af
    • Yorick Peterse's avatar
      Preload pipeline data for project pipelines · 3c64ad01bc13
      Yorick Peterse authored
      When displaying the pipelines of a project we now preload the following
      data:
      
      1. Authors of the commits that belong to these pipelines
      2. The number of warnings per pipeline, which is used by
         Ci::Pipeline#has_warnings?
      
      == Commit Authors
      
      Previously this data was queried for every Commit separately, leading to
      20 SQL queries being executed in the worst case. With an average of 3 to
      5 milliseconds per SQL query this could result in 100 milliseconds being
      spent in _just_ getting Commit authors.
      
      To preload this data Commit#author now uses BatchLoader (through
      Commit#lazy_author), and a separate module
      Gitlab::Ci::Pipeline::Preloader is used to ensure all authors are loaded
      before they are used.
      
      == Number of warnings
      
      This changes Ci::Pipeline#has_warnings? so it supports preloading of the
      number of warnings per pipeline. This removes the need for executing a
      COUNT(*) query for every pipeline just to see if it has any warnings or
      not.
      3c64ad01bc13
    • Yorick Peterse's avatar
      Limit the number of pipelines to count · 24c1b5d229da
      Yorick Peterse authored
      When displaying the project pipelines dashboard we display a few tabs
      for different pipeline states. For every such tab we count the number of
      pipelines that belong to it. For large projects such as GitLab CE this
      means having to count over 80 000 rows, which can easily take between 70
      and 100 milliseconds per query.
      
      To improve this we apply a technique we already use for search results:
      we limit the number of rows to count. The current limit is 1000, which
      means that if more than 1000 rows are present for a state we will show
      "1000+" instead of the exact number. The SQL queries used for this
      perform much better than a regular COUNT, even when a project has a lot
      of pipelines.
      
      Prior to these changes we would end up running a query like this:
      
          SELECT COUNT(*)
          FROM ci_pipelines
          WHERE project_id = 13083
          AND status IN ('success', 'failed', 'canceled')
      
      This would produce a plan along the lines of the following:
      
          Aggregate  (cost=3147.55..3147.56 rows=1 width=8) (actual time=501.413..501.413 rows=1 loops=1)
            Buffers: shared hit=17116 read=861 dirtied=2
            ->  Index Only Scan using index_ci_pipelines_on_project_id_and_ref_and_status_and_id on ci_pipelines  (cost=0.56..2984.14 rows=65364 width=0) (actual time=0.095..490.263 rows=80388 loops=1)
                  Index Cond: (project_id = 13083)
                  Filter: ((status)::text = ANY ('{success,failed,canceled}'::text[]))
                  Rows Removed by Filter: 2894
                  Heap Fetches: 353
                  Buffers: shared hit=17116 read=861 dirtied=2
          Planning time: 1.409 ms
          Execution time: 501.519 ms
      
      Using the LIMIT count technique we instead run the following query:
      
          SELECT COUNT(*)
          FROM (
              SELECT 1
              FROM ci_pipelines
              WHERE project_id = 13083
              AND status IN ('success', 'failed', 'canceled')
              LIMIT 1001
          ) for_count
      
      This query produces the following plan:
      
          Aggregate  (cost=58.77..58.78 rows=1 width=8) (actual time=1.726..1.727 rows=1 loops=1)
            Buffers: shared hit=169 read=15
            ->  Limit  (cost=0.56..46.25 rows=1001 width=4) (actual time=0.164..1.570 rows=1001 loops=1)
                  Buffers: shared hit=169 read=15
                  ->  Index Only Scan using index_ci_pipelines_on_project_id_and_ref_and_status_and_id on ci_pipelines  (cost=0.56..2984.14 rows=65364 width=4) (actual time=0.162..1.426 rows=1001 loops=1)
                        Index Cond: (project_id = 13083)
                        Filter: ((status)::text = ANY ('{success,failed,canceled}'::text[]))
                        Rows Removed by Filter: 9
                        Heap Fetches: 10
                        Buffers: shared hit=169 read=15
          Planning time: 1.832 ms
          Execution time: 1.821 ms
      
      While this query still uses a Filter for the "status" field the number
      of rows that it may end up filtering (at most 1001) is small enough that
      an additional index does not appear to be necessary at this time.
      
      See https://gitlab.com/gitlab-org/gitlab-ce/issues/43132#note_68659234
      for more information.
      24c1b5d229da
  14. 15 May, 2018 1 commit
  15. 06 May, 2018 1 commit
  16. 02 May, 2018 1 commit
  17. 01 May, 2018 1 commit
  18. 23 Apr, 2018 2 commits
  19. 18 Apr, 2018 1 commit
  20. 01 Feb, 2018 1 commit
    • Yorick Peterse's avatar
      Track and act upon the number of executed queries · 9627f5de5a69
      Yorick Peterse authored
      This ensures that we have more visibility in the number of SQL queries
      that are executed in web requests. The current threshold is hardcoded to
      100 as we will rarely (maybe once or twice) change it.
      
      In production and development we use Sentry if enabled, in the test
      environment we raise an error. This feature is also only enabled in
      production/staging when running on GitLab.com as it's not very useful to
      other users.
      9627f5de5a69
  21. 19 Dec, 2017 1 commit
    • Zeger-Jan van de Weg's avatar
      Load commit in batches for pipelines#index · 360f4832c8de
      Zeger-Jan van de Weg authored
      Uses `list_commits_by_oid` on the CommitService, to request the needed
      commits for pipelines. These commits are needed to display the user that
      created the commit and the commit title.
      
      This includes fixes for tests failing that depended on the commit
      being `nil`. However, now these are batch loaded, this doesn't happen
      anymore and the commits are an instance of BatchLoader.
      360f4832c8de
  22. 12 Sep, 2017 1 commit
  23. 05 Jul, 2017 1 commit
  24. 23 Jun, 2017 2 commits
  25. 13 Jun, 2017 1 commit
  26. 01 Jun, 2017 1 commit
  27. 31 May, 2017 1 commit
  28. 10 May, 2017 1 commit
  29. 09 May, 2017 1 commit
  30. 06 May, 2017 1 commit
  31. 05 May, 2017 2 commits