Adds Monitoring Setup docs and deploy-scp troubleshooting/debug fixes #2

Merged
Sluijsens merged 11 commits from feature/gitea-deployment-workflow into master 2026-07-30 23:57:52 +02:00
2 changed files with 27 additions and 14 deletions
Showing only changes of commit 084b941204 - Show all commits
+12 -14
View File
@@ -109,7 +109,7 @@ jobs:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- uses: actions/setup-node@v4 - uses: actions/setup-node@v3
with: with:
node-version: ${{ env.NODE_VERSION }} node-version: ${{ env.NODE_VERSION }}
- uses: pnpm/action-setup@v4 - uses: pnpm/action-setup@v4
@@ -130,16 +130,16 @@ jobs:
# --- Gate 4: frontend build --- # --- Gate 4: frontend build ---
# Validates the frontend compiles on its own, independent of any environment. The actual # Validates the frontend compiles on its own, independent of any environment. The actual
# per-environment deployable artifact is produced later by `dotnet publish` (publish-test / # per-environment deployable artifact is produced later by each publish job's own "Build admin
# publish-production jobs below), which triggers the same frontend build internally via # frontend" step (publish-test / publish-production, below), which builds frontend/ again with
# SlpModularCms.Api.csproj's BuildAndCopyAdminFrontend MSBuild target, with the environment's # that environment's Vite variables set and copies the result into wwwroot/admin before
# Vite variables set on the process so that target picks them up. # `dotnet publish` runs — see that step's comment for why this isn't an MSBuild target instead.
frontend-build: frontend-build:
needs: frontend-prepare needs: frontend-prepare
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- uses: actions/setup-node@v4 - uses: actions/setup-node@v3
with: with:
node-version: ${{ env.NODE_VERSION }} node-version: ${{ env.NODE_VERSION }}
- uses: pnpm/action-setup@v4 - uses: pnpm/action-setup@v4
@@ -167,7 +167,7 @@ jobs:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- uses: actions/setup-node@v4 - uses: actions/setup-node@v3
with: with:
node-version: ${{ env.NODE_VERSION }} node-version: ${{ env.NODE_VERSION }}
- uses: pnpm/action-setup@v4 - uses: pnpm/action-setup@v4
@@ -195,7 +195,7 @@ jobs:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- uses: actions/setup-node@v4 - uses: actions/setup-node@v3
with: with:
node-version: ${{ env.NODE_VERSION }} node-version: ${{ env.NODE_VERSION }}
- uses: pnpm/action-setup@v4 - uses: pnpm/action-setup@v4
@@ -217,10 +217,8 @@ jobs:
working-directory: frontend working-directory: frontend
run: pnpm run lint run: pnpm run lint
# Publishes the Api project for the test environment. The admin SPA is built as part of this # Publishes the Api project for the test environment. The admin SPA is built by this job's own
# publish (BuildAndCopyAdminFrontend, BeforeTargets="Publish"), so the VITE_* variables below are # "Build admin frontend" step below, ahead of `dotnet publish` — see that step's comment for why.
# set on this step's environment, not passed as CLI arguments — pnpm build (invoked by MSBuild)
# reads them the same way `vite build` always does.
# #
# REF-U5-01: the Umami-origin drift check this gate performs exists because U3's own startup check # REF-U5-01: the Umami-origin drift check this gate performs exists because U3's own startup check
# (BR-U3-22) can't work — the backend can never see VITE_UMAMI_WEBSITE_ID at runtime. It compares # (BR-U3-22) can't work — the backend can never see VITE_UMAMI_WEBSITE_ID at runtime. It compares
@@ -236,7 +234,7 @@ jobs:
- uses: actions/setup-dotnet@v4 - uses: actions/setup-dotnet@v4
with: with:
dotnet-version: ${{ env.DOTNET_VERSION }} dotnet-version: ${{ env.DOTNET_VERSION }}
- uses: actions/setup-node@v4 - uses: actions/setup-node@v3
with: with:
node-version: ${{ env.NODE_VERSION }} node-version: ${{ env.NODE_VERSION }}
- uses: pnpm/action-setup@v4 - uses: pnpm/action-setup@v4
@@ -299,7 +297,7 @@ jobs:
- uses: actions/setup-dotnet@v4 - uses: actions/setup-dotnet@v4
with: with:
dotnet-version: ${{ env.DOTNET_VERSION }} dotnet-version: ${{ env.DOTNET_VERSION }}
- uses: actions/setup-node@v4 - uses: actions/setup-node@v3
with: with:
node-version: ${{ env.NODE_VERSION }} node-version: ${{ env.NODE_VERSION }}
- uses: pnpm/action-setup@v4 - uses: pnpm/action-setup@v4
@@ -556,6 +556,21 @@ fi
source "$CREDENTIALS_FILE" source "$CREDENTIALS_FILE"
: "${DB_HOST:?}" "${DB_PORT:?}" "${DB_NAME:?}" "${DB_USER:?}" "${DB_PASSWORD:?}" : "${DB_HOST:?}" "${DB_PORT:?}" "${DB_NAME:?}" "${DB_USER:?}" "${DB_PASSWORD:?}"
# A brand-new environment's very first production deploy runs this step before the app has ever
# started, so before EF Core's migrations have had a chance to create the database — there is
# nothing to back up yet, and that's fine, not a failure. Distinguish that specific case ("Unknown
# database", MariaDB error 1049) from every other failure (wrong credentials, network issue,
# permissions): only the former is safe to skip, since skipping any OTHER error would silently mask
# a real backup failure against a database that may hold real data.
USE_ERROR=$(mariadb -h "$DB_HOST" -P "$DB_PORT" -u "$DB_USER" -p"$DB_PASSWORD" -e "USE \`$DB_NAME\`;" 2>&1 >/dev/null) || true
if echo "$USE_ERROR" | grep -q "Unknown database"; then
echo "Database '$DB_NAME' does not exist yet — nothing to back up (expected on a first deploy). Skipping."
exit 0
elif [[ -n "$USE_ERROR" ]]; then
echo "Could not verify database '$DB_NAME' exists: $USE_ERROR" >&2
exit 1
fi
BACKUP_DIR="$HOME/backups/slpsoftware/${ENVIRONMENT}" BACKUP_DIR="$HOME/backups/slpsoftware/${ENVIRONMENT}"
mkdir -p "$BACKUP_DIR" mkdir -p "$BACKUP_DIR"
TIMESTAMP=$(date -u +%Y%m%d%H%M%S) TIMESTAMP=$(date -u +%Y%m%d%H%M%S)