refactor(terraform): don't init in status handler

[eysi09]

What this PR does / why we need it:

Before this fix, we were calling terraform init in the getStatusHandler which is an undesired side effect.

With this refactor we now call it in the prepareEnvironment handler which is were it should be.

Also note that in PR #6706 we changed the provider init flow such that we now always call prepareEnvironment and the getStatusHandler isn't really used any more.

That's why I also removed the call to that handler from the prepareEnvironment function and instead moved the logic there.

It's basically duplicated across both handlers now which is fine because we're removing the status handler in 0.14.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

[twelvemo]

Also note that in PR #6706 we changed the provider init flow such that we now always call prepareEnvironment and the getStatusHandler isn't really used any more.

Just for understanding, did you mean we always call prepareEnvironment and the getEnvironmentStatus handler is not called any longer? The getStatus deploy action handler is still called.

[eysi09]

Just for understanding, did you mean we always call prepareEnvironment and the getEnvironmentStatus handler is not called any longer? The getStatus deploy action handler is still called.

This is only on the provider level.

Specifically, when initialising providers we dropped the flow where first we call getEnviromentStatus, then depending on the result call prepareEnvironment.

It was just a needless abstraction that really complicated the whole process and didn't add any value. Now we always call prepareEnvironment and expect it knows what to do and can exit early if needed.

However, we still call the getEnvironmentStatus handler for statusOnly commands but we'll remove this in 0.14 and just return something like unknown for providers in status commands.

But we didn't change anything around the action level life cycle.

Does that answer your question?

[twelvemo]

Just for understanding, did you mean we always call prepareEnvironment and the getEnvironmentStatus handler is not called any longer? The getStatus deploy action handler is still called.

This is only on the provider level.

Specifically, when initialising providers we dropped the flow where first we call getEnviromentStatus, then depending on the result call prepareEnvironment.

It was just a needless abstraction that really complicated the whole process and didn't add any value. Now we always call prepareEnvironment and expect it knows what to do and can exit early if needed.

However, we still call the getEnvironmentStatus handler for statusOnly commands but we'll remove this in 0.14 and just return something like unknown for providers in status commands.

But we didn't change anything around the action level life cycle.

Does that answer your question?

Yes thanks, that's also how i understood it, just wanted to make sure :-)

[twelvemo]

👍