feat(screenshots): add real application screenshots to README and update package publishing
CI & Test NaxOS Management API / test (push) Successful in 1m46s

This commit is contained in:
Lukas Holzner
2026-09-04 09:04:46 +02:00
parent 4d1becd781
commit a8173d724a
10 changed files with 28 additions and 5 deletions
+20 -5
View File
@@ -39,10 +39,25 @@ jobs:
npm pack npm pack
TGZ_FILE=$(ls naxos-api-*.tgz | head -n 1) TGZ_FILE=$(ls naxos-api-*.tgz | head -n 1)
echo "Packaging $TGZ_FILE to Gitea Packages registry..." echo "Packaging $TGZ_FILE to Gitea Packages registry..."
curl -s --fail-with-body -X PUT \ TOKEN="${{ secrets.PACKAGE_TOKEN }}"
-H "Authorization: token ${{ secrets.GITEA_TOKEN }}" \ if [ -z "$TOKEN" ]; then
TOKEN="${{ secrets.GITEA_TOKEN }}"
fi
RESPONSE=$(curl -s -w "\nHTTP_STATUS:%{http_code}" -X PUT \
-H "Authorization: token ${TOKEN}" \
--upload-file "$TGZ_FILE" \ --upload-file "$TGZ_FILE" \
"${{ github.server_url }}/api/packages/naxos/generic/naxos-api/1.0.0/$TGZ_FILE" || echo "Generic package uploaded or exists" "${{ github.server_url }}/api/packages/naxos/generic/naxos-api/1.0.0/$TGZ_FILE")
STATUS=$(echo "$RESPONSE" | grep "HTTP_STATUS:" | cut -d: -f2)
BODY=$(echo "$RESPONSE" | grep -v "HTTP_STATUS:")
echo "Package upload HTTP status: $STATUS"
if [ "$STATUS" -eq 201 ] || [ "$STATUS" -eq 200 ] || [ "$STATUS" -eq 204 ]; then
echo "Successfully published $TGZ_FILE to Gitea Packages!"
elif [ "$STATUS" -eq 409 ]; then
echo "Package version 1.0.0 already published in Gitea Packages: $BODY"
else
echo "Failed to publish package to Gitea Packages ($STATUS): $BODY"
exit 1
fi
echo "//git.lholz.de/api/packages/naxos/npm/:_authToken=${{ secrets.GITEA_TOKEN }}" >> ~/.npmrc echo "//git.lholz.de/api/packages/naxos/npm/:_authToken=${TOKEN}" >> ~/.npmrc
npm publish || echo "NPM package published or exists" npm publish || echo "NPM package published or exists in registry"
+8
View File
@@ -4,6 +4,14 @@
The **NaxOS Management Daemon** serves as the core orchestration brain of the NaxOS storage appliance. It bridges web dashboard interactions with underlying declarative NixOS module generation, OpenZFS primitives, GitOps synchronization, and workload lifecycle controls. The **NaxOS Management Daemon** serves as the core orchestration brain of the NaxOS storage appliance. It bridges web dashboard interactions with underlying declarative NixOS module generation, OpenZFS primitives, GitOps synchronization, and workload lifecycle controls.
## Appliance Interface Showcase
| Overview & Telemetry | OpenZFS Storage Engine |
| :---: | :---: |
| ![Dashboard Overview](docs/images/dashboard-overview.png) | ![Storage Management](docs/images/storage-management.png) |
| **CNCF Perses Analytics** | **App Store & Runtimes** |
| ![Perses Analytics](docs/images/perses-analytics.png) | ![App Store](docs/images/app-store.png) |
## Core Capabilities ## Core Capabilities
- **Declarative NixOS Compiler**: Translates REST API actions directly into standard NixOS module syntax (`generated-naxos-config.nix`), validated before activating via `nixos-rebuild switch`. - **Declarative NixOS Compiler**: Translates REST API actions directly into standard NixOS module syntax (`generated-naxos-config.nix`), validated before activating via `nixos-rebuild switch`.
Binary file not shown.

After

Width:  |  Height:  |  Size: 138 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 150 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 116 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 139 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB