Lmao

Here are the notes I have on downloading the database

docker exec -it mongo bash
mongodump --db=rocketchat --gzip --archive=/dump --excludeCollection=rocketchat_message_read_receipt
exit
(download the archive.gz and delete it via SFTP)

I need to SFTP to also locate the folder with all the uploads. I forget but there was something in particular about migrating the database before or after you upload the uploads folder if you did it in the wrong order it actually deleted all the uploads

"rc should be turned off
import latest DB
move uploads contents to the app/uploads folder (change permissions to 777)". My notes say that the uploads come after the database is imported. So you might want to look in the server under the app folder and you may see the uploads folder

Okay, when I do this I want to be on call with you to make sure I don’t mess anything up

http://159.65.165.84:3000/home

Okay, logged in

Looks like we have 22 github pages worth of releases to go through if we're doing gradual rocket update

okay there has to be a way to automate this,

Insha'Allah lol

It's pretty simple commands to update so it shouldn't be that hard

so what do you do

I want to document some stuff

stop rc with systemctl, remove installation folder, curl the version, install with npm, move to /opt/Rocket.Chat, chown -R, systemctl start

Database will update automatically w/ rocketchat update

but only if you go one version at a time (good design guys)

is this with docker? Or are the extra steps in docker

I saw a RC version in the docker config I thought

I think only difference would be docker start instead of systemctl start

maybe some dif directory names too

nvm I'm wrong because I forgot about the whole docker compose bit

Docker:

docker pull rocketchat/rocketchat:x.x.x
edit docker-compose.yml to rocketchat/rocketchat:x.x.x
docker-compose stop rocketchat
docker-compose rm rocketchat
docker-compose up -d rocketchat

so that updates image line?

what about mongo version, will that change?

We have to update image line manually for every update :D

mongo version should change automatically, I think

geez, lol

okay once its up, lets try migrating ONE version

Yeah we will keep an MOP or whatever, should make it easier

I had to google that, thats how professional I am

Yep a wagefag taught me that term

i mean it makes sense, just not with all the industry terms

there has to be a way to edit that version in the compose file without going into it

some CLI

There's probably a really easy way we could automate the whole thing I just don't know how

while server is booting up, I'm looking at it

I will reach out to Tyler SD and ask if he knows, he is a very good programmer

I won't be specific with what we're doing

just that I need to update something one version at a time

yea this is why dockers is not the greatest, since we are not experts

I'm not an expert in snap either :man_shrugging_light_skin_tone:

we could probably just do a text replace and remember the previous version or do a regex for the rocketchat/version section

we'd probably need a list of all the versions in an array so it can iterate through each one.

Yeah, that makes sense. It'd also need to know to wait until rc is back online before running the upgrade script again.

or if we could just identify which ones had the mongo scheme chage

Do you want to try jumping ahead by 5 versions at a time and seeing when the schema breaks?

thats not a bad idea

yea

Okay let's start with that then

When it breaks, we then go back?

is that possible?

Yeah and then we know within 5 versions where it breaks

using the snapshopt

we'd go to until last version where it didn't break, then update 1 version at a time for the next 5

save a new screenshot then go back to 5 at a time

I wonder how many scheme changes are out there

this snapshot takes ages

We can try the 5 at a time thing and see how far we get before it breaks and then judge if it's a viable solution from there

If we do the first 5 and it breaks instantly then we scrap that method, but if we can go like 50 versions without a schema break I think it'll be okay even with long snapshot time

that would be ideal. I wish they noted which versions update the schema

maybe we can find the update schema code and then identify the version

Great idea

inb4 it's every version

then we will have to write some script that can do that, no way are we doing this all manually

https://github.com/RocketChat/Rocket.Chat/tree/56b6d334b963e4f8a1b8f85920e04fd3bf082e44/app/models/server/models

these are schemas I think

These look like the tabs in the admin panel

I searched for $addFields in the code which is what addsa field to collections in db

and it pointed to these

Oh okay

