8 Commits
Author SHA1 Message Date
DragonSlayer_14andClaude Sonnet 5 12eaf6461d CI: Fuegt automatisiertes Nightly-Release hinzu und behebt Zeitzone bei geplanten Workflows
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
Nightly Build & Publish / Erkenne relevante Code-Änderungen (push) Waiting to run
Nightly Build & Publish / Build & Publish Packages (Nightly) (push) Blocked by required conditions
TruffleHog Secret Scan / TruffleHog (push) Waiting to run
Security Scans / Trivy & OSV-Scanner (push) Successful in 1m6s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m34s
- Neuer Workflow "nightly-pr.yaml": Erstellt und merged taeglich automatisch
  einen Pull Request von dev nach nightly (09:00 Uhr Europe/Berlin); legt den
  nightly-Branch bei Bedarf initial von dev an.
- Neuer Workflow "nightly.yaml": Baut und veroeffentlicht Pakete bei
  Aenderungen auf nightly in den nightly-Kanal der Paket-Registry
  (Debian/RPM/Arch); erstellt bewusst kein Gitea-Release.
- CRON_TZ=Europe/Berlin in security-scan.yaml und trufflehog-scan.yaml
  ergaenzt: Gitea Actions interpretiert schedule-Cron sonst in der lokalen
  Zeitzone des Gitea-Servers statt in der beabsichtigten Zeitzone.
- AGENTS.md aktualisiert (Abschnitt 5.1) um die neuen Workflows zu dokumentieren.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-21 00:27:19 +02:00
DragonSlayer_14andClaude Sonnet 5 a5b48e560e CI: Renovate-Schedule von wöchentlich auf täglich verkürzt
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 27s
Security Scans / Trivy & OSV-Scanner (push) Successful in 56s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m20s
'before 6am on monday' erlaubte nur einmal pro Woche automatische
PR-Erstellung - jeder außerhalb dieses Fensters gefundene Update musste
im Dependency-Dashboard-Issue erst manuell abgehakt werden ("Awaiting
Schedule"), auch nach der letzten Automerge-Änderung. 'before 6am' (ohne
Wochentag) öffnet das Fenster jetzt täglich, PRs für sichere Updates
laufen dadurch spürbar zeitnaher und größtenteils ohne manuelles
Abhaken durch.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 23:36:48 +02:00
DragonSlayer_14andClaude Sonnet 5 ce266787b6 CI: Renovate merged sichere Updates automatisch, unit-tests laufen jetzt auch für PRs gegen dev
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 31s
Security Scans / Trivy & OSV-Scanner (push) Successful in 53s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m20s
Patch-/Minor-/Digest-Updates (Cargo, Gitea Actions, Docker-Images)
werden künftig automatisch gemergt, sobald alle CI-Checks erfolgreich
sind - Major-Updates bleiben weiterhin manuell zu prüfen, da sie eher
brechende Änderungen enthalten.

Voraussetzung dafür: unit-tests.yaml (der eigentliche 'cargo test'-Lauf)
löste bisher nur bei Pull Requests gegen 'testing' aus, nicht gegen
'dev' - Renovate-PRs zielen aber auf 'dev' und wurden damit nie durch
einen echten Build/Test abgesichert, nur durch die Security-/Secret-
Scans. Jetzt läuft er auch dort.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 23:27:16 +02:00
DragonSlayer_14andClaude Sonnet 5 121bffc289 CI: Ersetzt rohes actions/cache für Cargo-Build-Artefakte durch Swatinem/rust-cache
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 29s
Security Scans / Trivy & OSV-Scanner (push) Successful in 55s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 6m57s
Ein rohes 'actions/cache' auf target/ lieferte zwar einen technischen
Cache-Hit, Cargo kompilierte die Abhängigkeiten aber trotzdem neu: der
tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten
Dateien dieselbe Mtime, wodurch Cargos Fingerprinting nicht mehr
zuverlässig erkennen kann, was älter/neuer als was ist. Swatinem/rust-cache
behebt das gezielt (u. a. gezielte Mtime-Korrektur nach dem Restore).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 23:18:19 +02:00
Gitea-Bot fc68daddac Chore: Erhöht Patch-Version auf 2.0.4 für Promotion nach testing
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 29s
Security Scans / Trivy & OSV-Scanner (push) Successful in 57s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 56s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 25s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m40s
Unit-Tests / Unit-Tests (pull_request) Successful in 3m23s
2026-09-20 20:33:00 +00:00
DragonSlayer_14andClaude Sonnet 5 3bf2ce0718 Fix: Paketinstallation blockiert nicht mehr synchron auf smart-mount-mount.service
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 19s
Security Scans / Trivy & OSV-Scanner (push) Successful in 29s
Auto Patch-Version-Bump (Dev → Testing PR) / Erkenne relevante Änderungen im PR (pull_request) Successful in 13s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 47s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 25s
Auto Patch-Version-Bump (Dev → Testing PR) / Patch-Version erhöhen & auf Dev pushen (pull_request) Successful in 14s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 42s
Unit-Tests / Unit-Tests (pull_request) Successful in 4m18s
'systemctl enable --now smart-mount-mount.service' im postinst/RPM-
Scriptlet wartete synchron auf den kompletten 'mount --all'-Lauf -
bei nicht erreichbaren Laufwerken (Netzwerk-Timeouts pro Paar) blieb
'apt'/'dpkg'/'pacman' dadurch minutenlang ohne sichtbare Rückmeldung
hängen (Logs gehen ins Journal, nicht ins Paketmanager-Terminal).

