Pins actions/setup-node to v3, skips DB backup when no database exists yet
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / backend-build (pull_request) Successful in 4m57s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m47s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m51s
Continuous Integration / backend-test (pull_request) Successful in 5m17s
Continuous Integration / frontend-build (pull_request) Successful in 2m15s
Continuous Integration / frontend-test (pull_request) Successful in 4m24s
Continuous Integration / frontend-lint (pull_request) Successful in 2m10s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m19s
Continuous Integration / deploy-test (pull_request) Skipped
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / backend-build (pull_request) Successful in 4m57s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m47s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m51s
Continuous Integration / backend-test (pull_request) Successful in 5m17s
Continuous Integration / frontend-build (pull_request) Successful in 2m15s
Continuous Integration / frontend-test (pull_request) Successful in 4m24s
Continuous Integration / frontend-lint (pull_request) Successful in 2m10s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m19s
Continuous Integration / deploy-test (pull_request) Skipped
actions/setup-node@v4's Post step attempts a cache-save that fails hard on this self-hosted Gitea Actions runner (no GHES cache API support), marking frontend-prepare as failed and blocking its dependents even though the actual install/build work succeeds. v3's older cache implementation doesn't hit this. Also cleans up two stale comments left over from the /admin MSBuild-target removal. Also updates the documented backup script to skip cleanly (exit 0) when the target database doesn't exist yet (MariaDB error 1049) rather than failing the whole deploy - expected on a brand-new environment's first production run, before migrations have ever had a chance to create it. Still fails hard on any other error, so a real backup failure against an existing database still blocks the deploy as intended.
This commit is contained in:
+15
@@ -556,6 +556,21 @@ fi
|
||||
source "$CREDENTIALS_FILE"
|
||||
: "${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}"
|
||||
mkdir -p "$BACKUP_DIR"
|
||||
TIMESTAMP=$(date -u +%Y%m%d%H%M%S)
|
||||
|
||||
Reference in New Issue
Block a user