Read about our upcoming Code of Conduct on this issue

  1. 02 Oct, 2017 3 commits
  2. 29 Sep, 2017 3 commits
  3. 28 Sep, 2017 5 commits
  4. 26 Sep, 2017 1 commit
  5. 25 Sep, 2017 5 commits
  6. 23 Sep, 2017 1 commit
  7. 22 Sep, 2017 1 commit
  8. 20 Sep, 2017 3 commits
    • Yorick Peterse's avatar
      Stop using Sidekiq for updating Key#last_used_at · 592d3ec60a59
      Yorick Peterse authored
      This makes things simpler as no scheduling is involved. Further we
      remove the need for running a SELECT + UPDATE just to get the key and
      update it, whereas we only need an UPDATE when setting last_used_at
      directly in a request.
      
      The added service class takes care of updating Key#last_used_at without
      using Sidekiq. Further it makes sure we only try to obtain a Redis lease
      if we're confident that we actually need to do so, instead of always
      obtaining it. We also make sure to _only_ update last_used_at instead of
      also updating updated_at.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36663
      592d3ec60a59
    • Yorick Peterse's avatar
      Remove redundant WHERE from event queries · a512957310b8
      Yorick Peterse authored
      The default scope in Event would add a "WHERE author_id IS NOT NULL"
      clause to every query. Now that "events.author_id" has a NOT NULL clause
      set this filter is redundant and we can safely remove it.
      
      In this commit we also add a validation on events.author_id (previously
      only defined in PushEvent) just in case something tries to create data
      without an author ID. This way we can present a nicer error message
      compared to PostgreSQL's foreign key error messages.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38129
      a512957310b8
    • Grzegorz Bizon's avatar
      7dd2d4553ae8
  9. 19 Sep, 2017 4 commits
  10. 18 Sep, 2017 5 commits
  11. 15 Sep, 2017 4 commits
    • Yorick Peterse's avatar
      Fix setting share_with_group_lock · c5f0e09eb838
      Yorick Peterse authored
      Prior to this commit running
      Namespace#force_share_with_group_lock_on_descendants would result in
      updating _all_ namespaces in the namespaces table, not just the
      descendants. This is the result of ActiveRecord::Relation#update_all not
      taking into account the CTE. To work around this we use the CTE query as
      a sub-query instead of directly calling #update_all.
      
      To prevent this from happening the relations returned by
      Gitlab::GroupHierarchy are now marked as read-only, resulting in an
      error being raised when methods such as #update_all are used.
      
      Fortunately on GitLab.com our statement timeouts appear to have
      prevented this query from actually doing any damage other than causing
      a very large amount of dead tuples.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37916
      c5f0e09eb838
    • haseeb's avatar
      created services for keys · e35fb58734d1
      haseeb authored
      e35fb58734d1
    • Jacob Vosmaer's avatar
      Prepare Repository#merge for migration to Gitaly · 48c3a539cb42
      Jacob Vosmaer authored
      48c3a539cb42
    • Zeger-Jan van de Weg's avatar
      Allow updating of project auto devops settings · 00918abcd2d0
      Zeger-Jan van de Weg authored
      Updating didn't work, as the project_id was missing to be set for the
      project_auto_devops model.
      
      Fixes gitlab-org/gitlab-ce#37893
      00918abcd2d0
  12. 14 Sep, 2017 4 commits
  13. 13 Sep, 2017 1 commit
    • Yorick Peterse's avatar
      Constrain environment deployments to project IDs · 98f4339ff129
      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
      98f4339ff129