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

[automation/go] - Implement min version checking #6577

Merged
merged 10 commits into from
Mar 23, 2021

Conversation

komalali
Copy link
Member

@komalali komalali commented Mar 18, 2021

Changes

  • Added a LocalWorkspace.PulumiVersion() method that returns the underlying Pulumi CLI version.
  • NewLocalWorkspace() now checks the underlying pulumi version during creation and stores it on the LocalWorkspace struct.
  • NewLocalWorkspace() checks that the PulumiVersion >= the minimum version set in minimum_version.go and returns an error to update the CLI if the check fails.

Go part of #6348 and #6419

@komalali komalali force-pushed the komalali/go-min-version branch 2 times, most recently from c7c4447 to 85fc2b6 Compare March 19, 2021 20:24
@komalali komalali requested a review from justinvp March 19, 2021 20:45

import "github.com/blang/semver"

var minimumVersion = semver.Version{
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 anything we are going to need to do in our 3.0 work relating to this? Is this something we need to bump on each release?

Copy link
Member Author

Choose a reason for hiding this comment

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

Is there anything we are going to need to do in our 3.0 work relating to this?

Yes, for the 3.0 release we will need to bump this to 3.0.0.

Is this something we need to bump on each release?

No, only when there is a change to the automation SDK that is dependent on a CLI change.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, for the 3.0 release we will need to bump this to 3.0.0.

Out of curiosity - is this true? Will 3.0 of automation API require that a 3.0 CLI is installed? It's not immediately obvious it would have to?

Related - is it a breaking change to increase this? I assume so - which will make us want to do this very infrequently.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. We made breaking changes to the CLI in 3.0 (standardizing select behavior) that we use under the hood in Automation API, so we will need to bump the minimum version.

Copy link
Contributor

@stack72 stack72 left a comment

Choose a reason for hiding this comment

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

@komalali this is great - a nice non-intrusive way to calculate this that only hits on the workspace creation. I am really worried about the version being embedded in this - it seems we need to do that for all of our code which means we need to remember to bump it in 4 places if we need to change it

I am not sure how much effort we want to put into this feature at this point but this feels like something we need to give some thought about

@EvanBoyle
Copy link
Contributor

which means we need to remember to bump it in 4 places if we need to change it

This problem is kinda inherent to any feature and/or bug fix made to automation API. Just part of the game, unfortunately.

@stack72
Copy link
Contributor

stack72 commented Mar 22, 2021

which means we need to remember to bump it in 4 places if we need to change it

This problem is kinda inherent to any feature and/or bug fix made to automation API. Just part of the game, unfortunately.

Totally understand, it's definitely why I still hit approve as it's something we just need to be aware of rather than blocking on it

But you are 100% correct here

@@ -479,6 +487,32 @@ func (l *LocalWorkspace) ImportStack(ctx context.Context, stackName string, stat
return nil
}

func (l *LocalWorkspace) getPulumiVersion(ctx context.Context) (semver.Version, error) {
stdout, stderr, errCode, err := l.runPulumiCmdSync(ctx, "version")
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps a small thing - but since we already have some issues with automation api performance due to many invocations of the CLI - curious on two things:

  1. What is the typical performance impact of making this call?
  2. Should we make this call asynchronously, and only block when a user (directly or indirectly via some other api call that internally checks the version) requests the version?

Copy link
Member

Choose a reason for hiding this comment

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

(Same idea of course applies in all languages)

Copy link
Member Author

Choose a reason for hiding this comment

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

Should we make this call asynchronously, and only block when a user (directly or indirectly via some other api call that internally checks the version) requests the version?

@lukehoban the design choice here for ensuring that we have the minimum version of the CLI installed (as a means for addressing #6419) is that we will validate the pulumi version against the minimum valid version at Workspace creation. We chose to only make this call once so we could then store it on the Workspace object and avoid redoing that work later.

Typical performance impact would vary by language but a benchmark test of Workspace creation in Go result in 0.07434 ns so I feel pretty comfortable taking that hit :)

Screen Shot 2021-03-22 at 8 05 45 PM

Copy link
Member

Choose a reason for hiding this comment

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

Great to see the perf impact is so small!


import "github.com/blang/semver"

var minimumVersion = semver.Version{
Copy link
Member

Choose a reason for hiding this comment

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

Yes, for the 3.0 release we will need to bump this to 3.0.0.

Out of curiosity - is this true? Will 3.0 of automation API require that a 3.0 CLI is installed? It's not immediately obvious it would have to?

Related - is it a breaking change to increase this? I assume so - which will make us want to do this very infrequently.

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.

5 participants