-
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
Orca 447 add server config to run pre hooks #8
Orca 447 add server config to run pre hooks #8
Conversation
/ptal #orchestration @nishkrishnan @paulnivin |
can you rebase? It should pull in the gh action that I pushed |
b6b69ad
to
0c5c20e
Compare
0c5c20e
to
1223315
Compare
/ptal |
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.
Nice job! Have some comments/questions
server/events/models/models.go
Outdated
// be the same as BaseRepo. | ||
HeadRepo Repo | ||
// Log is a logger that's been set up for this context. | ||
Log *logging.SimpleLogger |
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.
Should we be passing the interface here?
server/events/yaml/raw/global_cfg.go
Outdated
AllowCustomWorkflows *bool `yaml:"allow_custom_workflows,omitempty" json:"allow_custom_workflows,omitempty"` | ||
ID string `yaml:"id" json:"id"` | ||
ApplyRequirements []string `yaml:"apply_requirements" json:"apply_requirements"` | ||
WorkflowHooks []WorkflowHook `yaml:"pre_workflow_hooks" json:"pre_workflow_hooks"` |
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 would keep the naming consistent and just call this PreWorkflowHooks
// WorkflowHooksCommandResult is the result of executing pre workflow hooks for a | ||
// repository. | ||
type WorkflowHooksCommandResult struct { | ||
WorkflowHookResults []models.WorkflowHookResult |
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.
Curious as to why you chose to support a list at this point? I don't think we have a need for it right? and even if we did, might be easier to to just have all the steps listed in the external script itself. Plus it seems that this isn't really following the normal go convention of return some value + an error which feels a bit weird in a communal code base.
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.
You're right it is not needed here. I will remove it. It is used for command_runner where you have multiple projects running in parallel.
log.Warn("workspace is locked") | ||
return | ||
} | ||
log.Debug("got workspace lock") |
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.
if you're gonna leave this in maybe add a bit more like the root name/repo name
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.
Same with the above
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 log
is an instance of a logger and it uses repo_name#pr_num
as a prefix.
This is an example from my local
2020/10/19 16:43:53-0700 [DBUG] pre_workflow_hooks_command_runner.go:61 msarvar/atlantis-local-dev#28: Got workspace lock
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 can't do better than repo_name and PR since I don't have root information at this point.
headRepo models.Repo, | ||
pull models.PullRequest, | ||
user models.User, | ||
) |
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 aren't we returning an error at least in the 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.
Initially it was returning an object and error but CommandRunner
interface doesn't have any return values. So decided to be consistent.
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.
Hmm I see yeah ok we can probably be consistent then.
Verbose: false, | ||
} | ||
|
||
result := w.runHooks(ctx, workflowHooks, repoDir) |
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.
Seems odd to me to have an object called result that doesn't get returned and is only used as an error check.
Couldn't we just as easily return the first error we get in the function and check here whether that is nil or not?
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.
Yeah, i was trying too hard to follow the atlantis implementation for run_steps. But it makes sense to reduce the wrapping.
if err := recover(); err != nil { | ||
stack := recovery.Stack(3) | ||
logger.Err("PANIC: %s\n%s", err, stack) | ||
if commentErr := w.VCSClient.CreateComment( |
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.
Is there precendence for logging panics to the PR elsewhere in the repo?
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.
Seems like a bad user experience to do that but don't want to deviate from the standard if that's set already.
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.
Yep, it is in the command_runner.go both RunCommentCommand
and RunAutoplanCommand
use it. What would alternative be? Potentially we can log and move on for pre_workflow_hooks.
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.
It's a good question.
i think in this case, the hooks are going to be only configured server side right? So customers shouldn't really know about it. Hence I would lean towards something like we just log an error and a stat (and alarm on this internally) and just move on.
In our case, there will probably be some downstream error about missing an atlantis configuration file so it's probably ok. In the general case, I'm not sure what people would use this for, but might be safer to not panic on failure in case it's something non-critical.
What do you think?
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 think that should work for our use case.
server/events_controller.go
Outdated
// TODO: run pre workflow hooks | ||
// e.Logger.Info("running pre workflow hooks") | ||
// e.WorkflowHooksCommandRunner.RunPreHooks(baseRepo, headRepo, pull, user) | ||
|
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.
?
server/server.go
Outdated
AtlantisURL: parsedURL, | ||
Router: underlyingRouter, | ||
Port: userConfig.Port, | ||
WorkflowHooksCommandRunner: workflowHooksCommandRunner, |
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.
PreWorkflowHooksCommandRunner*
3f93fdf
to
556d70c
Compare
931368c
to
7c748af
Compare
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.
🚢
server/events/yaml/raw/global_cfg.go
Outdated
AllowCustomWorkflows *bool `yaml:"allow_custom_workflows,omitempty" json:"allow_custom_workflows,omitempty"` | ||
ID string `yaml:"id" json:"id"` | ||
ApplyRequirements []string `yaml:"apply_requirements" json:"apply_requirements"` | ||
PreWorkflowHooks []PreWorkflowHook `yaml:"pre_workflow_hooks" json:"pre_workflow_hooks"` |
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'm assuming we don't support this in the repo config currently?
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 sure what would be the use case for repo config? For repo config there is a custom run commands.
💨 |
Adding a run step that executes before any workflow steps.
runatlantis/atlantis#500 original issue that requested the feature.