An error occurred fetching the project authors.
  1. 03 Jan, 2020 1 commit
    • Bob Van Landuyt's avatar
      Wrap requests in an ApplicationContext · 3c5be56e
      Bob Van Landuyt authored
      This provides context to all requests made to Rails controllers or
      grape endpoints.
      
      Doing this starts a new `Labkit::Context`, to which we can provide a
      namespace, project and user.
      
      We're currently setting the following values:
      
      - Web requests: In the ApplicationController we wrap the entire
        request in a `with_context`.
        - user: based on the `auth_user` if there is one
        - project: We try to read the @project instance variable of the
          controller.
        - namespace: We try to read the @group instance variable of the
          controller. If there was none, but the project was set, we'll use
          that path to set the namespace
      
      - API requests: The application context is pushed in a before block
        setting the following values:
        - user: to `current_user` if there is one
        - project: to `@project`
        - namespace: to `@group`
      
      - Internal API requests: the application context is pushed in a before
        block:
        - user: When to the user set in `Api::Support::GitAccessActor`
        - project: to @project if it was available
      
      The 3 supported attributes for a context are read lazily when
      required.
      
      This also replaces the existing correlation middlewares with the new
      Labkit::Context middlewares.
      
      The rack middleware wraps each rack request in an overarching context
      that adds the correlation id. The context is cleaned up after the
      request, so we're sure all child contexts are cleaned up as well.
      
      The sidekiq client middleware will write the context into the job that
       goes into redis when a job is scheduled.
      
      The sidekiq server middleware will then re-instantiate this context so
      the job gets executed with the same context that was alive when it was
      scheduled. This means that any new job scheduled from sidekiq would
      also have this context.
      3c5be56e
  2. 27 Dec, 2019 1 commit
  3. 24 Dec, 2019 1 commit
  4. 18 Dec, 2019 1 commit
  5. 12 Dec, 2019 2 commits
  6. 05 Dec, 2019 1 commit
  7. 03 Dec, 2019 1 commit
  8. 19 Nov, 2019 1 commit
  9. 28 Oct, 2019 1 commit
  10. 24 Oct, 2019 1 commit
  11. 21 Oct, 2019 1 commit
  12. 10 Oct, 2019 1 commit
  13. 09 Oct, 2019 2 commits
  14. 24 Sep, 2019 1 commit
  15. 04 Sep, 2019 1 commit
  16. 03 Sep, 2019 1 commit
  17. 28 Aug, 2019 1 commit
  18. 10 Jul, 2019 1 commit
  19. 09 Jul, 2019 1 commit
  20. 17 May, 2019 1 commit
  21. 03 May, 2019 1 commit
  22. 16 Apr, 2019 1 commit
    • Luke Duncalfe's avatar
      Fix logic in Api::Internal test · 37492c5d
      Luke Duncalfe authored
      The intention of this test is to ensure that the service class
      MergeRequests::PushOptionsHandlerService does not run when the
      :mr_push_options feature flag is disabled.
      
      This test was passing, however was not testing what it was supposed to
      be!
      
      For one, setting Feature.disable(:feature) in the test does not disable
      the feature, as rspec config in spec_helper stubs Feature to make all
      features enabled:
      
      https://gitlab.com/gitlab-org/gitlab-ce/commit/3ee48e422defaedd69946c607bd8d3672e510375
      
      So the feature was still enabled in the test.
      
      But this test wasn't failing because unfortunately I had put:
      
      ```
      expect(MergeRequests::PushOptionsHandlerService).to receive(:new)
      ```
      
      instead of not_to!
      
      This meant that the `.new` method was being stubbed, so the service
      class did not create a MergeRequest, which satisfied the second
      expectation.
      
      ```
      expect(MergeRequests::PushOptionsHandlerService).to receive(:new)
      ```
      37492c5d
  23. 08 Apr, 2019 5 commits
    • Luke Duncalfe's avatar
    • Luke Duncalfe's avatar
      Refactor PushOptionsHandlerService from review · e73f537c
      Luke Duncalfe authored
      Exceptions are no longer raised, instead all errors encountered are
      added to the errors property.
      
      MergeRequests::BuildService is used to generate attributes of a new
      merge request.
      
      Code moved from Api::Internal to Api::Helpers::InternalHelpers.
      e73f537c
    • Luke Duncalfe's avatar
      Use Gitlab::PushOptions for `ci.skip` push option · 1883e320
      Luke Duncalfe authored
      Previously the raw push option Array was sent to Pipeline::Chain::Skip.
      
      This commit updates this class (and the chain of classes that pass the
      push option parameters from the API internal `post_receive` endpoint to
      that class) to treat push options as a Hash of options parsed by
      GitLab::PushOptions.
      
      The GitLab::PushOptions class takes options like this:
      
          -o ci.skip -o merge_request.create -o merge_request.target=branch
      
      and turns them into a Hash like this:
      
          {
            ci: {
              skip: true
            },
            merge_request: {
              create: true,
              target: 'branch'
            }
          }
      
      This now how Pipeline::Chain::Skip is determining if the `ci.skip` push
      option was used.
      1883e320
    • Luke Duncalfe's avatar
      867ac4d1
    • Luke Duncalfe's avatar
      Support merge request create with push options · aa352a95
      Luke Duncalfe authored
      To create a new merge request:
      
        git push -u origin -o merge_request.create
      
      To create a new merge request setting target branch:
      
        git push -u origin -o merge_request.create \
          -o merge_request.target=123
      
      To update an existing merge request with a new target branch:
      
        git push -u origin -o merge_request.target=123
      
      A new Gitlab::PushOptions class handles parsing and validating the push
      options array. This can be the start of the standard of GitLab accepting
      push options that follow namespacing rules. Rules are discussed in issue
      https://gitlab.com/gitlab-org/gitlab-ce/issues/43263.
      
      E.g. these push options:
      
        -o merge_request.create -o merge_request.target=123
      
      Become parsed as:
      
        {
          merge_request: {
            create: true,
            target: '123',
          }
        }
      
      And are fetched with the class via:
      
        push_options.get(:merge_request)
        push_options.get(:merge_request, :create)
        push_options.get(:merge_request, :target)
      
      A new MergeRequests::PushOptionsHandlerService takes the `merge_request`
      namespaced push options and handles creating and updating
      merge requests.
      
      Any errors encountered are passed to the existing `output` Hash in
      Api::Internal's `post_receive` endpoint, and passed to gitlab-shell
      where they're output to the user.
      
      Issue https://gitlab.com/gitlab-org/gitlab-ce/issues/43263
      aa352a95
  24. 05 Apr, 2019 1 commit
    • Bob Van Landuyt's avatar
      Fall back to project repository type by default · 2fdda744
      Bob Van Landuyt authored
      This makes sure that we always have a repository type when trying to
      parse a repository from a path.
      
      This is needed because sometimes we want to perform access checks as
      if the project already existed, for example when creating a project on
      push.
      
      Before this we were only doing that when accessing git over http, this
      makes sure it also works correctly when accessing git over SSH
      2fdda744
  25. 04 Apr, 2019 2 commits
  26. 26 Mar, 2019 2 commits
    • Bob Van Landuyt's avatar
      Allow multiple repositories per project · d36415b7
      Bob Van Landuyt authored
      This changes the repository type from a binary `wiki?` to a type. So
      we can have more than 2 repository types.
      
      Now everywhere we called `.wiki?` and expected a boolean, we check
      that type.
      d36415b7
    • Bob Van Landuyt's avatar
      Allow multiple repositories per project · 65f939d0
      Bob Van Landuyt authored
      This changes the repository type from a binary `wiki?` to a type. So
      we can have more than 2 repository types.
      
      Now everywhere we called `.wiki?` and expected a boolean, we check
      that type.
      65f939d0
  27. 12 Mar, 2019 1 commit
  28. 11 Mar, 2019 2 commits
  29. 16 Feb, 2019 1 commit
  30. 15 Feb, 2019 1 commit
  31. 14 Feb, 2019 1 commit