1. 22 Jan, 2019 1 commit
  2. 11 Jul, 2018 1 commit
  3. 05 Jul, 2018 1 commit
  4. 27 Jun, 2018 1 commit
  5. 06 Jun, 2018 1 commit
  6. 23 May, 2018 1 commit
  7. 04 Apr, 2018 1 commit
  8. 11 Oct, 2017 1 commit
  9. 07 Oct, 2017 1 commit
  10. 05 Oct, 2017 1 commit
  11. 25 Sep, 2017 1 commit
  12. 20 Sep, 2017 1 commit
  13. 27 Jul, 2017 1 commit
  14. 06 Jul, 2017 1 commit
  15. 05 Jul, 2017 1 commit
  16. 29 Jun, 2017 1 commit
  17. 20 Jun, 2017 1 commit
  18. 17 Jun, 2017 1 commit
  19. 14 Jun, 2017 1 commit
  20. 07 Jun, 2017 1 commit
  21. 16 May, 2017 1 commit
  22. 29 Apr, 2017 1 commit
  23. 21 Apr, 2017 1 commit
  24. 20 Apr, 2017 1 commit
  25. 19 Aug, 2016 1 commit
  26. 16 Aug, 2016 3 commits
    • Timothy Andrew's avatar
      Backport EE assertions in protected branch related specs. · 8c101fc3
      Timothy Andrew authored
      - Use assertions in the vein of `merge_access_levels.map(&:access_level)`
        instead of `merge_access_levels.first.access_level`
    • Timothy Andrew's avatar
      Don't select an access level if already selected. · 4c28d626
      Timothy Andrew authored
      1. This is in regard to the protected branches feature spec.
      2. For example, if "Masters" is already selected, don't re-select
         "Masters" during the spec.
      3. This is due to a bug in the frontend implementation, where selecting
         an already-selected access level _deselects_ it, which is something
         we don't need. I'll create a separate issue for this.
      4. This hasn't turned up before, because we were manually creating
         missing access levels prior to e805a647. Now, we just use nested
         attributes, and missing access levels fail validation.
    • 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
  27. 06 Aug, 2016 3 commits
  28. 29 Jul, 2016 5 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
      3. Move API handling back into the API (previously in
      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.
    • Timothy Andrew's avatar
      Implement review comments from @axil. · 88fd401d
      Timothy Andrew authored
      1. Align "Allowed to Merge" and "Allowed to Push" dropdowns.
      2. Don't display a flash every time a protected branch is updated.
         Previously, we were using this so the test has something to hook onto
         before the assertion. Now we're using `wait_for_ajax` instead.
    • Timothy Andrew's avatar
      Make specs compatible with PhantomJS versions < 2. · 4d6dadc8
      Timothy Andrew authored
      1. These versions of PhantomJS don't support `PATCH` requests, so we use
         a `POST` with `_method` set to `PATCH`.
    • Timothy Andrew's avatar
      Humanize protected branches' access levels at one location. · f2df2966
      Timothy Andrew authored
      1. The model now contains this humanization data, which is the once
         source of truth.
      2. Previously, this was being listed out in the dropdown component as well.
    • Timothy Andrew's avatar
      Update protected branches spec to work with the `select`s. · 9fa66147
      Timothy Andrew authored
      1. Get the existing spec passing.
      2. Add specs for all the access control options, both while creating and
         updating protected branches.
      3. Show a flash notice when updating protected branches, primarily so
         the spec knows when the update is done.
  29. 07 Jul, 2016 1 commit
    • Timothy Andrew's avatar
      Use the `GLDropdown` component to select protected branches. · d8d5424d
      Timothy Andrew authored
      1. Modify the component to support a callback for every key press in the
         filter. We need this so we can update the "Create: <branch_name"
      2. Modify the component to use `$(<selector>).first().click()` instead
         of `$(selector)[0].click()`, because the latter is non-standard, and
         doesn't work in PhantomJS.
  30. 05 Jul, 2016 1 commit
    • Timothy Andrew's avatar
      Add a feature spec for protected branch creation. · d8475276
      Timothy Andrew authored
      1. Doesn't seem like there's an easy way to do this for the actual
         branch protection, since we'd have to test an actual `git push`.
      2. Testing branch creation the web UI is also not straightforward,
         since the factory repo doesn't have any hooks, and so access checks
         at the `gitlab-shell` level aren't run.