1. 13 Jul, 2016 6 commits
    • Robert Speicher's avatar
      Revert "Merge branch '18193-developers-can-merge' into 'master' · 530f5158
      Robert Speicher authored
      This reverts commit 9ca633eb, reversing
      changes made to fb229bbf.
      530f5158
    • Timothy Andrew's avatar
    • Timothy Andrew's avatar
      Appease rubocop. · 4d00ed21
      Timothy Andrew authored
      4d00ed21
    • Timothy Andrew's avatar
      Refactor `Gitlab::GitAccess` · 60245bbe
      Timothy Andrew authored
      1. Don't use case statements for dispatch anymore. This leads to a lot
         of duplication, and makes the logic harder to follow.
      
      2. Remove duplicated logic.
      
          - For example, the `can_push_to_branch?` exists, but we also have a
            different way of checking the same condition within `change_access_check`.
      
          - This kind of duplication is removed, and the `can_push_to_branch?`
            method is used in both places.
      
      3. Move checks returning true/false to `UserAccess`.
      
          - All public methods in `GitAccess` now return an instance of
            `GitAccessStatus`. Previously, some methods would return
            true/false as well, which was confusing.
      
          - It makes sense for these kinds of checks to be at the level of a
            user, so the `UserAccess` class was repurposed for this. The prior
            `UserAccess.allowed?` classmethod is converted into an instance
            method.
      
          - All external uses of these checks have been migrated to use the
            `UserAccess` class
      
      4. Move the "change_access_check" into a separate class.
      
          - Create the `GitAccess::ChangeAccessCheck` class to run these
            checks, which are quite substantial.
      
          - `ChangeAccessCheck` returns an instance of `GitAccessStatus` as
            well.
      
      5. Break out the boolean logic in `ChangeAccessCheck` into `if/else`
         chains - this seems more readable.
      
      6. I can understand that this might look like overkill for !4892, but I
         think this is a good opportunity to clean it up.
      
          - http://martinfowler.com/bliki/OpportunisticRefactoring.html
      60245bbe
    • Timothy Andrew's avatar
      Enforce "developers can merge" during `pre-receive`. · 495db096
      Timothy Andrew authored
      1. When a merge request is being merged, save the merge commit SHA in
         the `in_progress_merge_commit_sha` database column.
      
      2. The `pre-receive` hook looks for any locked (in progress) merge
         request with `in_progress_merge_commit_sha` matching the `newrev` it
         is passed.
      
      3. If it finds a matching MR, the merge is legitimate.
      
      4. Update `git_access_spec` to test the behaviour we added here. Also
         refactored this spec a bit to make it easier to add more contexts / conditions.
      495db096
    • Mathias Vestergaard's avatar
      Added "developers can merge" setting to protected branches · f0577d83
      Mathias Vestergaard authored
      - Cherry-picked from `mvestergaard:branch-protection-dev-merge`
      - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220
      f0577d83
  2. 05 Jul, 2016 7 commits
  3. 09 May, 2016 1 commit
    • Stan Hu's avatar
      Improve multiple branch push performance by memoizing permission checking · 4be77d0b
      Stan Hu authored
      If you attempt to push thousands of branches at once, the 60-second timeout
      will occur because GitAccess checking does a lot of work to check if the
      user has permission to push to a branch. This changes does two things:
      
      1. Instead of making 1 DB query per branch push, use a memoized list of protected branches to check
      2. Memoize what permissions the user has to perform on this project
      
      On a test of 10,000 branch pushes, this prevents gitlab-shell from hitting the 60-second
      timeout.
      
      Closes #17225
      4be77d0b
  4. 05 May, 2016 2 commits
    • Yorick Peterse's avatar
      Fix passing nil to protected_tag? · 00367120
      Yorick Peterse authored
      Previously this method would directly receive the output of tag_name().
      This method could either return a String or nil. In the previous setup
      this would somehow magically work but because Rugged::TagCollection#[]
      doesn't accept nil values it started to fail.
      
      To work around this the elsif in change_access_check() assigns the
      result of tag_name() to a local and then _only_ calls protected_tag?()
      if the tag name is not nil. The extra parenthesis are put in place to
      ensure that things are parsed correctly, without these the code would be
      parsed as follows:
      
          elsif tag_ref = (tag_name(ref) && protected_tag(tag_ref))
      
      During runtime this would basically resolve to:
      
          elsif tag_ref = (tag_name(ref) && protected_tag(nil))
      
      This is because when you refer to the variable you're assigning _in_ the
      assignment Ruby returns nil instead of raising an error.
      00367120
    • Yorick Peterse's avatar
      Use tag_exists? in GitAccess#protected_tag? · 93ce2296
      Yorick Peterse authored
      This removes the need for retrieving the entire list of tags just to
      check if a specific one exists.
      93ce2296
  5. 16 Nov, 2015 1 commit
  6. 13 May, 2015 2 commits
  7. 25 Mar, 2015 1 commit
  8. 24 Mar, 2015 1 commit
  9. 10 Mar, 2015 1 commit
  10. 18 Feb, 2015 1 commit
  11. 03 Feb, 2015 2 commits
  12. 29 Jan, 2015 1 commit
  13. 21 Jan, 2015 1 commit
  14. 26 Dec, 2014 3 commits
  15. 05 Dec, 2014 1 commit
  16. 02 Dec, 2014 1 commit
  17. 01 Dec, 2014 1 commit
  18. 18 Nov, 2014 1 commit
  19. 03 Nov, 2014 1 commit
  20. 07 Oct, 2014 1 commit
  21. 23 Sep, 2014 1 commit
  22. 01 Sep, 2014 1 commit
  23. 30 May, 2014 1 commit
  24. 22 May, 2014 1 commit