Jetzt: 'systemctl enable' + 'systemctl start --no-block' für den
Mount-Service (stößt den ersten Mount-Versuch nur an, wartet nicht
darauf), 'enable --now' bleibt für den Watch-Timer (Timer "armen" ist
immer sofort fertig). scripts/package-arch.py unterscheidet das generisch
anhand der Dateiendung (.timer vs. .service), ohne den Anwendungsnamen
hart zu codieren. Zusätzlich TimeoutStartSec=600 im Unit-File als
Obergrenze gegen echte Hänger.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 22:31:53 +02:00
Gitea-Bot c4a415e3e4 Chore: Erhöht Patch-Version auf 2.0.3 für Promotion nach testing
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 26s
Security Scans / Trivy & OSV-Scanner (push) Successful in 54s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 54s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 28s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 1m29s
Unit-Tests / Unit-Tests (pull_request) Successful in 3m10s
2026-09-20 17:17:13 +00:00
DragonSlayer_14andClaude Sonnet 5 18d84c94f6 Fix: mount/unmount melden Fehlschläge jetzt korrekt, Logs im Journal sichtbar und persistent
Testing Build, Publish & Preview Release / Build, Publish Packages (Testing) & Create Preview Release (push) Skipped
TruffleHog Secret Scan / TruffleHog (push) Successful in 15s
Security Scans / Trivy & OSV-Scanner (push) Successful in 31s
TruffleHog Secret Scan / TruffleHog (pull_request) Successful in 24s
Auto Patch-Version-Bump (Dev → Testing PR) / Erkenne relevante Änderungen im PR (pull_request) Successful in 15s
Code Quality (Auto-Format & Clippy-Fix) / Formatierung & Clippy automatisch beheben (push) Successful in 59s
Auto Patch-Version-Bump (Dev → Testing PR) / Patch-Version erhöhen & auf Dev pushen (pull_request) Successful in 13s
Security Scans / Trivy & OSV-Scanner (pull_request) Successful in 44s
Unit-Tests / Unit-Tests (pull_request) Successful in 4m12s
'mount --all'/'unmount --all' gaben bisher immer Ok(()) zurück, selbst
wenn einzelne Laufwerkspaare nicht (aus)gehängt werden konnten (nur als
Text ausgegeben, nie propagiert) - anders als 'watch'. Dadurch zeigte
'systemctl status smart-mount-mount' nie "failed", egal was beim
Booten schiefging. run_mount/run_unmount propagieren Fehlschläge jetzt
wie 'watch' als Prozess-Fehler.

