-
-
Notifications
You must be signed in to change notification settings - Fork 663
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 lib.sh to change variables to functions #1247
Conversation
I've already tested if the concept works, which is the case. Hence marking as ready for review. |
The reason why we use the current way is that we do not want to run the variables every time the I haven't tested this, so I can't say, but are you 100% sure that the variables aren't set even if it's in a function? |
yes, that is the case. I have tested it by running bash -x on a script (and see which variables get called during the pull of the new library) This was inside the script:
if you run that with bash -x , you can see that no one of these variables inside the new functions get printed out during the initial pull. Additionally if you e.g. |
we should add a script that fetches the latest `server_configuration` script @szaimen That way we don't need to keep it in the scripts folder, and it would always be the latest version of the script
I tested this yesterday, just to see if it works to use functions instead, and it does. But, some variables are nested into different scripts, and I'm very careful here, since this is the way we done it for the past years. Double, tripple, and quadrouple check all the variables that are changed here. I know that And third, now we no longer have a way to check if the needed functions are actually loaded, which ww check in --------------------------------^. Thanks! |
static/main_menu.sh
Outdated
fi | ||
;; | ||
"Server Configuration") | ||
if network_ok | ||
then | ||
run_static_script server_configuration | ||
run_script STATIC server_configuration |
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 please revert all changes in this commit?
As I said it will complicate things to fix #11 by a lot!
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've reverted that.
I don't get what you mean. Have you seen, that we have actually a backup for the legacy way of calling them to remain backwards compatibility and in the case that we have forgotten one?
you can just test it. In my testing it works without any flaw.
Edit: where have we anywhere tested if functions get loaded? |
One example, I'm not sure if there's more: https://github.com/nextcloud/vm/blob/master/lib.sh#L790 Just because what you tested works, it doesn't mean that everything works. Just sayin. Happened to me several times. :) |
Ok, nice one. Question is - how long should we keep it? I don't want to clutter the scripts with different approaches. We use one standard, that's it. |
The thing is, that we
Okay, but it seems like this is network related, because you just check once in the library and not looping over it. because ncversion will only be set if the website can get reached. Don't want to say that you don't have a point here but if there was no check before, I won't see why we need to add additional checks, because the functions will work as reliable as the current NC_UPDATE=1 way of getting the needed variables. |
What about until the next Ubuntu 22.04 release? I think that is always a good date to get rid of legacy components - also it is nearly 2 years ahead. But that is what you have to decide because many things in the old VMs won't work without that backup. We could add a comment that it should get removed for Ubuntu 22.04? |
In general I think that we should keep some backwards compatibility for at least one OS before. So in 20.04 we ditched 16.04. In 22.04 we should ditch 18.04. It's nothing I have written in stone, but I think that's a good approach. It also depends on how much Ubuntu changes ofc. 16.04 to 18.04 was a huge change. 18.04 to 22.04 - not so huge. But ☝️ is regarding OS versions, I think this is more a matter of keeping backwards compatibility for a shorter period of time, just to make sure that old VMs (like max 6 months) should run without an issue. I mean the most critical thing here is those who haven't yet deployed their VM. We can expect that they did so within 6 months, right? The update script always uses the latest What do you think? |
Don't want to say that you don't have a point here but if there was no check before, I won't see why we need to add additional checks, because the functions will work as reliable as the current NC_UPDATE=1 way of getting the needed variables. The whole reason for that change (not using NC_UPDATE for the whole script, and put it in the function instead) is that it takes time to load the variables and it hammers Nextclouds servers more than we need to. IIRC, that's the main reason for it. But, maybe it's as easy as just check for $CURRENTVERSION as you did, and if if doesn't exist, just run What's making me most uncertain here is that you say that you've tested everything, but then you missed this... In my head "what else did he miss"? But at the same time, that's why we have these discussions. 👍 Even if I'm thorough as ***, I still miss things as well, we are all humans (and all that) :) |
yes and also we have less variables in every script and it is cleaner to be able to run the functions every time that we need them. Also They wouldn't get called during the script start which would speed up the first start...
Actually, I didn't missed it because else I had changed it (if it would have been some of the changed variables). I only haven't remembered now.
Yes, that is the whole idea 👍 |
This comment has been minimized.
This comment has been minimized.
What about merging this? Or is there still something to discuss? |
Great, then please look through the code once more and see if you can find more occurrences.
No, there are still bugs here, which I mentioned but that isn't fixed. |
PLUS: I don't want a failsafe here. Either it should all work, or we should find were it doesn't and fix t. |
This comment has been minimized.
This comment has been minimized.
I've changed download_verify_nextcloud_stable now and I've looked looked for all "[ -z" and "[ -n" and "=1" occurences and there is no old colde that still needs to be fixed, imo (despite of the script in the "old" directory); also the code in download_verify_nextcloud_stable wasn't badly needed to get fixed: it would have worked this way. |
No description provided.