BigW Consortium Gitlab

  1. 18 Sep, 2017 1 commit
  2. 13 Sep, 2017 1 commit
    • Constrain environment deployments to project IDs · f04094a4
      Yorick Peterse authored
      When querying the deployments of an environment the query Rails produces
      will be along the lines of the following:
      
          SELECT *
          FROM deployments
          WHERE environment_id = X
      
      For queries such as this (or queries that use this as their base and add
      more conditions) there is no meaningful index that can be used as long
      as deployments.project_id is not part of a WHERE clause.
      
      To work around this we change that "has_many :deployments" relation to
      always add a "WHERE project_id = X" condition. This means that queries
      filtering deployments can make better use of the existing indexes. For
      example, when filtering by deployments.iid this will result in the
      following query:
      
          SELECT *
          FROM deployments
          WHERE environment_id = X
          AND project_id = Y
          AND iid = Z
      
      This means PostgreSQL can use the existing index on
      (project_id, environment_id, iid) instead of having to use a different
      index (or none at all) and having to scan over a large amount of data.
      
      Query plan wise this means that instead of this query and plan:
      
          EXPLAIN (BUFFERS, ANALYZE)
          SELECT deployments.*
          FROM deployments
          WHERE deployments.environment_id = 5
          AND deployments.iid = 225;
      
          Index Scan using index_deployments_on_project_id_and_iid on deployments  (cost=0.42..14465.75 rows=1 width=117) (actual time=6.394..38.048 rows=1 loops=1)
            Index Cond: (iid = 225)
            Filter: (environment_id = 5)
            Rows Removed by Filter: 839
            Buffers: shared hit=4534
          Planning time: 0.076 ms
          Execution time: 38.073 ms
      
      We produce the following query and plan:
      
          EXPLAIN (BUFFERS, ANALYZE)
          SELECT deployments.*
          FROM deployments
          WHERE deployments.environment_id = 5
          AND deployments.iid = 225
          AND deployments.project_id = 1292351;
      
          Index Scan using index_deployments_on_project_id_and_iid on deployments  (cost=0.42..4.45 rows=1 width=117) (actual time=0.018..0.018 rows=1 loops=1)
            Index Cond: ((project_id = 1292351) AND (iid = 225))
            Filter: (environment_id = 5)
            Buffers: shared hit=4
          Planning time: 0.088 ms
          Execution time: 0.039 ms
      
      On GitLab.com these changes result in a (roughly) 11x improvement in SQL
      timings for the CI environment status endpoint.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36877
  3. 08 Sep, 2017 1 commit
  4. 25 Aug, 2017 1 commit
  5. 06 Jul, 2017 1 commit
    • Added Cop to blacklist the use of `dependent:` · 8fbbf41e
      Yorick Peterse authored
      This is allowed for existing instances so we don't end up 76 offenses
      right away, but for new code one should _only_ use this if they _have_
      to remove non database data. Even then it's usually better to do this in
      a service class as this gives you more control over how to remove the
      data (e.g. in bulk).
  6. 05 Jul, 2017 1 commit
  7. 27 Jun, 2017 1 commit
    • Add in_review_folder to usage ping · e7d12a70
      Z.J. van de Weg authored
      As its hard to reliably check how many review apps there are on the
      clients machine, we start by checking where the type is `review`. This
      means the folder is called that way. This will lead to a seq
      scan on the table. However, this is done once a week, so the benefit of
      adding an index seems not to apply here.
  8. 21 Jun, 2017 1 commit
  9. 16 Jun, 2017 1 commit
  10. 12 Jun, 2017 1 commit
  11. 07 Jun, 2017 1 commit
  12. 06 Jun, 2017 1 commit
  13. 31 May, 2017 1 commit
  14. 25 May, 2017 2 commits
  15. 22 May, 2017 1 commit
    • Use etag caching for environments JSON · ebede2b3
      Z.J. van de Weg authored
      For the index view, the environments can now be requested every 15
      seconds. Any transition state of a projects environments will trigger a
      cache invalidation action.
      
      Fixes gitlab-org/gitlab-ce#31701
  16. 12 May, 2017 1 commit
    • Use etag caching for environments JSON · 4535d520
      Z.J. van de Weg authored
      For the index view, the environments can now be requested every 15
      seconds. Any transition state of a projects environments will trigger a
      cache invalidation action.
      
      Fixes gitlab-org/gitlab-ce#31701
  17. 11 May, 2017 1 commit
    • Custom queries for prometheus · 4f824d2a
      Pawel Chojnacki authored
      - Tests for prometheus queries
      
      - fix rubocop warnings
      
      - Remove unused method. Add more queries to deployment queries.
      
      - Wrap BaseQuery in module hierarchy
      
      Renname Prometheus class to PrometheusClient
  18. 10 May, 2017 1 commit
  19. 12 Apr, 2017 1 commit
  20. 06 Apr, 2017 1 commit
  21. 07 Mar, 2017 1 commit
  22. 23 Feb, 2017 2 commits
  23. 13 Feb, 2017 1 commit
  24. 07 Feb, 2017 1 commit
  25. 06 Feb, 2017 4 commits
  26. 23 Jan, 2017 1 commit
  27. 09 Jan, 2017 1 commit
    • Treat environments matching `production/*` as Production · b7467748
      Toon Claes authored
      For Cycle Analytics, the environment `production` is treated as a
      special case, and used to update the `first_deployed_to_production_at`
      metric.
      
      With the Review Apps changes, slash syntax is used to group related
      environments in the list. This is mostly used for `review/<branch>`
      environments, but it's possible for people to have multiple production
      environments, and someone might then want to group them like
      `production/eu`, `production/us`, or even just make it look prettier
      with `production/www.example.com`. In any of these cases, the first
      deploy to one of these `production/*` environments now is treated as a
      Production deploy.
  28. 19 Dec, 2016 1 commit
  29. 15 Dec, 2016 2 commits
  30. 06 Dec, 2016 1 commit
  31. 21 Nov, 2016 2 commits
  32. 16 Nov, 2016 2 commits