Zusätzlich: logger_ctdra::set_log_dir() zeigt jetzt auf
/var/log/smart-mount statt auf einen zufälligen Temp-Ordner, beide
systemd-Units haben ein festes SyslogIdentifier=smart-mount mit
explizitem StandardOutput/StandardError=journal (journalctl -t
smart-mount zeigt damit alles gebündelt), und
smart-mount-mount.service bleibt dank RemainAfterExit=yes nach einem
erfolgreichen Lauf als "active (exited)" sichtbar statt sofort wieder
auf "inactive" zu springen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-20 19:16:08 +02:00
19 changed files with 437 additions and 62 deletions
+7 -9
View File
@@ -24,16 +24,14 @@ jobs:
components: clippy, rustfmt
cache: false
# Ein rohes 'actions/cache' auf target/ liefert zwar einen technischen Cache-Hit (Dateien
# werden wiederhergestellt), Cargo kompiliert die Abhängigkeiten aber oft trotzdem neu:
# Der tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten Dateien dieselbe
# Mtime, wodurch Cargos Fingerprinting nicht mehr zuverlässig erkennen kann, was
# älter/neuer als was ist, und sicherheitshalber alles neu baut. Swatinem/rust-cache ist
# genau dafür gebaut (u. a. gezielte Mtime-Korrektur nach dem Restore).
- name: Cache Cargo-Abhängigkeiten & Build-Artefakte
uses: actions/cache@v6
with:
path: |
~/.cargo/registry
~/.cargo/git
target
key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
restore-keys: |
cargo-${{ runner.os }}-
uses: Swatinem/rust-cache@v2
- name: Formatierung automatisch beheben
run: cargo fmt
+9 -9
View File
@@ -47,16 +47,16 @@ jobs:
toolchain: stable
cache: false
# Ein rohes 'actions/cache' auf target/ liefert zwar einen technischen Cache-Hit
# (Dateien werden restauriert), Cargo kompiliert die Abhängigkeiten aber trotzdem neu:
# Der tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten Dateien
# (Quelldateien wie kompilierte .rlib/.d-Dateien) dieselbe Mtime, wodurch Cargos
# Fingerprinting nicht mehr zuverlässig erkennen kann, was tatsächlich älter/neuer als
# was ist, und sicherheitshalber alles neu baut. Swatinem/rust-cache ist genau dafür
# gebaut (u. a. gezielte Mtime-Korrektur nach dem Restore) und cached dabei automatisch
# auch beide Cross-Compilation-Targets (x86_64 + aarch64) in diesem Job.
- name: Cache Cargo-Abhängigkeiten & Build-Artefakte
uses: actions/cache@v6
with:
path: |
~/.cargo/registry
~/.cargo/git
target
key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
restore-keys: |
cargo-${{ runner.os }}-
uses: Swatinem/rust-cache@v2
- name: Alte Paketierungs-Ausgaben aus dem Cache entfernen
run: rm -rf target/debian target/generate-rpm target/arch target/completions
+91
View File
@@ -0,0 +1,91 @@
name: Nightly Auto-Merge (Dev → Nightly)
on:
schedule:
# Gitea Actions interpretiert 'schedule'-Cron standardmaessig in der lokalen
# Zeitzone des Gitea-Servers (anders als GitHub Actions, das immer UTC nutzt).
# Das CRON_TZ-Praefix ist eine Gitea-Erweiterung und legt die Zeitzone explizit
# und DST-sicher fest, unabhaengig von der Server-Konfiguration.
- cron: "CRON_TZ=Europe/Berlin 0 9 * * *"
workflow_dispatch:
jobs:
merge-dev-into-nightly:
name: Erstelle & merge automatisch PR von dev nach nightly
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v7
with:
fetch-depth: 0
token: ${{ secrets.PACKAGE_TOKEN || secrets.RELEASE_TOKEN || secrets.PUBLISH_TOKEN || secrets.API_TOKEN || secrets.PAT_TOKEN || secrets.CUSTOM_TOKEN || secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN || github.token }}
- name: Stelle sicher, dass der nightly-Branch existiert
run: |
git fetch origin dev
if git ls-remote --exit-code --heads origin nightly > /dev/null 2>&1; then
echo "nightly-Branch existiert bereits."
else
echo "nightly-Branch existiert noch nicht, erstelle ihn initial von dev..."
git push origin origin/dev:refs/heads/nightly
fi
- name: Prüfe auf Unterschiede zwischen dev und nightly
id: diff
run: |
git fetch origin nightly
if git diff --quiet origin/nightly origin/dev; then
echo "Keine Unterschiede zwischen dev und nightly, überspringe."
echo "has_changes=false" >> "$GITHUB_OUTPUT"
else
echo "has_changes=true" >> "$GITHUB_OUTPUT"
fi
- name: Prüfe auf bereits offenen PR nach nightly
id: check_pr
if: steps.diff.outputs.has_changes == 'true'
env:
GITEA_URL: ${{ gitea.server_url || github.server_url }}
REPO: ${{ gitea.repository || github.repository }}
TOKEN: ${{ secrets.PACKAGE_TOKEN || secrets.RELEASE_TOKEN || secrets.PUBLISH_TOKEN || secrets.API_TOKEN || secrets.PAT_TOKEN || secrets.CUSTOM_TOKEN || secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN || github.token }}
run: |
OPEN_PRS=$(curl -s -H "Authorization: token ${TOKEN}" "${GITEA_URL}/api/v1/repos/${REPO}/pulls?state=open&limit=50")
PR_NUMBER=$(echo "$OPEN_PRS" | jq -r '[.[] | select(.base.ref == "nightly" and .head.ref == "dev")][0].number // empty')
echo "Bereits offener dev→nightly PR: ${PR_NUMBER:-keiner}"
echo "pr_number=${PR_NUMBER}" >> "$GITHUB_OUTPUT"
- name: Erstelle PR (dev -> nightly)
id: create_pr
if: steps.diff.outputs.has_changes == 'true' && steps.check_pr.outputs.pr_number == ''
env:
GITEA_URL: ${{ gitea.server_url || github.server_url }}
REPO: ${{ gitea.repository || github.repository }}
TOKEN: ${{ secrets.PACKAGE_TOKEN || secrets.RELEASE_TOKEN || secrets.PUBLISH_TOKEN || secrets.API_TOKEN || secrets.PAT_TOKEN || secrets.CUSTOM_TOKEN || secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN || github.token }}
run: |
DATE="$(date -u +%Y-%m-%d)"
PAYLOAD=$(jq -n --arg title "Nightly-Build: Merge dev in nightly (${DATE})" --arg head "dev" --arg base "nightly" \
'{title: $title, head: $head, base: $base}')
RESP=$(curl -f -s -S -X POST \
-H "Authorization: token ${TOKEN}" \
-H "Content-Type: application/json" \
-d "$PAYLOAD" \
"${GITEA_URL}/api/v1/repos/${REPO}/pulls")
PR_NUMBER=$(echo "$RESP" | jq -r '.number')
echo "PR #${PR_NUMBER} erstellt."
echo "pr_number=${PR_NUMBER}" >> "$GITHUB_OUTPUT"
- name: Merge PR automatisch
if: steps.diff.outputs.has_changes == 'true'
env:
GITEA_URL: ${{ gitea.server_url || github.server_url }}
REPO: ${{ gitea.repository || github.repository }}
TOKEN: ${{ secrets.PACKAGE_TOKEN || secrets.RELEASE_TOKEN || secrets.PUBLISH_TOKEN || secrets.API_TOKEN || secrets.PAT_TOKEN || secrets.CUSTOM_TOKEN || secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN || github.token }}
PR_NUMBER: ${{ steps.create_pr.outputs.pr_number || steps.check_pr.outputs.pr_number }}
run: |
echo "Merge PR #${PR_NUMBER} automatisch (dev -> nightly)..."
curl -f -s -S -X POST \
-H "Authorization: token ${TOKEN}" \
-H "Content-Type: application/json" \
-d '{"Do": "merge"}' \
"${GITEA_URL}/api/v1/repos/${REPO}/pulls/${PR_NUMBER}/merge"
echo "PR #${PR_NUMBER} erfolgreich gemerged."
+171
View File
@@ -0,0 +1,171 @@
name: Nightly Build & Publish
on:
push:
branches:
- nightly
jobs:
detect-changes:
name: Erkenne relevante Code-Änderungen
runs-on: ubuntu-latest
outputs:
code_changed: ${{ steps.filter.outputs.code }}
steps:
- name: Checkout Repository
uses: actions/checkout@v7
- name: Prüfe auf Änderungen am Programmcode
uses: dorny/paths-filter@v4
id: filter
with:
filters: |
code:
- 'src/**'
- 'Cargo.toml'
- 'Cargo.lock'
- 'scripts/**'
- '.cargo/**'
- '.gitea/workflows/nightly.yaml'
build-and-publish:
name: Build & Publish Packages (Nightly)
needs: detect-changes
if: needs.detect-changes.outputs.code_changed == 'true'
runs-on: ubuntu-latest
env:
CARGO_BINSTALL_VERSION: "1.23.0"
CARGO_DEB_VERSION: "3.8.0"
CARGO_GENERATE_RPM_VERSION: "0.21.0"
steps:
- name: Checkout Repository
uses: actions/checkout@v7
- name: Install Rust Toolchain
uses: actions-rust-lang/setup-rust-toolchain@v2
with:
toolchain: stable
cache: false
- name: Cache Cargo-Abhängigkeiten & Build-Artefakte
uses: Swatinem/rust-cache@v2
- name: Alte Paketierungs-Ausgaben aus dem Cache entfernen
run: rm -rf target/debian target/generate-rpm target/arch target/completions
- name: Install Cross-Compilation Toolchains (apt)
run: |
sudo apt-get update
sudo apt-get install -y gcc-aarch64-linux-gnu
- name: Ermittle Rust-Version für Rustup-Target-Cache-Key
run: echo "RUST_VERSION=$(rustc --version | awk '{print $2}')" >> "$GITHUB_ENV"
- name: Cache Rustup Cross-Compilation-Targets
id: cache-rustup-targets
uses: actions/cache@v6
with:
path: |
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu
key: rustup-targets-${{ runner.os }}-${{ env.RUST_VERSION }}
- name: Add Rust Cross-Compilation Targets
if: steps.cache-rustup-targets.outputs.cache-hit != 'true'
run: rustup target add aarch64-unknown-linux-gnu
- name: PATH um Cargo-bin-Verzeichnis ergänzen
run: |
mkdir -p ~/.cargo/bin
echo "$HOME/.cargo/bin" >> "$GITHUB_PATH"
- name: Cache Packaging-Tools (cargo-binstall, cargo-deb, cargo-generate-rpm)
id: cache-packaging-tools
uses: actions/cache@v6
with:
path: |
~/.cargo/bin/cargo-binstall
~/.cargo/bin/cargo-deb
~/.cargo/bin/cargo-generate-rpm
key: packaging-tools-${{ runner.os }}-${{ env.CARGO_BINSTALL_VERSION }}-${{ env.CARGO_DEB_VERSION }}-${{ env.CARGO_GENERATE_RPM_VERSION }}
- name: Install Packaging Tools (Prebuilt Binaries)
if: steps.cache-packaging-tools.outputs.cache-hit != 'true'
run: |
curl -fsSL "https://github.com/cargo-bins/cargo-binstall/releases/download/v${CARGO_BINSTALL_VERSION}/cargo-binstall-x86_64-unknown-linux-musl.tgz" | tar -xz -C ~/.cargo/bin
~/.cargo/bin/cargo-binstall -y --no-symlinks "cargo-deb@${CARGO_DEB_VERSION}" "cargo-generate-rpm@${CARGO_GENERATE_RPM_VERSION}"
- name: Run Tests
run: |
cargo test
- name: Build Release Binaries
run: |
cargo build --release --target x86_64-unknown-linux-gnu
cargo build --release --target aarch64-unknown-linux-gnu
- name: Generate Shell Completions
run: |
cargo build --release --bin generate-completions
./target/release/generate-completions target/completions
- name: Determine Build Number
id: build_num
env:
GITEA_URL: ${{ gitea.server_url || github.server_url }}
REPO: ${{ gitea.repository || github.repository }}
REPO_OWNER: ${{ gitea.repository_owner || github.repository_owner }}
TOKEN: ${{ secrets.PACKAGE_TOKEN || secrets.RELEASE_TOKEN || secrets.PUBLISH_TOKEN || secrets.API_TOKEN || secrets.PAT_TOKEN || secrets.CUSTOM_TOKEN || secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN || github.token }}
run: |
BUILD_NUM=$(python3 scripts/get-build-number.py)
echo "build_number=${BUILD_NUM}" >> $GITHUB_OUTPUT
echo "BUILD_NUMBER=${BUILD_NUM}" >> $GITHUB_ENV
echo "Ermittelte Build-Nummer: ${BUILD_NUM}"
- name: Build Debian Packages (.deb)
run: |
cargo deb --target x86_64-unknown-linux-gnu --deb-revision "${BUILD_NUMBER}" --no-build
cargo deb --target aarch64-unknown-linux-gnu --deb-revision "${BUILD_NUMBER}" --no-build
- name: Build Fedora / RPM Packages (.rpm)
run: |
mkdir -p target/generate-rpm
cargo generate-rpm --target x86_64-unknown-linux-gnu -s "release=\"${BUILD_NUMBER}\"" -o target/generate-rpm
cargo generate-rpm --target aarch64-unknown-linux-gnu -s "release=\"${BUILD_NUMBER}\"" -o target/generate-rpm
- name: Build Arch Linux Packages (.pkg.tar.zst)
run: |
python3 scripts/package-arch.py --target x86_64-unknown-linux-gnu --pkgrel "${BUILD_NUMBER}"
python3 scripts/package-arch.py --target aarch64-unknown-linux-gnu --pkgrel "${BUILD_NUMBER}"
- name: Publish Packages to Gitea Package Registry
env:
GITEA_URL: ${{ gitea.server_url || github.server_url }}
REPO_OWNER: ${{ gitea.repository_owner || github.repository_owner }}
TOKEN: ${{ secrets.PACKAGE_TOKEN || secrets.RELEASE_TOKEN || secrets.PUBLISH_TOKEN || secrets.API_TOKEN || secrets.PAT_TOKEN || secrets.CUSTOM_TOKEN || secrets.GITEA_TOKEN || secrets.GITHUB_TOKEN || github.token }}
run: |
echo "Veröffentliche Debian-Paket (Distribution: nightly, Component: main)..."
for deb in target/debian/*.deb; do
[ -f "$deb" ] || continue
curl -f -s -S -X PUT \
-H "Authorization: token ${TOKEN}" \
--upload-file "$deb" \
"${GITEA_URL}/api/packages/${REPO_OWNER}/debian/pool/nightly/main/upload"
done
echo "Veröffentliche Fedora/RPM-Paket (Gruppe: nightly)..."
for rpm in target/generate-rpm/*.rpm; do
[ -f "$rpm" ] || continue
curl -f -s -S -X PUT \
-H "Authorization: token ${TOKEN}" \
--upload-file "$rpm" \
"${GITEA_URL}/api/packages/${REPO_OWNER}/rpm/nightly/upload"
done
echo "Veröffentliche Arch Linux-Paket (Repository: nightly)..."
for pkg in target/arch/*.pkg.tar.zst; do
[ -f "$pkg" ] || continue
curl -f -s -S -X PUT \
-H "Authorization: token ${TOKEN}" \
--upload-file "$pkg" \
"${GITEA_URL}/api/packages/${REPO_OWNER}/arch/nightly"
done
+1 -1
View File
@@ -8,7 +8,7 @@ on:
- dev
pull_request:
schedule:
- cron: "0 5 * * 1"
- cron: "CRON_TZ=Europe/Berlin 0 5 * * 1"
workflow_dispatch:
jobs:
+9 -9
View File
@@ -47,16 +47,16 @@ jobs:
toolchain: stable
cache: false
# Ein rohes 'actions/cache' auf target/ liefert zwar einen technischen Cache-Hit
# (Dateien werden restauriert), Cargo kompiliert die Abhängigkeiten aber trotzdem neu:
# Der tar-basierte Restore-Vorgang setzt bei allen wiederhergestellten Dateien
# (Quelldateien wie kompilierte .rlib/.d-Dateien) dieselbe Mtime, wodurch Cargos
# Fingerprinting nicht mehr zuverlässig erkennen kann, was tatsächlich älter/neuer als
# was ist, und sicherheitshalber alles neu baut. Swatinem/rust-cache ist genau dafür
# gebaut (u. a. gezielte Mtime-Korrektur nach dem Restore) und cached dabei automatisch
# auch beide Cross-Compilation-Targets (x86_64 + aarch64) in diesem Job.
- name: Cache Cargo-Abhängigkeiten & Build-Artefakte
uses: actions/cache@v6
with:
path: |
~/.cargo/registry
~/.cargo/git
target
key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
restore-keys: |
cargo-${{ runner.os }}-
uses: Swatinem/rust-cache@v2
- name: Alte Paketierungs-Ausgaben aus dem Cache entfernen
run: rm -rf target/debian target/generate-rpm target/arch target/completions
+1 -1
View File
@@ -4,7 +4,7 @@ on:
push:
pull_request:
schedule:
- cron: "0 6 * * 1"
- cron: "CRON_TZ=Europe/Berlin 0 6 * * 1"
workflow_dispatch:
jobs:
+5 -9
View File
@@ -8,6 +8,7 @@ on:
- reopened
branches:
- testing
- dev
jobs:
test:
@@ -23,16 +24,11 @@ jobs:
toolchain: stable
cache: false
# Siehe main.yaml/testing.yaml: Swatinem/rust-cache statt eines rohen 'actions/cache' auf
# target/, das trotz Cache-Hit wegen verschobener Mtimes nach dem Restore oft trotzdem
# alles neu kompiliert.
- name: Cache Cargo-Abhängigkeiten & Build-Artefakte
uses: actions/cache@v6
with:
path: |
~/.cargo/registry
~/.cargo/git
target
key: cargo-${{ runner.os }}-${{ hashFiles('Cargo.lock') }}
restore-keys: |
cargo-${{ runner.os }}-
uses: Swatinem/rust-cache@v2
- name: Run Tests
run: cargo test
+4 -1
View File
@@ -118,7 +118,10 @@ Alle Workflows liegen unter `.gitea/workflows/` und nutzen gecachte Abhängigkei
### 5.1 Build & Release
- **`main.yaml`** (Trigger: `push` auf `main`): Baut Binaries für alle 3 Architekturen, führt `cargo test` aus, baut `.deb`, `.rpm` und `.pkg.tar.zst`, lädt sie in die Gitea Package Registry hoch, erstellt ein Gitea Release `v<VERSION>` und baut/veröffentlicht zusätzlich ein Docker-Image (`:latest`, `:<VERSION>`, `:v<VERSION>`, `:<VERSION>.<BUILD_NUMBER>`).
- **`testing.yaml`** (Trigger: `push` auf `testing`): Analog zu `main.yaml`, veröffentlicht jedoch in die `testing`-Kanäle der Paket-Registry, erstellt ein Pre-Release `v<VERSION>-preview` und taggt Docker-Images mit `:testing`, `:<VERSION>-preview`, `:<VERSION>-testing` etc.
- **`unit-tests.yaml`** (Trigger: `pull_request``testing`, bei `opened`/`synchronize`/`reopened`): Schnelle CI-Prüfung (`cargo test`) für Pull Requests, ohne Paketierung oder Veröffentlichung.
- **`nightly.yaml`** (Trigger: `push` auf `nightly`): Analog zu `testing.yaml`/`main.yaml` (Build, Tests, Paketierung für alle 3 Architekturen), veröffentlicht die Pakete jedoch ausschließlich in den `nightly`-Kanal der Paket-Registry (Distribution/Gruppe/Repository jeweils `nightly`) und erstellt **kein** Gitea Release.
- **`nightly-pr.yaml`** (Trigger: `schedule` täglich `CRON_TZ=Europe/Berlin 0 9 * * *`, zusätzlich `workflow_dispatch`): Erstellt automatisch einen Pull Request von `dev` nach `nightly` (legt den `nightly`-Branch bei Bedarf initial von `dev` an) und merged diesen sofort ohne manuelle Freigabe, sofern es Unterschiede zwischen beiden Branches gibt. Der Merge löst anschließend `nightly.yaml` aus.
> **Hinweis:** Gitea Actions interpretiert `schedule`-Cron standardmäßig in der lokalen Zeitzone des Gitea-Servers (anders als GitHub Actions, das immer UTC nutzt). Das `CRON_TZ=`-Präfix ist eine Gitea-Erweiterung, die die Zeitzone unabhängig von der Server-Konfiguration DST-sicher festlegt — bei neuen zeitgesteuerten Workflows bevorzugt verwenden statt einer fest verdrahteten UTC-Zeit (betrifft z. B. `security-scan.yaml`s `0 5 * * 1`, das ohne `CRON_TZ=` von der Server-Zeitzone abhängt).
- **`unit-tests.yaml`** (Trigger: `pull_request``testing`/`dev`, bei `opened`/`synchronize`/`reopened`): Schnelle CI-Prüfung (`cargo test`) für Pull Requests, ohne Paketierung oder Veröffentlichung.
### 5.2 Sicherheit & Qualität
- **`security-scan.yaml`** (Trigger: `push` auf `main`/`testing`/`dev`, `pull_request`, wöchentlich montags 05:00 UTC, `workflow_dispatch`): Führt Trivy (`vuln`, `secret`, `misconfig`; Schweregrad `CRITICAL`/`HIGH`) und OSV-Scanner aus und meldet Funde über `scripts/report-security-issue.py` als Gitea-Issue (Label `security-scan`).
Generated
+1 -1
View File
@@ -2052,7 +2052,7 @@ checksum = "ba467056f1b547ed52077911161fc86985becbc60e8e1857c8a144dab0def891"
[[package]]
name = "smart-mount"
version = "2.0.2"
version = "2.0.4"
dependencies = [
"aes-gcm 0.11.1",
"anyhow",
+8 -2
View File
@@ -1,6 +1,6 @@
[package]
name = "smart-mount"
version = "2.0.2"
version = "2.0.4"
edition = "2024"
authors = ['DragonSlayer_14']
readme = "README.md"
@@ -110,7 +110,13 @@ suggests = { "davfs2" = "*", "cifs-utils" = "*", "nfs-utils" = "*" }
post_install_script = """
if command -v systemctl >/dev/null 2>&1; then
systemctl daemon-reload || true
systemctl enable --now smart-mount-mount.service smart-mount-watch.timer || true
# smart-mount-mount.service mountet echte Netzlaufwerke (kann bei nicht erreichbaren
# Servern pro Paar mehrere zehn Sekunden dauern) - "enable --now" wuerde synchron darauf
# warten und damit die Paketinstallation blockieren, daher aktivieren + nur als
# asynchroner Job starten ("--no-block", kehrt sofort zurueck).
systemctl enable smart-mount-mount.service || true
systemctl start --no-block smart-mount-mount.service || true
systemctl enable --now smart-mount-watch.timer || true
fi
/usr/lib/smart-mount/setup-cron || true
"""
+18 -3
View File
@@ -145,13 +145,19 @@ System-systemd-Dienst ein - kein manueller Schritt nötig. Die dafür paketierte
`smart-mount watch` aufruft (Standardintervall: 120s).
Die postinst/postrm-Skripte des Pakets (bzw. das `.INSTALL`-Skriptlet bei Arch) aktivieren und
starten beide Units beim Installieren/Upgraden (`systemctl enable --now ...`) und deaktivieren
sie wieder beim Deinstallieren (`systemctl disable --now ...`) - siehe `packaging/deb/postinst`
+ `packaging/deb/postrm` bzw. `[package.metadata.generate-rpm]`/`scripts/package-arch.py` in
deaktivieren beide Units beim Installieren/Deinstallieren - siehe `packaging/deb/postinst` +
`packaging/deb/postrm` bzw. `[package.metadata.generate-rpm]`/`scripts/package-arch.py` in
`Cargo.toml`. Welche Laufwerkspaare dabei gemountet werden (und für welchen Nutzer, siehe
`owner_user` unten) steuert ausschließlich `/etc/smart-mount/config.toml` - nicht die
Unit-Dateien selbst.
`smart-mount-mount.service` mountet dabei echte Netzlaufwerke, was bei einem gerade nicht
erreichbaren Server pro Paar mehrere zehn Sekunden dauern kann (begrenzt auf max. 10 Minuten
insgesamt, siehe `TimeoutStartSec` in der Unit) - das Paket-Setup wird dadurch **nicht**
blockiert: `systemctl start --no-block` stößt den ersten Mount-Versuch beim Installieren nur an,
statt synchron auf ihn zu warten. `smart-mount-watch.timer` wird dagegen sofort synchron
gestartet (das Timer-"Armen" selbst ist immer augenblicklich fertig).
**Anderes Watch-Intervall als der Standard (120s):** `settings.watch_interval_secs` in
`config.toml` steuert nur den Cron-Fallback (s. u.) - der paketierte Timer hat ein fest
eingebautes Intervall. Zum Anpassen:
@@ -162,6 +168,15 @@ sudo systemctl edit smart-mount-watch.timer
# OnUnitActiveSec=60s
```
**Logs:** beide Units schreiben mit festem `SyslogIdentifier=smart-mount` ins systemd-Journal -
`journalctl -u smart-mount-mount` / `-u smart-mount-watch` (oder gebündelt `journalctl -t
smart-mount`) zeigt sie an. Zusätzlich schreibt smart-mount dieselben Meldungen dauerhaft nach
`/var/log/smart-mount/log-<Datum>.log` (siehe `settings.log_level` für die Ausführlichkeit,
Standard `info`) - unabhängig von der Journal-Rotation. `smart-mount-mount.service` bleibt nach
einem erfolgreichen Lauf als "active (exited)" sichtbar (`RemainAfterExit=yes`), und ein
Fehlschlag beim Mounten mindestens eines konfigurierten Laufwerkspaars lässt den Dienst jetzt
auch tatsächlich als "failed" erscheinen, statt es stillschweigend zu ignorieren.
### Cron-Fallback (Systeme ohne systemd)
Ist beim Installieren/Upgraden des Pakets kein `systemctl` gefunden, aber `/etc/cron.d`
+9 -1
View File
@@ -9,7 +9,15 @@ set -e
if [ "$1" = "configure" ]; then
if command -v systemctl >/dev/null 2>&1; then
systemctl daemon-reload || true
systemctl enable --now smart-mount-mount.service smart-mount-watch.timer || true
# smart-mount-mount.service mountet echte Netzlaufwerke (kann pro konfiguriertem Paar
# mehrere zehn Sekunden dauern, wenn ein Server gerade nicht erreichbar ist) - "enable
# --now" wuerde synchron darauf warten und damit "apt"/"dpkg" fuer die gesamte Dauer
# blockieren. Daher: aktivieren (fuer den naechsten Boot) und der eigentliche Mount-Lauf
# nur als asynchroner Job ("--no-block", kehrt sofort zurueck) - das Paket-Setup selbst
# wartet also nie auf Netzwerk-Timeouts.
systemctl enable smart-mount-mount.service || true
systemctl start --no-block smart-mount-mount.service || true
systemctl enable --now smart-mount-watch.timer || true
fi
/usr/lib/smart-mount/setup-cron || true
fi
@@ -5,7 +5,26 @@ Wants=network-online.target
[Service]
Type=oneshot
# Bleibt nach einem erfolgreichen Lauf als "active (exited)" sichtbar (statt sofort wieder
# "inactive") - macht in 'systemctl status' auf einen Blick erkennbar, dass der letzte Boot-Lauf
# tatsächlich durchlief, statt nur "inactive" zu zeigen (das genauso gut "nie gelaufen" heißen
# könnte).
RemainAfterExit=yes
ExecStart=/usr/bin/smart-mount mount --all
# Harte Obergrenze statt des systemd-Standards (üblicherweise 90s): pro konfiguriertem Paar
# werden Erreichbarkeit UND Mount-Versuch sequenziell geprüft (bis zu ~20s Erreichbarkeits-
# check + 30s Mount-Timeout, siehe crate::mount::MOUNT_TIMEOUT_SECS), bei mehreren Paaren
# summiert sich das - 90s würde bei zwei oder mehr gerade nicht erreichbaren Servern schon
# reichen, um mitten im Mount-Versuch abgebrochen zu werden. 10 Minuten sind großzügig genug für
# eine typische Anzahl Paare, ohne bei einem echten Hänger (z. B. einer verwaisten Dateisperre)
# unbegrenzt zu warten.
TimeoutStartSec=600
# Explizit (statt sich auf den systemd-Standard zu verlassen): stdout/stderr gehen ins Journal,
# unter einem festen, von der jeweiligen Unit unabhängigen Tag - 'journalctl -t smart-mount'
# zeigt damit die Ausgaben aller smart-mount-Units gebündelt.
StandardOutput=journal
StandardError=journal
SyslogIdentifier=smart-mount
[Install]
WantedBy=multi-user.target
@@ -4,3 +4,6 @@ Description=smart-mount: check reachability and switch local/cloud if needed
[Service]
Type=oneshot
ExecStart=/usr/bin/smart-mount watch
StandardOutput=journal
StandardError=journal
SyslogIdentifier=smart-mount
+35 -5
View File
@@ -1,29 +1,59 @@
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended"],
"extends": [
"config:recommended"
],
"timezone": "Europe/Berlin",
"schedule": ["before 6am on monday"],
"schedule": [
"before 6am"
],
"baseBranchPatterns": [
"dev"
],
"packageRules": [
{
"matchFileNames": [".gitea/workflows/**"],
"matchFileNames": [
".gitea/workflows/**"
],
"groupName": "Gitea Actions",
"separateMajorMinor": false,
"separateMinorPatch": false
},
{
"matchManagers": ["cargo"],
"matchManagers": [
"cargo"
],
"groupName": "Cargo Dependencies",
"separateMajorMinor": false,
"separateMinorPatch": false
},
{
"matchManagers": ["dockerfile", "docker-compose"],
"matchManagers": [
"dockerfile",
"docker-compose"
],
"groupName": "Docker-Images",
"separateMajorMinor": false,
"separateMinorPatch": false
},
{
"description": "Patch-/Minor-/Digest-Updates automatisch mergen, sobald alle CI-Checks (inkl. Unit-Tests) erfolgreich sind - Major-Updates sind unten explizit ausgenommen (siehe nächste Regel).",
"matchUpdateTypes": [
"patch",
"minor",
"digest",
"lockFileMaintenance"
],
"automerge": true,
"automergeType": "pr",
"platformAutomerge": true
},
{
"description": "Major-Updates immer manuell prüfen, da potenziell brechende Änderungen.",
"matchUpdateTypes": [
"major"
],
"automerge": false
}
],
"customManagers": [
+18 -8
View File
@@ -105,16 +105,26 @@ def build_install_scriptlet(name, installable, all_units, has_cron_helper):
Cron-Fallback-Hilfsprogramm ('usr/lib/<name>/setup-cron', siehe src/bin/setup-cron.rs) beim
Installieren/Upgraden auf bzw. entfernt dessen Cron-Datei beim Entfernen wieder. Rein anhand
der tatsächlich gefundenen Unit-Dateien/Hilfsprogramme zusammengesetzt, ohne den
Anwendungsnamen selbst hart zu codieren (der als `name`-Parameter hereinkommt)."""
installable_str = " ".join(installable)
Anwendungsnamen selbst hart zu codieren (der als `name`-Parameter hereinkommt).
'.service'-Units werden bewusst NICHT über 'enable --now' gestartet: Bei einem oneshot-
Service (typischer Fall für ein Boot-Setup-Skript) würde das den ExecStart-Befehl synchron
ausführen und damit 'pacman' für die gesamte Laufzeit des Skripts blockieren (siehe
packaging/deb/postinst für den konkreten Fall, der das erst sichtbar gemacht hat: ein
Mount-Versuch gegen ein gerade nicht erreichbares Netzlaufwerk). '.timer'-Units sind davon
nicht betroffen - sie nur zu "armen" ist immer sofort fertig - und starten daher weiterhin
synchron mit 'enable --now'."""
timers = [u for u in installable if u.endswith(".timer")]
services = [u for u in installable if not u.endswith(".timer")]
all_units_str = " ".join(all_units)
systemd_enable = (
" systemctl daemon-reload >/dev/null 2>&1 || true\n"
f" systemctl enable --now {installable_str} >/dev/null 2>&1 || true\n"
if installable
else ""
)
systemd_enable = " systemctl daemon-reload >/dev/null 2>&1 || true\n" if installable else ""
if timers:
systemd_enable += f" systemctl enable --now {' '.join(timers)} >/dev/null 2>&1 || true\n"
for service in services:
systemd_enable += f" systemctl enable {service} >/dev/null 2>&1 || true\n"
systemd_enable += f" systemctl start --no-block {service} >/dev/null 2>&1 || true\n"
systemd_reload = " systemctl daemon-reload >/dev/null 2>&1 || true\n" if all_units else ""
systemd_disable = (
f" systemctl disable --now {all_units_str} >/dev/null 2>&1 || true\n" if all_units else ""
+22 -3
View File
@@ -2,7 +2,7 @@
use crate::config::{self, DrivePair};
use crate::db::credentials::CredentialStore;
use crate::reconcile;
use crate::reconcile::{self, Action};
fn select_pairs(
cfg: &crate::config::AppConfig,
@@ -32,9 +32,21 @@ pub async fn run_mount(name: Option<String>, all: bool) -> anyhow::Result<()> {
);
let creds = CredentialStore::open().await?;
let mut had_failure = false;
for pair in &pairs {
let outcome = reconcile::reconcile_pair(pair, &cfg.settings, &creds).await;
print_outcome(&outcome);
if matches!(outcome.action, Action::Failed(_)) {
had_failure = true;
}
}
// Ohne dies wäre `smart-mount-mount.service` (siehe packaging/systemd/) beim Booten selbst
// dann "erfolgreich" (Exit-Code 0), wenn tatsächlich kein einziges Laufwerkspaar gemountet
// werden konnte - `systemctl status` würde den Fehlschlag also nie sichtbar machen. Analog
// zu `watch::run` unten.
if had_failure {
anyhow::bail!("at least one drive pair could not be mounted");
}
Ok(())
}
@@ -52,17 +64,24 @@ pub async fn run_unmount(name: Option<String>, all: bool) -> anyhow::Result<()>
&format!("unmount: processing {} drive pair(s)", pairs.len()),
);
let mut had_failure = false;
for pair in &pairs {
match reconcile::unmount_pair(pair, &cfg.settings).await {
Ok(_) => println!("{} ({}): unmounted", pair.name, pair.id),
Err(e) => println!("{} ({}): ERROR: {e}", pair.name, pair.id),
Err(e) => {
println!("{} ({}): ERROR: {e}", pair.name, pair.id);
had_failure = true;
}
}
}
if had_failure {
anyhow::bail!("at least one drive pair could not be unmounted");
}
Ok(())
}
pub(crate) fn print_outcome(outcome: &reconcile::ReconcileOutcome) {
use reconcile::Action;
let action_str = match &outcome.action {
Action::NoOp => "no change".to_string(),
Action::MountedLocal => "mounted local".to_string(),
+6
View File
@@ -7,6 +7,12 @@ use smart_mount::cli;
async fn main() -> ExitCode {
smart_mount::config::init();
// Persistentes, gut auffindbares Log-Verzeichnis statt logger-ctdras Standard-Fallback
// (ein Ordner im System-Temp-Verzeichnis, siehe logger-ctdra-Doku) - smart-mount läuft
// ausschließlich als root/System-Dienst (siehe crate::systemd), daher immer derselbe,
// feste Pfad. Muss vor dem ersten Log-Aufruf stehen (siehe logger_ctdra::set_log_dir).
logger_ctdra::set_log_dir("/var/log/smart-mount");
let log_level = match smart_mount::config::pairs::load() {
Ok(cfg) => cfg.settings.log_level,
Err(_) => "info".to_string(),