Adding Update Process to README

[Ryanb58]

It would be nice to get an update process defined in the readme.

[tom472]

Yes - this is something that I am currently working on. Trying to fully get the logic right when it comes to determining if the project is being run for the first time or if it is an upgrade.

I saw your PR but it's not purely as easy as just doing a git pull and the compose-up, there may be new container folders to be made via the main script, or there may be new variables to be added to the .env file etc.

Sorry for the delay on this - however it is high on my "to-do" list.

Thanks

[kspillane]

If we are talking about getting a new version of the script to add new features, why not generate the compose and .env files dynamically and not include them as part of the repository? In fact, you probably wouldn't even need the .env file at all. Then you wouldn't need to check anything, any run would be a first run, and if the directories already exist, there shouldn't be any problems. They'd either be created or there'd be an error saying the directory already exists.

[tom472]

I personally like the use of the .env file it makes for a much cleaner overall docker-compose.yml file. However - I am going to pull the .env file from the repo, since it is just a stub, and that way there will be no .env file on any first run and it will be there if you re-run and then I can adjust for that.

[kspillane]

So, I am curious as to what exactly would be done in an update? Are we talking like redoing the configuration, or downloading a new version of the script to get new features?

If we are talking redoing the config to change settings. A few modifications to the way files are moved by the script (change form mv to cp - which I think is better anyway) and not appending to the .env file each time (recreate the variables each run, so it doesn't get to big) would handle that. if we are talking about upgrading for new features for an existing install, we could very easily write a feature check to download a new script and compose file from the repo. Then it would just be an update. Recreating existing folder should not overwrite anything.

I can work on this if you want.

[tom472]

The main goal of an update is for major changes to the project to be reflected for users who already have it running.

Like if a container get replaced - For example when Mediabox started there wasn't an official PLEX container now there is so I have changed to that. And I am currently considering a replacement for Minio.

Or new features like - I have just made a commit for PIA server selection - in it's own branch for a bit more testing but should be merged soon.

Things like that...

The process would be to check for existing instance - do a Git Pull - and then re-deploy.

No we would not append to the .env file we would extract a few lines i.e. PIA creds, Couchpotato creds etc. things that are likely to not have changed. Then create a new .env with the rest of the current variables in case any of those have changed. Like IP, hostname, current user etc. these are some things that some users might change from time to time.

Yes - I have taken to the method of changing most of the mv's to cp's -- you are correct it seems better

[kspillane]

Would you want to check for updates automatically, or whenever the program is run? If you don't do it manually, there'd have to have a way of letting the users know that there is an update. If the latter, maybe make a website or facebook page for mediabox so people can know about new releases, then they can rerun the script to do the update. If the former, well that's more difficult, probably don't want to use cron if it can be avoided. I will think about it.

As far as for rerunning the script to redo stuff in case you needed to change something and didn't want to just edit the .env file. That's easy. Get all the mv's changed to cp's, and echo the .env comments into the .env file with the first line being an overwrite ">" not an append. ">>". I can work on this one two over the weekend, too.

I do think a facebook page or website (cpuld do something simple in ghost) would be great to spread the word about mediabox and get people to update (once there is an update process). As features keep getting added, more people will probably want to use it.

I will try to think up an automated update notification process and run it by you.

[tom472]

My current thought is based on the next "big" change I want to make.

The big change I want to make next is to the "landing page", I am looking to replace that with a more robust webserver container (nginx, php-fpm type container) and use some sort of simple (probably flat-file) CMS system like Grav or something so that the landing page can look better and have more info.

Then the thought is to build in a Version check into the landing page - letting users know if they are up to date or behind, and if they are behind what has been changed / added and how to update.

My thought is users will get used to loading the landing page from time to time to check the status of their current version.

Again this is all based on re-configuring the entire landing page container etc. I like making things work and slapping some code together - I am terrible at making things look good. :)

[kspillane]

I was going to play with improving the landing page also. I will try some things this weekend. I hate doing front-end design and UX stuff though. I was going to redo it in bootstrap because it is easy, but I will take a look at Grav, a cursory glance leads me to believe it may be better.

Also, in the ARM support code, I switched from uHTTPd to nginx with no issues. I can create a PR for that if you want.

[tom472]

Hold tight on a PR for nginx - because I've been eyeballing a couple Grav containers and they already have nginx php-fpm etc. in the container. So if I can make it look right it will be a simple swap for a "Grav" container that will have all the necessary parts.

Thanks

[kspillane]

Neat, I will try to write up some help pages in markdown, Descriptions of how to use the various services, links to their pages, etc.

[tom472]

So sorry for how long this took.

The one time upgrade step is here below and now in the README - after these steps being run once anytime you want to update Mediabox just re-run the ./mediabox.sh script.

Upgrading mediabox:

This is only necessary once - and only if you dowloaded Mediabox before it was added into the project.

1. Change directory into mediabox: $ cd your/path/to/mediabox/
2. Git Stash any alterations to local files: $ git stash
3. Git pull the changes to the Mediabox Project: $ git pull
4. Then run the mediabox.sh script: $ ./mediabox.sh << Redo just this step anytime you want/need to update in the future.