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

Update klotho checks #137

Merged
merged 4 commits into from
Jan 25, 2023
Merged

Update klotho checks #137

merged 4 commits into from
Jan 25, 2023

Conversation

ewucc
Copy link
Contributor

@ewucc ewucc commented Jan 25, 2023

I think the second stream check will result in false update messages being printed.

Here's an example where I set my options to oss:v0.5.19

Calling server w/ url + stream:  http://srv.klo.dev oss:v0.5.19
Current ver:  0.5.19       Latest Ver:  0.5.19
Current Stream:  oss:latest    User Stream:  oss:v0.5.19

If the user pins the version to the current version, it's just never going to match the stream check because the current stream is always the default value oss:latest

I'm pretty sure the first check for the semver is good enough since that takes the latest and converts it to the version number and compares that to the running builds version in the build file.

Discussion: Not sure if the initial intention was to notify the user every time they run, that their pinned version is behind latest, but if that's the case, then this needs to be merged in https://github.com/klothoplatform/klotho-server/pull/27. The server was checking w/ the stream version provided instead of actual latest.

@ghost
Copy link

ghost commented Jan 25, 2023

This check was there intentionally. Let's say both the latest in both oss and pro is 0.6.0, and I'm on the oss stream. If I do klotho --set-option update.stream=pro:latest --update, then I don't want it to say "oh you're on v0.6.0 already, nothing to do". It should recognize that because I updated streams, it always needs to do an update.

It's very possible I got some other aspect of the workflow wrong, but I think we do need to preserve that behavior at least.

@ewucc
Copy link
Contributor Author

ewucc commented Jan 25, 2023

Per convo w/ yuval, added the check for the stream type

If the user pins a version and that version is not latest and the version actually matches the current version they have, then we instead message that the version has been pinned.
Screen Shot 2023-01-25 at 12 22 16 PM

If the user pins a version and it's not latest and it does not match the version they are on, or they pin it to latest, or they don't pin a version, we do the update check
Screen Shot 2023-01-25 at 12 22 11 PM

@@ -126,3 +128,19 @@ func OptionOrDefault(given string, defaultValue string) string {
}
return given
}

func ShouldCheckForUpdate(given string, defaultValue string, currVersion string) bool {
Copy link

Choose a reason for hiding this comment

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

small: can we rename these args? something like

Suggested change
func ShouldCheckForUpdate(given string, defaultValue string, currVersion string) bool {
func ShouldCheckForUpdate(updateStreamOverride string, defaultUpdateStream string, currVersion string) bool {

and then similarly below:

  • givenParts => streamOverrideParts
  • givenVersion => streamOverrideVersion

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yep can change for sure

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

Logic is good. For some reason, it took me a bit to actually grok this. Partially I could just be a bit out of it, but I think the var name changes I suggested would have helped a lot. If you disagree, feel free to disregard — my suggestions aren't blocking.

@github-actions
Copy link

Package Line Rate Health
github.com/klothoplatform/klotho/pkg/analytics 2%
github.com/klothoplatform/klotho/pkg/annotation 23%
github.com/klothoplatform/klotho/pkg/cli 4%
github.com/klothoplatform/klotho/pkg/core 20%
github.com/klothoplatform/klotho/pkg/env_var 82%
github.com/klothoplatform/klotho/pkg/exec_unit 45%
github.com/klothoplatform/klotho/pkg/infra/kubernetes 59%
github.com/klothoplatform/klotho/pkg/infra/kubernetes/helm 39%
github.com/klothoplatform/klotho/pkg/input 63%
github.com/klothoplatform/klotho/pkg/lang 37%
github.com/klothoplatform/klotho/pkg/lang/dockerfile 0%
github.com/klothoplatform/klotho/pkg/lang/golang 9%
github.com/klothoplatform/klotho/pkg/lang/javascript 47%
github.com/klothoplatform/klotho/pkg/lang/python 60%
github.com/klothoplatform/klotho/pkg/lang/yaml 0%
github.com/klothoplatform/klotho/pkg/logging 7%
github.com/klothoplatform/klotho/pkg/multierr 95%
github.com/klothoplatform/klotho/pkg/provider/aws 60%
github.com/klothoplatform/klotho/pkg/runtime 75%
github.com/klothoplatform/klotho/pkg/static_unit 32%
github.com/klothoplatform/klotho/pkg/validation 73%
github.com/klothoplatform/klotho/pkg/yaml_util 79%
Summary 39% (3694 / 9361)

@ewucc ewucc merged commit 8ec28f4 into main Jan 25, 2023
@ewucc ewucc deleted the update-fix branch January 25, 2023 21:04
ghost pushed a commit that referenced this pull request Feb 17, 2023
Previously, if you tried to pin to a lower version, we would treat it as
a no-op (and keep you at your current version). Now, we'll perform the
update ("downdate").

This resolves #187.

We've had a few back-and-forths in this code, most recently #137. I
added unit tests to try and put this to bed for good, or at least
prevent further regressions.
ghost pushed a commit that referenced this pull request Feb 17, 2023
Previously, if you tried to pin to a lower version, we would treat it as
a no-op (and keep you at your current version). Now, we'll perform the
update ("downdate").

This resolves #187.

We've had a few back-and-forths in this code, most recently #137. I
added unit tests to try and put this to bed for good, or at least
prevent further regressions.
@ghost ghost mentioned this pull request Feb 17, 2023
ghost pushed a commit that referenced this pull request Feb 21, 2023
Previously, if you tried to pin to a lower version, we would treat it as
a no-op (and keep you at your current version). Now, we'll perform the
update ("downdate").

This resolves #187.

We've had a few back-and-forths in this code, most recently #137. I
added unit tests to try and put this to bed for good, or at least
prevent further regressions.

I found myself getting kinda confused about the various situations, so I
wrote a novel to explain it to myself. I figured I'd keep it around for
the next person.
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.

1 participant