1. 06 Mar, 2019 1 commit
    • Patrick Bajao's avatar
      Allow protected branch creation via web and API · e371520f
      Patrick Bajao authored
      This commit includes changes to add `UserAccess#can_create_branch?`
      which will check whether the user is allowed to create a branch even
      if it matches a protected branch.
      
      This is used in `Gitlab::Checks::BranchCheck` when the branch name
      matches a protected branch.
      
      A `push_to_create_protected_branch` ability in `ProjectPolicy` has been
      added to allow Developers and above to create protected branches.
      e371520f
  2. 06 Dec, 2018 1 commit
    • Stan Hu's avatar
      Remove unnecessary includes of ShellAdapter · e96fd232
      Stan Hu authored
      Determined by running the script:
      
      ```
      included = `git grep --name-only ShellAdapter`.chomp.split("\n")
      used = `git grep --name-only gitlab_shell`.chomp.split("\n")
      included - used
      ```
      e96fd232
  3. 27 Jul, 2018 1 commit
  4. 06 Jun, 2018 1 commit
  5. 24 Apr, 2018 1 commit
  6. 02 Feb, 2018 1 commit
  7. 29 Nov, 2017 1 commit
    • Yorick Peterse's avatar
      Only load branch names for protected branch checks · a0527ab8
      Yorick Peterse authored
      When checking if a branch is protected we don't need all columns of
      every protected branch row, instead we only care about the names. By
      using "select" here we reduce the amount of data we need to send over
      the wire and load into memory.
      a0527ab8
  8. 31 Aug, 2017 1 commit
    • Sean McGivern's avatar
      `current_application_settings` belongs on `Gitlab::CurrentSettings` · 5883ce95
      Sean McGivern authored
      The initializers including this were doing so at the top level, so every object
      loaded after them had a `current_application_settings` method. However, if
      someone had rack-attack enabled (which was loaded before these initializers), it
      would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
      have that method.
      
      To fix this:
      
      1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
         `Object.new.current_application_settings` to work.
      2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
         like that in several places.
      3. Change the initializers to use that new form.
      5883ce95
  9. 31 May, 2017 1 commit
  10. 03 Apr, 2017 4 commits
  11. 31 Mar, 2017 1 commit
  12. 23 Feb, 2017 1 commit
  13. 16 Aug, 2016 1 commit
    • Timothy Andrew's avatar
      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.
      e805a647
  14. 29 Jul, 2016 4 commits
    • Timothy Andrew's avatar
      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.
      0a8aeb46
    • Timothy Andrew's avatar
      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.
      12387b4d
    • Timothy Andrew's avatar
      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`
      134fe5af
    • Timothy Andrew's avatar
      Add models for the protected branch access levels. · 21bece44
      Timothy Andrew authored
      - And hook up their associations.
      21bece44
  15. 07 Jul, 2016 1 commit
    • Timothy Andrew's avatar
      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).
      b1c81f84
  16. 05 Jul, 2016 2 commits
    • Timothy Andrew's avatar
      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.
      2a5cb7ec
    • Timothy Andrew's avatar
      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.
      f51af496
  17. 03 Jun, 2016 2 commits
  18. 09 May, 2016 1 commit
  19. 06 May, 2016 1 commit
  20. 24 Apr, 2015 1 commit
  21. 22 Jan, 2015 1 commit
  22. 26 Jun, 2014 1 commit
  23. 09 Apr, 2014 1 commit
  24. 21 Mar, 2013 1 commit
  25. 04 Feb, 2013 1 commit
  26. 28 Jan, 2013 1 commit
  27. 04 Jan, 2013 1 commit
  28. 03 Jan, 2013 1 commit
  29. 19 Nov, 2012 1 commit
  30. 09 Oct, 2012 2 commits
  31. 27 Sep, 2012 1 commit