1837 Add --source to various commands

[jimmykarily]

Fixes: kairos-io/kairos#1837

[Itxaka]

Currently on upgrade, we use viper to set the var and then recover it on the spec generation.

Is not the best thing ever to be honest, but it helps to set it once and forget about it instead of passing it via all the methods.

viper is a singleton, so once you set a value on it, its available everywhere. This allows us to set it even when parsing the source on the maing.go and then on the spec generation we can just get it and use it.

Unless we are able to somehow bind the flag to the spec, I thikn we should do just that, set the source just after validating it and then on the spec generation, get it and use it. Less moving pieces all around and a single way of setting it and getting it for all commands.

[jimmykarily]

viper is a singleton, so once you set a value on it, its available everywhere.

A singleton is not much better than global variables: https://en.wikipedia.org/wiki/Singleton_pattern#Criticism
and there are many reasons to avoid global variables (and singletons). Let me see if I can find a cleaner way to pass it around, otherwise I'll just use it the same way.

(btw, I'm suspecting 1800) has something to do with how we pass these through viper but I can't reproduce it yet)

[jimmykarily]

@Itxaka now that the collector accepts readers as well, maybe a better idea is to create a config with all the command line options and pass it to the collector as a reader. This way to propagates down to everything.

After all, these command line arguments are really configuration and the sooner we "merge" it the better, because all the consumers of the config will have access to it. What do you think?

[Itxaka]

@Itxaka now that the collector accepts readers as well, maybe a better idea is to create a config with all the command line options and pass it to the collector as a reader. This way to propagates down to everything.

After all, these command line arguments are really configuration and the sooner we "merge" it the better, because all the consumers of the config will have access to it. What do you think?

Hell yeah, that is an awesome idea!

[codecov]

Codecov Report

Merging #152 (48fc618) into main (1170576) will decrease coverage by 0.73%.
The diff coverage is 16.57%.

@@            Coverage Diff             @@
##             main     #152      +/-   ##
==========================================
- Coverage   60.48%   59.75%   -0.73%     
==========================================
  Files          37       37              
  Lines        4494     4577      +83     
==========================================
+ Hits         2718     2735      +17     
- Misses       1546     1608      +62     
- Partials      230      234       +4     

Files	Coverage Δ
internal/agent/reset.go	0.00% <0.00%> (ø)
internal/agent/interactive_install.go	0.00% <0.00%> (ø)
internal/agent/install.go	5.40% <0.00%> (-0.36%)	⬇️
pkg/config/spec.go	72.60% <52.63%> (+0.82%)	⬆️
internal/agent/upgrade.go	0.00% <0.00%> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[jimmykarily]

The PR in its current state seems to work (manual QA). I want to give another take on the tests. It's currently not easy to test because even creating the UpgradeSpec involves mounting partitions and such.