lukechilds
/
umbrel
mirror of https://github.com/lukechilds/umbrel.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
282 Commits
288 Branches
26 Tags
2.3 MiB
 
 
Tree: ccd8f28011
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'ccd8f28011'
${ noResults }
umbrel/bin/update/README.md

4.2 KiB
Raw Blame History

Over-The-Air (OTA) Updates

How over-the-air updates work on Umbrel.

Execution Flow

  1. New developments across the any/entire fleet of Umbrel's services (bitcoind, lnd, dashboard, middleware, etc) are made, which maintain their own independent version-control and release-schedule. Subsequently, their new docker images are built, tagged and pushed to Docker Hub.

  2. The newly built and tagged images are updated in the main repository's (i.e. this repo) docker-compose.yml file.

  3. Any new developments to the main repository (i.e. this repo) are made, eg. adding a new directory or a new config file.

  4. To prepare a new release of Umbrel, called vX.Y.Z, a PR is opened that updates the info.json file to:

{
    "version": "X.Y.Z",
    "name": "Umbrel vX.Y.Z",
    "notes": "This release contains a number of bug fixes and new features."
    "requires": ">=A.B.C" 
}

  1. Once the PR is merged, the master branch is immediately tagged vX.Y.Z and released on GitHub.

  2. Thus the new info.json will automatically be available at https://raw.githubusercontent.com/getumbrel/umbrel/master/info.json. This is what triggers the OTA update.

  3. When the user opens his umbrel-dashboard, it periodically polls umbrel-manager to check for new updates.

  4. umbrel-manager fetches the latest info.json from umbrel's main repo's master branch using GET https://raw.githubusercontent.com/getumbrel/umbrel/master/info.json, compares it's version with the version of the local $UMBREL_ROOT/info.json file, and exits if both the versions are same.

  5. If fetched version > local version, umbrel-manager checks if local version satisfies the requires condition in the fetched info.json.

  6. If not, umbrel-manager makes a GET request to https://raw.githubusercontent.com/getumbrel/umbrel/vX.Y.Z/info.json and repeats step 8 and 9 until local version < fetched version and local version doesn't fulfill the fetched requires condition.

  7. umbrel-manager then returns the satisfactory info.json to umbrel-dashboard.

  8. umbrel-dashboard then alerts the user regarding the new update, and after the user consents, it makes a POST request to umbrel-manager to start the update process.

  9. umbrel-manager creates a signal file on the mounted host OS volume ($UMBREL_ROOT/signals/update) with the version X.Y.Z, and returns 200 OK to the umbrel-dashboard.

  10. fswatch, a file monitoring tool that's continuosly monitoring the $UMBREL_ROOT/signals/update file notices the change, and immeditaly runs $UMBREL_ROOT/bin/update/start.sh as root.

  11. $UMBREL_ROOT/bin/update/start.sh clones release vX.Y.Z from github in /tmp/umbrel-vX.Y.Z.

  12. $UMBREL_ROOT/bin/update/start.sh then executes all of the following update scripts from the new release /tmp/umbrel-vX.Y.Z one-by-one:

All of the above scripts continuosly update $UMBREL_ROOT/statuses/update-status.json with the progress of upgrade, which the dashboard periodically fetches every 2s via umbrel-manager to notify the user on the progress of update.