BigW Consortium Gitlab

  1. 12 May, 2017 1 commit
  2. 10 May, 2017 1 commit
  3. 06 Apr, 2017 1 commit
  4. 04 Apr, 2017 1 commit
  5. 29 Nov, 2016 1 commit
  6. 24 Oct, 2016 2 commits
    • Implement review comments from @DouweM. · b803bc7b
      Timothy Andrew authored
    • Fix branch protection API. · f79f3a1d
      Timothy Andrew authored
      1. Previously, we were not removing existing access levels before
         creating new ones. This is not a problem for EE, but _is_ for CE,
         since we restrict the number of access levels in CE to 1.
      
      2. The correct approach is:
      
          CE -> delete all access levels before updating a protected branch
          EE -> delete developer access levels if "developers_can_{merge,push}" is switched off
      
      3. The dispatch is performed by checking if a "length: 1" validation is
         present on the access levels or not.
      
      4. Another source of problems was that we didn't put multiple queries in
         a transaction. If the `destroy_all` passes, but the `update` fails,
         we should have a rollback.
      
      5. Modifying the API to provide users direct access to CRUD access
         levels will make things a lot simpler.
      
      6. Create `create/update` services separately for this API, which
         perform the necessary data translation, before calling the regular
         `create/update` services. The translation code was getting too large
         for the API endpoint itself, so this move makes sense.
  7. 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.