4.2.2<br>4.2.1<br>4.2.0<br>4.1.2<br>4.1.1<br>4.1.0<br>4.0.6<br>4.0.5<br>4.0.4<br>4.0.3<br>4.0.2<br>4.0.1<br>4.0.0<br>3.18.3<br>3.18.2<br>3.18.1<br>3.18.0<br>3.17.3<br>3.17.2<br>3.17.1<br>3.17.0<br>3.16.5<br>3.16.4<br>3.16.3<br>3.16.2<br>3.16.1<br>3.16.0<br>3.15.4<br>3.15.3<br>3.15.2<br>3.15.1<br>3.15.0<br>3.14.6<br>3.14.5<br>3.14.4<br>3.14.3<br>3.14.2<br>3.14.1<br>3.14.0<br>3.13.5<br>3.13.4<br>3.13.3<br>3.13.2<br>3.13.1<br>3.13.0<br>3.12.7<br>3.12.6<br>3.12.4<br>3.12.5<br>3.12.3<br>3.12.2<br>3.12.1<br>3.12.0<br>3.11.5<br>3.11.4<br>3.11.3<br>3.11.2<br>3.11.1<br>3.11.0<br>3.10.7<br>3.10.7<br>3.10.6<br>3.10.5<br>3.10.4<br>3.10.3<br>3.10.2<br>3.10.1<br>3.10.0<br>3.9.7<br>3.9.6<br>3.9.5<br>3.9.4<br>3.9.3<br>3.9.2<br>3.9.1<br>3.9.0<br>3.8.9<br>3.8.8<br>3.8.7<br>3.8.6<br>3.8.5<br>3.8.4<br>3.8.3<br>3.8.2<br>3.8.1<br>3.8.0<br>3.7.4<br>3.7.3<br>3.7.2<br>3.7.1<br>3.7.0<br>3.6.3<br>3.6.2<br>3.6.1<br>3.6.0<br>3.5.4<br>3.5.3<br>3.5.2<br>3.5.1<br>3.5.0<br>3.4.3<br>3.4.2<br>3.4.1<br>3.4.0<br>3.3.3<br>3.3.2<br>3.3.1<br>3.3.0<br>

108, almost 109 :nose:

with schema updates/

thats just all of them

rocket chat developers turned me into a bar of soap

lol

I am thinking a bash script like this

<br>#!/bin/bash<br><br>declare -a versionArray=("3.3.0" "3.3.1" "3.3.2" "3.3.3" "3.4.0" "3.4.1" "3.4.2" "3.4.3" "3.5.0" "3.5.1" "3.5.2" "3.5.3" "3.5.4" "3.6.0" "3.6.1" "3.6.2" "3.6.3" "3.7.0" "3.7.1" "3.7.2" "3.7.3" "3.7.4" "3.8.0" "3.8.1" "3.8.2" "3.8.3" "3.8.4" "3.8.5" "3.8.6" "3.8.7" "3.8.8" "3.8.9" "3.9.0" "3.9.1" "3.9.2" "3.9.3" "3.9.4" "3.9.5" "3.9.6" "3.9.7" "3.10.0" "3.10.1" "3.10.2" "3.10.3" "3.10.4" "3.10.5" "3.10.6" "3.10.7" "3.10.7" "3.11.0" "3.11.1" "3.11.2" "3.11.3" "3.11.4" "3.11.5" "3.12.0" "3.12.1" "3.12.2" "3.12.3" "3.12.5" "3.12.4" "3.12.6" "3.12.7" "3.13.0" "3.13.1" "3.13.2" "3.13.3" "3.13.4" "3.13.5" "3.14.0" "3.14.1" "3.14.2" "3.14.3" "3.14.4" "3.14.5" "3.14.6" "3.15.0" "3.15.1" "3.15.2" "3.15.3" "3.15.4" "3.16.0" "3.16.1" "3.16.2" "3.16.3" "3.16.4" "3.16.5" "3.17.0" "3.17.1" "3.17.2" "3.17.3" "3.18.0" "3.18.1" "3.18.2" "3.18.3" "4.0.0" "4.0.1" "4.0.2" "4.0.3" "4.0.4" "4.0.5" "4.0.6" "4.1.0" "4.1.1" "4.1.2" "4.2.0" "4.2.1" "4.2.2")<br><br>declare currentVersion="3.2.2"<br>for v in "${versionArray[@]}"<br>do<br> docker-compose stop rocketchat<br> docker pull rocketchat/rocketchat:$v<br> sed -i "s/rocket.chat:$currentVersion/rocket.chat:$v/g" /home/andrewj/docker-compose.yml<br> docker-compose rm rocketchat<br> docker-compose up -d rocketchat<br> currentVersion=$v<br>done<br>

it might hang on the docker-compose up

or does -d mean detach, so it will move along

So its missing after docker-compose up -d rocketchat how do we know its finished botting up so we can move on to the next version

ping port 3000?

It's up for me

Pinging the port might work. But it might always ping because it's open.

We could just set it on a timer I guess.

yea I am gonna do a timer for 30 seconds and however long it takes to get next version downloaded

not every milestone has a version to download, here is official list https://hub.docker.com/r/rocketchat/rocket.chat/tags/?page=10&ordering=last_updated

I'll have to update my list

fingers crossed that one of the undownloadable versions doesn't have schema changes

but we can probably get it from github if so

yea, also it looks like docker pulls it automatically by just updating the compose

okay version updated

now to run the script lol

:fingers_crossed: