An error occurred fetching the project authors.
  1. 18 Aug, 2016 4 commits
  2. 16 Aug, 2016 2 commits
    • Timothy Andrew's avatar
      Improve EE compatibility with protected branch access levels. · 4ddbbcd1
      Timothy Andrew authored
      1. Change a few incorrect `access_level` to `access_levels.first` that
         were missed in e805a647.
      
      2. `API::Entities` can iterate over all access levels instead of just
         the first one. This makes no difference to CE, and makes it more compatible
         with EE.
      4ddbbcd1
    • 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
  3. 10 Aug, 2016 2 commits
    • Rémy Coutable's avatar
      Improve the performance of the GET /:sources/:id/{access_requests,members} API endpoints · 5010be77
      Rémy Coutable authored
      The performance was greatly improved by removing two N+1 queries issues
      for each endpoint.
      
      For comparison:
      
      1. `GET /projects/:id/members`
      
      With two N+1 queries issues (one was already fxed in the following
      snippet):
      
      ```
        ProjectMember Load (0.2ms)  SELECT "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
      NULL  ORDER BY "members"."id" DESC  [["source_type", "Project"],
      ["source_id", 1], ["source_type", "Project"]]
        User Load (0.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN
      (5, 22, 16, 13)  ORDER BY "users"."id" DESC
        ActiveRecord::SchemaMigration Load (0.2ms)  SELECT
      "schema_migrations".* FROM "schema_migrations"
        ProjectMember Load (0.3ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
      NULL AND "members"."user_id" = $4  ORDER BY "members"."id" DESC LIMIT 1
      [["source_type", "Project"], ["source_id", 1], ["source_type",
      "Project"], ["user_id", 5]]
        ProjectMember Load (0.3ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
      NULL AND "members"."user_id" = $4  ORDER BY "members"."id" DESC LIMIT 1
      [["source_type", "Project"], ["source_id", 1], ["source_type",
      "Project"], ["user_id", 22]]
        ProjectMember Load (0.3ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
      NULL AND "members"."user_id" = $4  ORDER BY "members"."id" DESC LIMIT 1
      [["source_type", "Project"], ["source_id", 1], ["source_type",
      "Project"], ["user_id", 16]]
        ProjectMember Load (0.3ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
      NULL AND "members"."user_id" = $4  ORDER BY "members"."id" DESC LIMIT 1
      [["source_type", "Project"], ["source_id", 1], ["source_type",
      "Project"], ["user_id", 13]]
      ```
      
      Without the N+1 queries issues:
      
      ```
        ProjectMember Load (0.3ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND "members"."requested_at" IS
      NULL  ORDER BY "members"."id" DESC LIMIT 20 OFFSET 0  [["source_type",
      "Project"], ["source_id", 1], ["source_type", "Project"]]
        User Load (0.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN
      (5, 22, 16, 13)  ORDER BY "users"."id" DESC
      ```
      
      2. `GET /projects/:id/access_requests`
      
      With two N+1 queries issues:
      
      ```
        ProjectMember Load (0.3ms)  SELECT "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
      NOT NULL)  ORDER BY "members"."id" DESC  [["source_type", "Project"],
      ["source_id", 8], ["source_type", "Project"]]
        User Load (0.1ms)  SELECT  "users".* FROM "users" WHERE "users"."id" =
      $1  ORDER BY "users"."id" DESC LIMIT 1  [["id", 24]]
        User Load (0.1ms)  SELECT  "users".* FROM "users" WHERE "users"."id" =
      $1  ORDER BY "users"."id" DESC LIMIT 1  [["id", 23]]
        ActiveRecord::SchemaMigration Load (0.2ms)  SELECT
      "schema_migrations".* FROM "schema_migrations"
        ProjectMember Load (0.1ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
      NOT NULL) AND "members"."user_id" = $4  ORDER BY "members"."id" DESC
      LIMIT 1  [["source_type", "Project"], ["source_id", 8], ["source_type",
      "Project"], ["user_id", 24]]
        ProjectMember Load (0.2ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
      NOT NULL) AND "members"."user_id" = $4  ORDER BY "members"."id" DESC
      LIMIT 1  [["source_type", "Project"], ["source_id", 8], ["source_type",
      "Project"], ["user_id", 23]]
      ```
      
      Without the N+1 queries issues:
      
      ```
        ProjectMember Load (0.3ms)  SELECT  "members".* FROM "members" WHERE
      "members"."source_type" = $1 AND "members"."type" IN ('ProjectMember')
      AND "members"."source_id" = $2 AND "members"."source_type" = $3 AND
      "members"."type" IN ('ProjectMember') AND ("members"."requested_at" IS
      NOT NULL)  ORDER BY "members"."id" DESC LIMIT 20 OFFSET 0
      [["source_type", "Project"], ["source_id", 8], ["source_type",
      "Project"]]
        User Load (0.5ms)  SELECT "users".* FROM "users" WHERE "users"."id" IN
      (24, 23)  ORDER BY "users"."id" DESC
      ```
      Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
      5010be77
    • Rémy Coutable's avatar
      New AccessRequests API endpoints for Group & Project · 29850364
      Rémy Coutable authored
      Also, mutualize AccessRequests and Members endpoints for Group &
      Project.
      New API documentation for the AccessRequests endpoints.
      Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
      29850364
  4. 03 Aug, 2016 1 commit
  5. 02 Aug, 2016 1 commit
  6. 29 Jul, 2016 3 commits
    • Z.J. van de Weg's avatar
      Add API support for environments · 84cd2120
      Z.J. van de Weg authored
      84cd2120
    • 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
      Have the `branches` API work with the new protected branches data model. · 01d190a8
      Timothy Andrew authored
      1. The new data model moves from `developers_can_{push,merge}` to
         `allowed_to_{push,merge}`.
      
      2. The API interface has not been changed. It still accepts
         `developers_can_push` and `developers_can_merge` as options. These
         attributes are inferred from the new data model.
      
      3. Modify the protected branch create/update services to translate from
         the API interface to our current data model.
      01d190a8
  7. 28 Jul, 2016 1 commit
  8. 19 Jul, 2016 3 commits
  9. 18 Jul, 2016 2 commits
  10. 12 Jul, 2016 9 commits
  11. 11 Jul, 2016 2 commits
  12. 08 Jul, 2016 4 commits
  13. 06 Jul, 2016 3 commits
  14. 01 Jul, 2016 3 commits