Skip to content
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

Merged

Conversation

msarvar
Copy link

@msarvar msarvar commented Oct 15, 2020

Adding a run step that executes before any workflow steps.
runatlantis/atlantis#500 original issue that requested the feature.

@msarvar
Copy link
Author

msarvar commented Oct 19, 2020

/ptal #orchestration @nishkrishnan @paulnivin

@nishkrishnan
Copy link
Contributor

can you rebase? It should pull in the gh action that I pushed

@msarvar msarvar force-pushed the ORCA-447-add-server-config-to-run-pre-hooks branch 2 times, most recently from b6b69ad to 0c5c20e Compare October 19, 2020 19:26
@msarvar msarvar force-pushed the ORCA-447-add-server-config-to-run-pre-hooks branch from 0c5c20e to 1223315 Compare October 19, 2020 19:29
@msarvar
Copy link
Author

msarvar commented Oct 19, 2020

/ptal

Copy link
Contributor

@nishkrishnan nishkrishnan left a 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

// be the same as BaseRepo.
HeadRepo Repo
// Log is a logger that's been set up for this context.
Log *logging.SimpleLogger
Copy link
Contributor

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?

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"`
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Author

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")
Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same with the above

Copy link
Author

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

Copy link
Author

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,
)
Copy link
Contributor

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?

Copy link
Author

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.

Copy link
Contributor

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)
Copy link
Contributor

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?

Copy link
Author

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(
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Author

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.

Copy link
Contributor

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?

Copy link
Author

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.

Comment on lines 442 to 445
// TODO: run pre workflow hooks
// e.Logger.Info("running pre workflow hooks")
// e.WorkflowHooksCommandRunner.RunPreHooks(baseRepo, headRepo, pull, user)

Copy link
Contributor

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PreWorkflowHooksCommandRunner*

@msarvar msarvar force-pushed the ORCA-447-add-server-config-to-run-pre-hooks branch from 3f93fdf to 556d70c Compare October 20, 2020 00:00
@msarvar msarvar force-pushed the ORCA-447-add-server-config-to-run-pre-hooks branch from 931368c to 7c748af Compare October 20, 2020 00:28
Copy link
Contributor

@nishkrishnan nishkrishnan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢

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"`
Copy link
Contributor

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?

Copy link
Author

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.

@msarvar
Copy link
Author

msarvar commented Oct 20, 2020

💨

@msarvar msarvar merged commit 2e74997 into release-v0.15.0-lyft.1 Oct 20, 2020
@msarvar msarvar deleted the ORCA-447-add-server-config-to-run-pre-hooks branch October 20, 2020 00:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants