-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create proxy command runner to toggle between platform mode worklow #197
Create proxy command runner to toggle between platform mode worklow #197
Conversation
based on a feature flag
} | ||
|
||
func (r *Runner) Run(ctx *command.Context, cmd *events.CommentCommand) { | ||
if err := r.vcsClient.CreateComment(ctx.Pull.BaseRepo, ctx.Pull.Num, "I'm a platform mode approve_policies runner", command.ApprovePolicies.String()); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This description lmao.
type featureRunnerFunc func(ctx *command.Context, cmd *events.CommentCommand) | ||
|
||
func (f featureRunnerFunc) Run(ctx *command.Context, cmd *events.CommentCommand) { | ||
f(ctx, cmd) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this necessary vs. just an interface? All the methods seem to have the same signature? Is there a reason we can't just use a decorator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to avoid instantiating a new decorator instance for each command. For instance in server.go
I'm doing this:
featuredRunner := lyftCommands.NewPlatformModeFeatureRunner(
featureAllocator,
userConfig.EnablePlatformMode,
logger,
)
commentCommandRunnerByCmd := map[command.Name]comment.Runner{
command.Plan: featuredRunner.Wrap(
plan.NewRunner(vcsClient),
planCommandRunner,
),
command.Apply: featuredRunner.Wrap(
apply.NewRunner(vcsClient),
applyCommandRunner,
),
command.ApprovePolicies: featuredRunner.Wrap(
policies.NewRunner(vcsClient),
approvePoliciesCommandRunner,
)
}
Instead of initializing a new runner for each plan. This is basically a decorator pattern as well, just more functional inspired. Based on this talk. I also fixed the signature of the Wrap
function to return CommentCommandRunner
interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the code to use decorator struct.
return | ||
} | ||
|
||
shouldAllocate, err := r.featureAllocator.ShouldAllocate(feature.PlatformMode, ctx.HeadRepo.FullName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not in this PR but something we should do is emit stats within the feature allocator when there is an error.
Created a
PlatformModeFeatureRunner
that acts as a proxy for plan, apply and policy check command runners.Created dummy plan and apply runners that only comment to github