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

fix(provider): allow initialising providers without write ops for validation command #6051

Merged
merged 5 commits into from
May 21, 2024

Conversation

twelvemo
Copy link
Collaborator

@twelvemo twelvemo commented May 15, 2024

What this PR does / why we need it:

While resolving providers all kinds of actions are performed in the different providers e.g. for the kubernetes providers ingress controllers are installed and app namespaces created. The terraform provider with an initRoot stack and autoApply set to true will even apply a terraform stack on provider initialization. This is the intended behavior for a lot of commands like deploy etc. However some commands like validate also rely on resolving the providers, whereas a validate command should not apply any changes.

This PR adds a statusOnly param to the graph and provider resolution so providers can be resolved and their status queried without any write operations. To do this the getEnvironmentStatus handler on each provider should only implement status checks, while the prepareEnvironment handler should handle any write calls. Added tests for all providers that implement these handlers.

Which issue(s) this PR fixes:

Fixes #6029 #3327

Special notes for your reviewer:

@twelvemo twelvemo changed the title No write ops on validate fix(provider): allow initialising providers without write ops for validation command May 15, 2024
@twelvemo twelvemo marked this pull request as ready for review May 17, 2024 09:35
@@ -418,7 +418,7 @@ export class GraphSolver extends TypedEventEmitter<SolverEvents> {
// Status is either aborted or failed
this.log.silly(() => `Request ${request.getKey()} status: ${resultToString(status)}`)
this.completeTask({ ...status, node: request })
} else if (request.statusOnly && status !== undefined) {
} else if (request.statusOnly && status !== undefined && status.result) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is the condition status.result necessary here? The GraphResult.result field is defined as nullable. I'm not sure about the semantics behind the null-value here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

statusOnly wasn't really used before. Now when it is actually true and passed in to the solver, it will return a status in the first iteration, but status.result will still be null. However status.result is needed in completeTask see here.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Did the lack of this check cause any errors?
There is a node.complete(...) in completeTask (solver.ts#L466):

const result = node.complete(params)

It should get the existing result if it's not null or create a new object otherwise. So, maybe it's safe to omit this check here. I'm not sure, let's double-check.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It is a bit confusing, but we actually try to read result.result here which is still null after complete.
Without this check, garden crashes:

TypeError: Cannot read properties of null (reading 'status')
    at file:///Users/anna/repos/garden/core/build/src/garden.js:575:56
    at Array.every (<anonymous>)
    at file:///Users/anna/repos/garden/core/build/src/garden.js:575:41

Do you think there is a better way to deal with this?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, I see. Thanks for the clarification! 👍
I don't see a better way at the moment, just wanted to double check this and get more context :)
Looks good!

core/src/garden.ts Outdated Show resolved Hide resolved
Copy link
Collaborator

@vvagaytsev vvagaytsev left a comment

Choose a reason for hiding this comment

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

Looks good, thank you! 👍

I've left one question and a few non-blocking minor comments. Let's check those and get this merged today.

Huge thanks for adding provider-level tests! 💯

Copy link
Collaborator

@vvagaytsev vvagaytsev left a comment

Choose a reason for hiding this comment

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

Thank you! 💯

@twelvemo twelvemo added this pull request to the merge queue May 21, 2024
Merged via the queue into main with commit 2321ae8 May 21, 2024
41 checks passed
@twelvemo twelvemo deleted the no-write-ops-on-validate branch May 21, 2024 13:29
@twelvemo twelvemo linked an issue May 21, 2024 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants