-
Notifications
You must be signed in to change notification settings - Fork 45
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 version check #1157
Fix version check #1157
Conversation
cmd/skywire-visor/commands/root.go
Outdated
@@ -581,3 +446,144 @@ func checkHvIsRunning(addr string, retries int) bool { | |||
} | |||
return false | |||
} | |||
|
|||
func updateConfig(mLog *logging.MasterLogger, conf *visorconfig.V1) { |
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.
I am wondering if it would be better to ask the user to run the update CLI command. For most users we will perform config upgrades via package scripts. For others running from source, they could/should be able to run CLI I would think. Would save us the trouble from reimplementing the CLI code here.
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.
I personally never use config update.
Config gen is very solidly implemented, whereas it isn't clear that config update will act as desired and was otherwise untested for updating possibly between versions. Its intended use was only to change the values that cannot be directly set with config gen.
is this not the desired behavior? The config needs to be updated if there is such a drastic change to the version, I thought? @jdknives didn't object so I guess my assumption is wrong I will implement the semver package as you suggest |
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.
Based on its issue #1154, no need to check minor update, and if I missing something and need to check then PR is OK.
@0pcom correct. Only need to check on major increments. There are a few remaining issues:
Logging is too verbose. Most of the info logging should be at debug level. Some of the logs are duplicate such as the last three ones. |
func logBuildInfo(mLog *logging.MasterLogger) { | ||
log := mLog.PackageLogger("buildinfo") | ||
visorBuildInfo = buildinfo.Get() | ||
if visorBuildInfo.Version != "unknown" { |
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.
Can we put these logs on one line?
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.
done with 0e6b703
pkg/skyenv/values_darwin.go
Outdated
@@ -8,6 +8,10 @@ const ( | |||
OS = "mac" | |||
// SkywirePath is the path to the installation folder. | |||
SkywirePath = "/Library/Application Support/Skywire" | |||
// Ptext is the description to use for the -p flag for config gen and for the visor | |||
Ptext = "use mac installation path: " + SkywirePath |
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.
I think you misunderstood my request. I would like to get rid of the additional global variable. We can just construct this message inside the flag declaration instead of exposing a global variable.
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.
done with f672c82
pkg/skyenv/values_darwin.go
Outdated
// Ptext is the description to use for the -p flag for config gen and for the visor | ||
Ptext = "use mac installation path: " + SkywirePath | ||
// Configjson is the config name generated by the script included with the installation on mac | ||
Configjson = "skywire.json" |
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.
We talked about making this congruent with the names for generic skywire configs by using skywire-config.json
. Did that not work out or did you miss it?
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.
I need to implement the systray and config gen at the user level for the packages first
when that is working I will go back and figure out migration of the configs in /opt/skywire from skywire.json to skywire-config.json
It's just too much to do at the same time. I'm trying to avoid unintended consequences.
…h. Move buildinfo logging to one line
cmd/skywire-visor/commands/root.go
Outdated
@@ -380,7 +378,7 @@ func initConfig(mLog *logging.MasterLogger, confPath string) *visorconfig.V1 { / | |||
log.WithError(err).Fatal("Failed to read in config.") | |||
} | |||
if !compat { | |||
updateConfig(mLog, conf) | |||
updateConfig(mLog) |
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.
This can be one line of just using log.Fatalf() for instance. Seems overkill to me to assign a new package logger and then log error and fatal separately.
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.
you are right, separate func was vestigial - fixed in cd88cfe
Fixes #1154