Select Git revision
context.rb
-
Bob Van Landuyt authored
The context can be passed from the client applications as a hash. Every time a new context is added, it will inherit the values of the previous context. Those previous values will be overridden by any new ones passed. A context always has a correlation id that is not empty. If an empty correlation id is passed, a new one will be generated. There is a `Labkit::Middleware::Rack` that will set the correlation id to the current request id. Because of this, every newly started context within a rack request will get the same correlation id. Using the `Labkit::Middleware::Sidekiq::Client` middleware the context active at the moment of scheduling a job will be serialized into the job. The `Labkit::Middleware::Sidekiq::Server` middleware will load the context that was stored on the job, so newly scheduled jobs would start with the same context. This context could be modified by the job. In this iteration the following extra values can be specified on the context: - user - project - root_namespace **Usage of the Labkit::Context** The preferred way of specifying a context is using a block: Labkit::Context.with_context( user: 'jane.doe', project: 'jane.doe/cool' ) do |context| # application code end If there's no way to wrap the application code into a block (for example for the grape api), then context can be pushed and popped: def context @context ||= Labkit::Context.push(user: 'jane.doe') end before { context } after { Labkit::Context.pop(context) } It is possible to provide procs when assigning values to the context: Labkit::Context.with_context(user: -> { current_user }) { # ... } This proc will only be executed when needed: When serialising the context into a log or a job. This happens when calling `Labkit::Context.to_h`.
Bob Van Landuyt authoredThe context can be passed from the client applications as a hash. Every time a new context is added, it will inherit the values of the previous context. Those previous values will be overridden by any new ones passed. A context always has a correlation id that is not empty. If an empty correlation id is passed, a new one will be generated. There is a `Labkit::Middleware::Rack` that will set the correlation id to the current request id. Because of this, every newly started context within a rack request will get the same correlation id. Using the `Labkit::Middleware::Sidekiq::Client` middleware the context active at the moment of scheduling a job will be serialized into the job. The `Labkit::Middleware::Sidekiq::Server` middleware will load the context that was stored on the job, so newly scheduled jobs would start with the same context. This context could be modified by the job. In this iteration the following extra values can be specified on the context: - user - project - root_namespace **Usage of the Labkit::Context** The preferred way of specifying a context is using a block: Labkit::Context.with_context( user: 'jane.doe', project: 'jane.doe/cool' ) do |context| # application code end If there's no way to wrap the application code into a block (for example for the grape api), then context can be pushed and popped: def context @context ||= Labkit::Context.push(user: 'jane.doe') end before { context } after { Labkit::Context.pop(context) } It is possible to provide procs when assigning values to the context: Labkit::Context.with_context(user: -> { current_user }) { # ... } This proc will only be executed when needed: When serialising the context into a log or a job. This happens when calling `Labkit::Context.to_h`.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.