An error occurred fetching the project authors.
  1. 15 Aug, 2016 5 commits
  2. 08 Aug, 2016 1 commit
    • Yorick Peterse's avatar
      Added concern for a faster "cache_key" method · 77c8520e
      Yorick Peterse authored
      This concern provides an optimized/simplified version of the "cache_key"
      method. This method is about 9 times faster than the default "cache_key"
      method.
      
      The produced cache keys _are_ different from the previous ones but this
      is worth the performance improvement. To showcase this I set up a
      benchmark (using benchmark-ips) that compares FasterCacheKeys#cache_key
      with the regular cache_key. The output of this benchmark was:
      
          Calculating -------------------------------------
                     cache_key     4.825k i/100ms
                cache_key_fast    21.723k i/100ms
          -------------------------------------------------
                     cache_key     59.422k (± 7.2%) i/s -    299.150k
                cache_key_fast    543.243k (± 9.2%) i/s -      2.694M
      
          Comparison:
                cache_key_fast:   543243.4 i/s
                     cache_key:    59422.0 i/s - 9.14x slower
      
      To see the impact on real code I applied these changes and benchmarked
      Issue#referenced_merge_requests. For an issue referencing 10 merge
      requests these changes shaved off between 40 and 60 milliseconds.
      77c8520e
  3. 29 Jul, 2016 1 commit
    • Yorick Peterse's avatar
      Method for returning issues readable by a user · 002ad215
      Yorick Peterse authored
      The method Ability.issues_readable_by_user takes a list of users and an
      optional user and returns an Array of issues readable by said user. This
      method in turn is used by
      Banzai::ReferenceParser::IssueParser#nodes_visible_to_user so this
      method no longer needs to get all the available abilities just to check
      if a user has the "read_issue" ability.
      
      To test this I benchmarked an issue with 222 comments on my development
      environment. Using these changes the time spent in nodes_visible_to_user
      was reduced from around 120 ms to around 40 ms.
      002ad215
  4. 27 Jul, 2016 1 commit
  5. 20 Jul, 2016 1 commit
  6. 01 Jul, 2016 1 commit
  7. 29 Jun, 2016 1 commit
  8. 24 Jun, 2016 2 commits
  9. 18 Jun, 2016 1 commit
  10. 16 Jun, 2016 2 commits
  11. 13 Jun, 2016 2 commits
  12. 06 Jun, 2016 1 commit
  13. 03 Jun, 2016 2 commits
  14. 01 Jun, 2016 1 commit
    • Yorick Peterse's avatar
      Refactor Participable · 580d2501
      Yorick Peterse authored
      There are several changes to this module:
      
      1. The use of an explicit stack in Participable#participants
      2. Proc behaviour has been changed
      3. Batch permissions checking
      
      == Explicit Stack
      
      Participable#participants no longer uses recursion to process "self" and
      all child objects, instead it uses an Array and processes objects in
      breadth-first order. This allows us to for example create a single
      Gitlab::ReferenceExtractor instance and pass this to any Procs. Re-using
      a ReferenceExtractor removes the need for running potentially many SQL
      queries every time a Proc is called on a new object.
      
      == Proc Behaviour Changed
      
      Previously a Proc in Participable was expected to return an Array of
      User instances. This has been changed and instead it's now expected that
      a Proc modifies the Gitlab::ReferenceExtractor passed to it. The return
      value of the Proc is ignored.
      
      == Permissions Checking
      
      The method Participable#participants uses
      Ability.users_that_can_read_project to check if the returned users have
      access to the project of "self" _without_ running multiple SQL queries
      for every user.
      580d2501
  15. 09 May, 2016 1 commit
  16. 06 May, 2016 1 commit
  17. 20 Apr, 2016 6 commits
  18. 19 Apr, 2016 2 commits
  19. 14 Apr, 2016 1 commit
  20. 12 Apr, 2016 2 commits
    • Timothy Andrew's avatar
      Refactor `Issue#related_branches` · 5d88de09
      Timothy Andrew authored
      - Previously, the controller held the logic to calculate
        related branches, which was:
      
        `<branches ending with `issue.iid`> - <branches with a merge request referenced in the current issue>`
      
      - This logic belongs in the `related_branches` method, not in the
        controller. This commit makes this change.
      
      - This means that `Issue#related_branches` now needs to take a `User`.
        When we find the branches that have a merge request referenced in the
        current issue, this is limited to merge requests that the current user
        has access to.
      
      - This is not directly related to #14566, but is a related refactoring.
      5d88de09
    • Timothy Andrew's avatar
      Sanitize branch names for confidential issues. · 377b59da
      Timothy Andrew authored
      - When creating new branches for confidential issues,
        prefer a branch name like `issue-15` to
        `some-sensitive-issue-title-15`.
      - The behaviour for non-confidential issues stays the same.
      377b59da
  21. 01 Apr, 2016 1 commit
  22. 23 Mar, 2016 1 commit
  23. 20 Mar, 2016 1 commit
  24. 19 Mar, 2016 2 commits