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. 20 Nov, 2019 1 commit
    • Andrew Newdigate's avatar
      Add Sidekiq middleware stack integration tests · 85ef5ab0
      Andrew Newdigate authored
      Before this change, Sidekiq middleware components were only tested
      through unit tests. This add basic integration tests for our server-side
      and client-side middleware stacks, to ensure that messages pass through
      the stack without causing exceptions.
      
      The change also ensures that each middleware yields control as expected.
      85ef5ab0