Read about our upcoming Code of Conduct on this issue

  1. 11 Jul, 2018 1 commit
  2. 09 Jul, 2018 2 commits
  3. 02 Jul, 2018 1 commit
  4. 26 Jun, 2018 1 commit
  5. 07 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Fix some N+1s when calculating notification recipients · 3516463bc414
      Sean McGivern authored
      First N+1: we may have loaded a user's notification settings already, but not
      have loaded their sources. Because we're iterating through, we'd potentially
      load sources that are completely unrelated, just because they belong to this
      user.
      
      Second N+1: we do a separate query for each user who could be subscribed to or
      unsubcribed from the target. It's actually more efficient in this case to get
      all subscriptions at once, as we will need to check most of them.
      
      We can fix both by the slightly unpleasant means of checking IDs manually,
      rather than object equality.
      3516463bc414
  6. 31 May, 2018 1 commit
  7. 22 May, 2018 1 commit
  8. 21 May, 2018 1 commit
  9. 17 May, 2018 1 commit
  10. 16 May, 2018 4 commits
    • Dylan Griffith's avatar
      f53ae86bec1b
    • Dylan Griffith's avatar
      Allow group runners to be viewed/edited in API · d55e1d6a4062
      Dylan Griffith authored
      d55e1d6a4062
    • Jan Provaznik's avatar
      Changed order of include · 33c7dfb1ce05
      Jan Provaznik authored
      33c7dfb1ce05
    • Jan Provaznik's avatar
      Delete remote uploads · 9cb2812d4482
      Jan Provaznik authored
      ObjectStore uploader requires presence of associated `uploads` record
      when deleting the upload file (through the carrierwave's after_commit
      hook) because we keep info whether file is LOCAL or REMOTE in `upload`
      object.
      
      For this reason we can not destroy uploads as "dependent: :destroy" hook
      because these would be deleted too soon. Instead we rely on
      carrierwave's hook to destroy `uploads` in after_commit hook.
      
      But in before_destroy hook we still have to delete not-mounted uploads
      (which don't use carrierwave's destroy hook). This has to be done in
      before_Destroy instead of after_commit because `FileUpload` requires
      existence of model's object on destroy action.
      
      This is not ideal state of things, in a next step we should investigate
      how to unify model dependencies so we can use same workflow for all
      uploads.
      
      Related to #45425
      9cb2812d4482
  11. 14 May, 2018 1 commit
  12. 10 May, 2018 2 commits
  13. 04 May, 2018 1 commit
  14. 30 Apr, 2018 1 commit
  15. 28 Apr, 2018 1 commit
    • blackst0ne's avatar
      [Rails5] Fix `params` for DeleteUserWorker · 8457742c3619
      blackst0ne authored
      This commit fixes the error:
      
      ```
        1) Admin::UsersController DELETE #user with projects deletes the user and their contributions when hard delete is specified
           Failure/Error: Users::DestroyService.new(current_user).execute(delete_user, options.symbolize_keys)
      
           NoMethodError:
             undefined method `symbolize_keys' for "{\"hard_delete\"=>\"true\"}":String
           # ./app/workers/delete_user_worker.rb:8:in `perform'
           # ./lib/gitlab/sidekiq_status/server_middleware.rb:5:in `call'
           # ./config/initializers/forbid_sidekiq_in_transactions.rb:35:in `block (2 levels) in <module:NoEnqueueingFromTransactions>'
           # ./app/models/user.rb:913:in `delete_async'
           # ./app/controllers/admin/users_controller.rb:148:in `destroy'
           # ./lib/gitlab/i18n.rb:50:in `with_locale'
           # ./lib/gitlab/i18n.rb:56:in `with_user_locale'
           # ./app/controllers/application_controller.rb:327:in `set_locale'
           # ./spec/controllers/admin/users_controller_spec.rb:28:in `block (3 levels) in <top (required)>'
      
      Finished in 6.81 seconds (files took 13.9 seconds to load)
      1 example, 1 failure
      ```
      8457742c3619
  16. 23 Apr, 2018 1 commit
  17. 19 Apr, 2018 1 commit
    • blackst0ne's avatar
      [Rails5] Fix `User#manageable_groups` · fc7c27524d46
      blackst0ne authored
      In `arel 7.0` (`7.1.4` version is used for rails5) there were introduced
      some changes that break our code in the `User#manageable_groups` method.
      
      The problem is that `arel_table[:id].in(Arel::Nodes::SqlLiteral)` generates
      wrong `IN ()` construction. The selection for `IN` is missing:
      
      => "\"namespaces\".\"id\" IN (0)"
      
      That caused such spec errors for the `rails5` branch:
      
      ```
      4) User groups with child groups #manageable_groups does not include duplicates if a membership was added for the subgroup
          Failure/Error: expect(user.manageable_groups).to contain_exactly(group, subgroup)
      
            expected collection contained:  [#<Group id:232 @group29>, #<Group id:234 @group29/group30>]
            actual collection contained:    []
            the missing elements were:      [#<Group id:232 @group29>, #<Group id:234 @group29/group30>]
          # ./spec/models/user_spec.rb:699:in `block (5 levels) in <top (required)>'
          # ./spec/spec_helper.rb:188:in `block (2 levels) in <top (required)>'
          # /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:112:in `block in run'
          # /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:101:in `loop'
          # /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:101:in `run'
          # /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec_ext/rspec_ext.rb:12:in `run_with_retry'
          # /var/lib/gems/2.3.0/gems/rspec-retry-0.4.6/lib/rspec/retry.rb:30:in `block (2 levels) in setup'
      ```
      
      This commit changes `User#manageable_groups` in the way to drop the usage of
      `Arel::Nodes::SqlLiteral` and adds usage of raw SQL query.
      This change should be updated when we're migrated to Rails 5.2 because arel
      was fixed in `9.0.0` (which is used in Rails 5.2).
      fc7c27524d46
  18. 18 Apr, 2018 1 commit
    • Yorick Peterse's avatar
      Revert the addition of goldiloader · be0c0cc36a37
      Yorick Peterse authored
      This reverts the addition of the "goldiloader" Gem and all use of it.
      While this Gem is very promising it's causing a variety of problems on
      GitLab.com due to it eager-loading too much data in places where we
      don't expect/can handle this. At least for the time being this means we
      have to go back to manually fixing N+1 query problems, but at least
      those should not cause a negative impact on availability.
      be0c0cc36a37
  19. 09 Apr, 2018 5 commits
  20. 06 Apr, 2018 2 commits
  21. 05 Apr, 2018 2 commits
  22. 04 Apr, 2018 1 commit
  23. 28 Mar, 2018 1 commit
  24. 27 Mar, 2018 1 commit
  25. 26 Mar, 2018 1 commit
  26. 07 Mar, 2018 2 commits
  27. 02 Mar, 2018 1 commit
  28. 28 Feb, 2018 1 commit