BigW Consortium Gitlab

  1. 16 Aug, 2016 1 commit
    • Backport changes from gitlab-org/gitlab-ee!581 to CE. · e805a647
      Timothy Andrew authored
      !581 has a lot of changes that would cause merge conflicts if not
      properly backported to CE. This commit/MR serves as a better
      foundation for gitlab-org/gitlab-ee!581.
      
      = Changes =
      
      1. Move from `has_one {merge,push}_access_level` to `has_many`, with the
         `length` of the association limited to `1`. This is _effectively_ a
         `has_one` association, but should cause less conflicts with EE, which
         is set to `has_many`. This has a number of related changes in the
         views, specs, and factories.
      
      2. Make `gon` variable loading more consistent (with EE!581) in the
         `ProtectedBranchesController`. Also use `::` to prefix the
         `ProtectedBranches` services, because this is required in EE.
      
      3. Extract a `ProtectedBranchAccess` concern from the two access level
         models. This concern only has a single `humanize` method here, but
         will have more methods in EE.
      
      4. Add `form_errors` to the protected branches creation form. This is
         not strictly required for EE compatibility, but was an oversight
         nonetheless.
  2. 29 Jul, 2016 4 commits
    • Use `Gitlab::Access` to protected branch access levels. · 0a8aeb46
      Timothy Andrew authored
      1. It makes sense to reuse these constants since we had them duplicated
         in the previous enum implementation. This also simplifies our
         `check_access` implementation, because we can use
         `project.team.max_member_access` directly.
      
      2. Use `accepts_nested_attributes_for` to create push/merge access
         levels. This was a bit fiddly to set up, but this simplifies our code
         by quite a large amount. We can even get rid of
         `ProtectedBranches::BaseService`.
      
      3. Move API handling back into the API (previously in
         `ProtectedBranches::BaseService#translate_api_params`.
      
      4. The protected branch services now return a `ProtectedBranch` rather
         than `true/false`.
      
      5. Run `load_protected_branches` on-demand in the `create` action, to
         prevent it being called unneccessarily.
      
      6. "Masters" is pre-selected as the default option for "Allowed to Push"
         and "Allowed to Merge".
      
      7. These changes were based on a review from @rymai in !5081.
    • Allow setting "Allowed To Push/Merge" while creating a protected branch. · 12387b4d
      Timothy Andrew authored
      1. Reuse the same dropdown component that we used for updating these
         settings (`ProtectedBranchesAccessSelect`). Have it accept options
         for the parent container (so we can control the elements it sees) and
         whether or not to save changes via AJAX (we need this for update, but
         not create).
      
      2. Change the "Developers" option to "Developers + Masters", which is
         clearer.
      
      3. Remove `developers_can_push` and `developers_can_merge` from the
         model, since they're not needed anymore.
    • Use the `{Push,Merge}AccessLevel` models in the UI. · 134fe5af
      Timothy Andrew authored
      1. Improve error handling while creating protected branches.
      
      2. Modify coffeescript code so that the "Developers can *" checkboxes
         send a '1' or '0' even when using AJAX. This lets us keep the backend
         code simpler.
      
      3. Use services for both creating and updating protected branches.
         Destruction is taken care of with `dependent: :destroy`
    • Add models for the protected branch access levels. · 21bece44
      Timothy Andrew authored
      - And hook up their associations.
  3. 07 Jul, 2016 1 commit
    • Have `Project#open_branches` return branches that are matched by a wildcard protected branch. · b1c81f84
      Timothy Andrew authored
      1. The `open_branches` method is used to provide a list of branches
         while creating a protected branch.
      
      2. It makes sense to include branches which are matched by one or more
         wildcard protected branches, since the user might want to make exact
         protected branches from these as well.
      
      3. This also provides a large performance improvement. On my machine, in
         a project with 5000 branches and 2000 protected branches, the
         `ProtectedBranches#index` page went from a 40 seconds load time to 4
         seconds (10x speedup).
  4. 05 Jul, 2016 2 commits
    • Modify the frontend for wildcard protected branches. · 2a5cb7ec
      Timothy Andrew authored
      1. Allow entering any branch name for a protected branch.
      
          - Either pick from a list of options, or enter it manually
          - You can enter wildcards.
      
      2. Display branches matching a protected branch.
      
          -  Add a `ProtectedBranches#show` page that displays the branches
             matching the given protected branch, or a message if there are no
             matches.
      
          - On the `index` page, display the last commit for an exact match,
            or the number of matching branches for a wildcard match.
      
          -  Add an `iid` column to `protected_branches` - this is what we use for
             the `show` page URL.
      
          -  On the off chance that this feature is unnecessary, this commit
             encapsulates it neatly, so it can be removed without affecting
             anything else.
      
      3. Remove the "Last Commit" column from the list of protected branches.
      
          - There's no way to pull these for wildcard protected branches, so it's
            best left for the `show` page.
      
          - Rename the `@branches` instance variable to `@protected_branches`
      
          - Minor styling changes with the "Unprotect" button - floated right
            like the "Revoke" button for personal access tokens
      
      4. Paginate the list of protected branches.
      
      5. Move the instructions to the left side of the page.
    • Support wildcard matches for protected branches at the model level. · f51af496
      Timothy Andrew authored
      1. The main implementation is in the `ProtectedBranch` model. The
         wildcard is converted to a Regex and compared. This has been tested
         thoroughly.
      
          - While `Project#protected_branch?` is the main entry point,
            `project#open_branches` and
            `project#developers_can_push_to_protected_branch?`
            have also been modified to work with wildcard protected branches.
      
          - The regex is memoized (within the `ProtectedBranch` instance)
      
      2. Improve the performance of `Project#protected_branch?`
      
          -  This method is called from `Project#open_branches` once _per branch_
             in the project, to check if that branch is protected or not.
      
          -  Before, `#protected_branch?` was making a database call every
             time it was invoked (in the above case, that amounts to once
             per branch), which is expensive.
      
          -  This commit caches the list of protected branches in memory, which
             reduces the number of database calls down to 1.
      
          -  A downside to this approach is that `#protected_branch?` _could_
             return a stale value (due to the caching), but this is
             an acceptable tradeoff.
      
      3. Remove the (now) unused `Project#protected_branch_names` method.
      
          - This was previously used to check for protected branch status.
  5. 03 Jun, 2016 2 commits
  6. 09 May, 2016 1 commit
    • Remove the annotate gem and delete old annotations · f1479b56
      Jeroen van Baarsen authored
      In 8278b763 the default behaviour of annotation
      has changes, which was causing a lot of noise in diffs. We decided in #17382
      that it is better to get rid of the whole annotate gem, and instead let people
      look at schema.rb for the columns in a table.
      
      Fixes: #17382
  7. 06 May, 2016 1 commit
  8. 24 Apr, 2015 1 commit
  9. 22 Jan, 2015 1 commit
  10. 26 Jun, 2014 1 commit
  11. 09 Apr, 2014 1 commit
  12. 21 Mar, 2013 1 commit
  13. 04 Feb, 2013 1 commit
  14. 28 Jan, 2013 1 commit
  15. 04 Jan, 2013 1 commit
  16. 03 Jan, 2013 1 commit
  17. 19 Nov, 2012 1 commit
  18. 09 Oct, 2012 2 commits
  19. 27 Sep, 2012 2 commits
  20. 26 Sep, 2012 1 commit
  21. 02 Sep, 2012 1 commit
  22. 28 Aug, 2012 1 commit
    • Use similar interface to access gitolite · 7cdc5b9e
      randx authored
      Simplified gitolite handle logic
      Stubn over monkeypatch
      Stub only specific methods in Gitlab:Gitolite
      Moved grach auth to lib
      added specs for keys observer
      removes SshKey role
  23. 26 Jun, 2012 1 commit
  24. 26 May, 2012 1 commit
  25. 05 Mar, 2012 1 commit
  26. 15 Feb, 2012 1 commit