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 version check #1157

Merged
merged 9 commits into from
Apr 28, 2022
Merged

Fix version check #1157

merged 9 commits into from
Apr 28, 2022

Conversation

0pcom
Copy link
Collaborator

@0pcom 0pcom commented Apr 19, 2022

Fixes #1154

@mrpalide
Copy link
Contributor

It's OK for different patch version, but on minor different get error yet.
image

@@ -581,3 +446,144 @@ func checkHvIsRunning(addr string, retries int) bool {
}
return false
}

func updateConfig(mLog *logging.MasterLogger, conf *visorconfig.V1) {
Copy link
Member

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.

Copy link
Collaborator Author

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.

@0pcom
Copy link
Collaborator Author

0pcom commented Apr 20, 2022

It's OK for different patch version, but on minor different get error yet. image

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

Copy link
Contributor

@mrpalide mrpalide left a 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.

@jdknives
Copy link
Member

@0pcom correct. Only need to check on major increments. There are a few remaining issues:

[2022-04-26T12:09:19+02:00] INFO [buildinfo]: version="v1.0.0"
[2022-04-26T12:09:19+02:00] INFO [buildinfo]: built on="2022-04-26T10:09:09Z"
[2022-04-26T12:09:19+02:00] INFO [buildinfo]: against commit="c33e3c8fdf0db9443c863ba86b3beafb8da63bc8"
[2022-04-26T12:09:19+02:00] INFO [visor:config]: Reading config from file.
[2022-04-26T12:09:19+02:00] INFO [visor:config]: filepath="skywire-config.json"
[2022-04-26T12:09:19+02:00] INFO [visor:config]: config version: ="v0.6.0-241-g20aa58f7"
[2022-04-26T12:09:19+02:00] ERROR [visor:update-config]: config version does not match visor version
[2022-04-26T12:09:19+02:00] ERROR [visor:update-config]: skywire version: ="v1.0.0"
[2022-04-26T12:09:19+02:00] INFO [visor:update-config]: match:true
[2022-04-26T12:09:19+02:00] INFO [visor:update-config]: updstr:go run cmd/skywire-cli/skywire-cli.go config gen -b
[2022-04-26T12:09:19+02:00] INFO [visor:update-config]: please update your config with the following command:

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" {
Copy link
Member

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done with 0e6b703

@@ -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
Copy link
Member

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done with f672c82

// 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"
Copy link
Member

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?

Copy link
Collaborator Author

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.

@0pcom
Copy link
Collaborator Author

0pcom commented Apr 26, 2022

@jdknives i've removed the generation of the update command string per our conversation here 0e6b703

@@ -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)
Copy link
Member

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.

Copy link
Collaborator Author

@0pcom 0pcom Apr 27, 2022

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
image

@mrpalide mrpalide merged commit b8998bb into skycoin:develop Apr 28, 2022
@0pcom 0pcom deleted the fix/version-check branch April 29, 2022 01:26
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.

4 participants