148 lines
4.9 KiB
Markdown
148 lines
4.9 KiB
Markdown
# LumaOps server versus Gitea audit
|
|
|
|
This audit compares the supplied `lumaops_server.zip` and `LumaOps_gitea.zip`.
|
|
|
|
## Main result
|
|
|
|
The main Unraid working tree and the supplied Gitea checkout point to exactly the same commit:
|
|
|
|
```text
|
|
d42d4a7f08240c478d07466e3fabec654dc71367
|
|
```
|
|
|
|
Latest subject:
|
|
|
|
```text
|
|
Preserve colors across Aura zone updates
|
|
```
|
|
|
|
There is therefore no source-version drift at the root of the live LumaOps folder.
|
|
|
|
## Root Git repository
|
|
|
|
The root `.git` directory should remain in place. It enables:
|
|
|
|
- exact-SHA verification;
|
|
- controlled fetch and reset;
|
|
- a reliable previous-version reference;
|
|
- rollback without copying a second complete source tree.
|
|
|
|
The archived server copy showed one root status difference for `scripts/unraid-hardware-setup.sh`: file mode `100755 → 100644`. This is consistent with Unix executable bits being lost during ZIP handling. The file content did not differ. Check the executable bit directly on Unraid before deployment.
|
|
|
|
|
|
## Origin URL mismatch to resolve
|
|
|
|
The supplied server root uses:
|
|
|
|
```text
|
|
ssh://git@127.0.0.1:222/NuklearRabbit/LumaOps.git
|
|
```
|
|
|
|
The supplied Gitea checkout uses:
|
|
|
|
```text
|
|
https://gitea.itworx.tech/Jens/LumaOps.git
|
|
```
|
|
|
|
Although both archives currently point to the same commit, these are different
|
|
repository paths. Before the first ForgeFlow deployment, choose the server-
|
|
reachable URL for the authoritative `Jens/LumaOps` repository, for example an
|
|
SSH URL through `127.0.0.1:222` when Gitea runs on the same Unraid host.
|
|
|
|
ForgeFlow 0.4 detects this mismatch. Deployment is blocked unless the profile
|
|
matches the existing origin or **Align an existing server origin to this URL**
|
|
is explicitly enabled.
|
|
|
|
## Runtime and persistent paths
|
|
|
|
The server copy contains runtime data that must not be replaced by source updates:
|
|
|
|
- `appdata/`
|
|
- `data/`
|
|
- `logs/`
|
|
- `.env` and application-specific configuration
|
|
|
|
The repository `.gitignore` already excludes the principal runtime paths. ForgeFlow's SSH strategy uses Git reset without `git clean`, so untracked persistent data remains in place.
|
|
|
|
## Compose and Unraid integration
|
|
|
|
The root `docker-compose.yml` is already suitable as the authoritative deployment definition. It includes:
|
|
|
|
- build context at the project root;
|
|
- container name `lumaops`;
|
|
- the Unraid `dockerman` label;
|
|
- a Web UI label;
|
|
- an Unraid icon label;
|
|
- `${WEB_PORT:-1223}:${APP_PORT:-8080}`;
|
|
- persistent relative volumes;
|
|
- USB, HID and I²C devices;
|
|
- a healthcheck.
|
|
|
|
ForgeFlow should use this existing Compose file rather than generate a replacement. Ports and complex device mappings belong in the repository's maintained Compose definition.
|
|
|
|
The supplied `.dockerignore` already excludes `.git`, so keeping the root Git
|
|
working tree does **not** copy Git history into the Docker build context. It does
|
|
not yet explicitly exclude the existing runtime/legacy folders `appdata/`,
|
|
`data/`, `logs/` and `source/`. Before the first production rebuild, add the
|
|
paths that are not build inputs:
|
|
|
|
```text
|
|
appdata/
|
|
data/
|
|
logs/
|
|
source/
|
|
.forgeflow/
|
|
```
|
|
|
|
ForgeFlow 0.4 detects existing preserved paths and nested Git repositories that
|
|
are missing from `.dockerignore` and reports them as a preflight warning. The
|
|
tool does not silently edit a source-controlled `.dockerignore`; the correction
|
|
should be committed to Gitea so every deployment uses the same build context.
|
|
|
|
## Nested `source/` repository
|
|
|
|
The server archive also contains a nested Git working tree under:
|
|
|
|
```text
|
|
source/
|
|
```
|
|
|
|
Its HEAD is:
|
|
|
|
```text
|
|
b746a52af1613f4291235f5e8165b8197a269a79
|
|
```
|
|
|
|
It was ahead of its own upstream and included rebase metadata in the supplied archive. The root Compose file uses build context `.` and does not reference `source/`. This strongly indicates that `source/` is an abandoned or historical checkout rather than the active deployment source.
|
|
|
|
ForgeFlow reports this as a nested-repository warning and does not remove it automatically.
|
|
|
|
Recommended migration:
|
|
|
|
1. Back up `/mnt/user/appdata/lumaops`.
|
|
2. Verify on Unraid that `docker compose config` uses the root project.
|
|
3. Stop changing files in `source/`.
|
|
4. Rename it temporarily to `source.legacy-backup`.
|
|
5. Rebuild and test LumaOps from the root.
|
|
6. Remove the legacy copy only after a successful validation period.
|
|
|
|
Do not delete the root `.git` directory. Also do not delete the nested `source/`
|
|
directory as part of the first ForgeFlow test. Treat its cleanup as a separate,
|
|
backed-up migration after the root deployment and rollback have both been
|
|
validated.
|
|
|
|
## Recommended ForgeFlow profile
|
|
|
|
```text
|
|
Provider: SSH / Unraid
|
|
Server folder: lumaops
|
|
Branch: main
|
|
Compose mode: Repository/server Compose
|
|
Compose file: docker-compose.yml
|
|
Clone URL: the Git URL reachable from Unraid
|
|
Healthcheck: the existing LumaOps health URL, when exposed
|
|
Preserve paths: .env, appdata, data, logs, config, compose.override.yml
|
|
```
|
|
|
|
No folder rename is required for LumaOps because `lumaops` already aligns with the repository name.
|