-
Notifications
You must be signed in to change notification settings - Fork 198
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
hooks: require environment and project always #4011
Conversation
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
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 a bug that this is fixing? What is the expectation when the environment or project or env is not available? Looks like we may panic.
|
||
stableServices, err := m.importManager.ServiceStable(ctx, projectConfig) | ||
func (m *HooksMiddleware) registerServiceHooks(ctx context.Context) error { | ||
stableServices, err := m.importManager.ServiceStable(ctx, m.projectConfig) |
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.
What happens when there isn't a project? Won't we get a panic for nil
reference?
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.
) (*actions.ActionResult, error) { | ||
if projectConfig.Hooks == nil || len(projectConfig.Hooks) == 0 { | ||
func (m *HooksMiddleware) registerCommandHooks(ctx context.Context, next NextFn) (*actions.ActionResult, error) { | ||
if m.projectConfig.Hooks == nil || len(m.projectConfig.Hooks) == 0 { |
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.
Looks like we would get nil
reference panic here if projectConfig is nil
hooksRunner := ext.NewHooksRunner( | ||
hooksManager, | ||
m.commandRunner, | ||
envManager, | ||
m.envManager, | ||
m.console, | ||
projectConfig.Path, | ||
projectConfig.Hooks, | ||
env, | ||
m.projectConfig.Path, | ||
m.projectConfig.Hooks, | ||
m.env, |
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 the environment isn't available and we have nil
for environment I would expect a panic happens here.
@wbreza I was thinking this fixes the issue #3920, using the same approach as #3940 where we force environment initialization to happen early-on. The only difference is that in this approach, we don't use middleware to separate initialization into lifecycles. In this PR, we just use the slightly more direct approach of using DI directly. |
Hi @weikanglim. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass. |
Since hooks was introduced, it has always taken a soft dependency on project and environment being available. This change introduces a hard dependency and validates environment and project being available before deciding to register or run hooks.