|
| 1 | +# gooseBit |
| 2 | +<img src="img/goosebit-logo.png" style="width: 100px; height: 100px; display: block;"> |
| 3 | + |
| 4 | +--- |
| 5 | + |
| 6 | +A simplistic, opinionated remote update server implementing hawkBit™'s [DDI API](https://eclipse.dev/hawkbit/apis/ddi_api/). |
| 7 | + |
| 8 | +## Setup |
| 9 | + |
| 10 | +To set up, install the dependencies in `pyproject.toml` with `poetry install`. Then you can run gooseBit by running `main.py`. |
| 11 | + |
| 12 | +## Initial Startup |
| 13 | + |
| 14 | +The first time you start gooseBit, you should change the default username and password inside `settings.yaml`. |
| 15 | +The default login credentials for testing are `admin@goosebit.local`, `admin`. |
| 16 | + |
| 17 | +## Assumptions |
| 18 | +- [SWUpdate](https://swupdate.org) used on device side. |
| 19 | + |
| 20 | +## Current Feature Set |
| 21 | + |
| 22 | +### Firmware repository |
| 23 | +Uploading firmware images through frontend. Accepted file naming patterns are `model_revision_date_time.swu` / |
| 24 | +`model_date_time.swu`. Date and time is used to determine the most current version for a device with a give model |
| 25 | +and revision. |
| 26 | + |
| 27 | +### Automatic device registration |
| 28 | +First time a new device connects, its configuration data is requested. `hw_model` and `hw_revision` are captured from |
| 29 | +the configuration data (both fall back to `default` if not provided) which allows to distinguish different device |
| 30 | +types and their revisions. |
| 31 | + |
| 32 | +### Automatically update device to newest firmware |
| 33 | +Once a device is registered it will get the newest available firmware from the repository based on model and revision. |
| 34 | + |
| 35 | +### Manually update device to specific firmware |
| 36 | +Frontend allows to assign specific firmware to be rolled out. |
| 37 | + |
| 38 | +### Firmware rollout |
| 39 | +Rollouts allow a fine-grained assignment of firmwares to devices. The reported device model and revision is combined |
| 40 | +with the manually set feed and flavor values on a device to determine a matching rollout. |
| 41 | + |
| 42 | +The feed is meant to model either different environments (like: dev, qa, live) or update channels (like. candidate, |
| 43 | +fast, stable). |
| 44 | + |
| 45 | +The flavor can be used for different type of builds (like: debug, prod). |
| 46 | + |
| 47 | +### Pause updates |
| 48 | +Device can be pinned to its current firmware. |
| 49 | + |
| 50 | +### Realtime update logs |
| 51 | +While an update is running, the update logs are captured and visualized in the frontend. |
0 commit comments