`manifest.storage.buckets` has existed since manifest version 1 and meant nothing — discovery validated it and no code read it. This turns it into a real capability, which is what stands between Announcements and the module system: that product currently fetches a hardcoded LAN S3 endpoint, parses ListObjectsV2 XML by hand, and hands the browser direct object URLs. - A module declares a logical bucket and receives a scoped facade at `context.storage` — list, head, get, put, delete. The contract names no provider: no endpoint, region, credential, or physical bucket is reachable from it, which is what lets the same module run under a future standalone host over its own or a shared S3-compatible service. - Core's first provider speaks S3 through the AWS SDK. SeaweedFS is the deployment target (ADR 0004), never an API name. Probing the pinned image found `CreateBucket` reporting `BucketAlreadyExists` rather than AWS's `BucketAlreadyOwnedByYou`; treating only the AWS spelling as success would have failed every second boot. A live test pins it. - Logical → physical mapping is deterministic and collision-safe: an installation prefix, the module and bucket ids joined by `--` (which cannot occur inside either identifier, so `a-b`+`c` and `a`+`b-c` cannot collide), and a digest over the full untruncated identity. Two modules declaring `assets` always get separate namespaces; neither can see the physical name. - Declaring a bucket is now a requirement: with no provider configured the module is `blocked · storage_unavailable` through ADR 0028's existing resolver, propagating to required dependents. An installation with no object storage stays a complete deployment. - Binding availability is not provider health. Eligibility asks whether storage is configured, never whether it answered; bucket creation is lazy on first use so a storage outage cannot stop the platform booting; a running module whose store blinks stays running and retries. Nothing deletes a bucket. - Credentials are deployment-supplied, never persisted, never routed through module configuration, and never visible to modules, module UI, diagnostics, or API responses. Provider errors translate to a closed code set carrying no endpoint, bucket, request id, or XML. - Retires ADR 0029's transitional `bucket` configuration key. No manifest version change. The template declares no bucket, so it still runs without S3. See ADR 0030. Co-Authored-By: Claude Opus 5 <[email protected]>
135 lines
5.1 KiB
Bash
Executable File
135 lines
5.1 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
|
|
set -Eeuo pipefail
|
|
|
|
repository_root="$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")/.." && pwd)"
|
|
cd "$repository_root"
|
|
|
|
# shellcheck source=scripts/lib/compose-job-network.sh
|
|
source "$repository_root/scripts/lib/compose-job-network.sh"
|
|
|
|
command -v docker >/dev/null || {
|
|
echo "Docker is required for the PostgreSQL migration integration suite." >&2
|
|
exit 1
|
|
}
|
|
command -v pnpm >/dev/null || {
|
|
echo "pnpm is required for the PostgreSQL migration integration suite." >&2
|
|
exit 1
|
|
}
|
|
if ! docker compose version >/dev/null 2>&1; then
|
|
echo "Docker Compose is required for the PostgreSQL migration integration suite." >&2
|
|
exit 1
|
|
fi
|
|
if ! compose_job_network_initialize; then
|
|
echo "The current Docker job container could not be identified." >&2
|
|
exit 1
|
|
fi
|
|
|
|
raw_project="ekklesia-migration-${GITHUB_RUN_ID:-local}-${GITHUB_RUN_ATTEMPT:-0}-${GITHUB_JOB:-job}-$$"
|
|
project="${raw_project//[^a-zA-Z0-9_-]/-}"
|
|
project="${project,,}"
|
|
|
|
export POSTGRES_DB="ekklesia_migration_test"
|
|
export POSTGRES_USER="ekklesia_migration_test"
|
|
export POSTGRES_PASSWORD="temporary-$project-${RANDOM}-${RANDOM}"
|
|
export POSTGRES_PORT="0"
|
|
|
|
compose=(
|
|
docker compose
|
|
--project-name "$project"
|
|
--env-file .env.example
|
|
--file infrastructure/compose.yaml
|
|
)
|
|
|
|
cleanup() {
|
|
local exit_status=$?
|
|
trap - EXIT INT TERM
|
|
|
|
if ! compose_job_network_disconnect; then
|
|
echo "PostgreSQL migration test network cleanup failed." >&2
|
|
if ((exit_status == 0)); then
|
|
exit_status=1
|
|
fi
|
|
fi
|
|
if ! "${compose[@]}" down --volumes --remove-orphans --timeout 10 >/dev/null 2>&1; then
|
|
echo "PostgreSQL migration test infrastructure cleanup failed." >&2
|
|
if ((exit_status == 0)); then
|
|
exit_status=1
|
|
fi
|
|
fi
|
|
exit "$exit_status"
|
|
}
|
|
trap cleanup EXIT
|
|
trap 'exit 130' INT
|
|
trap 'exit 143' TERM
|
|
|
|
if ! "${compose[@]}" config --quiet >/dev/null 2>&1; then
|
|
echo "PostgreSQL migration test infrastructure configuration is invalid." >&2
|
|
exit 1
|
|
fi
|
|
# PostgreSQL and the S3-compatible object-storage service are both brought up from the repository's
|
|
# own pinned Compose file, so the live suites exercise exactly the services a developer runs locally
|
|
# and CI already knows how to provision. SeaweedFS is the intended deployment target (ADR 0004), and
|
|
# proving the storage contract against a mock instead would have hidden the provider quirks this
|
|
# suite exists to catch.
|
|
if ! "${compose[@]}" up --detach --wait --wait-timeout 180 postgres object-storage >/dev/null 2>&1; then
|
|
echo "Disposable PostgreSQL and object storage did not become ready." >&2
|
|
exit 1
|
|
fi
|
|
|
|
if [[ "$COMPOSE_JOB_NETWORK_RUNNING_IN_CONTAINER" == "true" ]]; then
|
|
if ! compose_job_network_connect postgres "${compose[@]}"; then
|
|
echo "The migration test job could not join the isolated PostgreSQL network." >&2
|
|
exit 1
|
|
fi
|
|
if ! compose_job_network_connect object-storage "${compose[@]}"; then
|
|
echo "The migration test job could not join the isolated object-storage network." >&2
|
|
exit 1
|
|
fi
|
|
database_host="postgres"
|
|
database_port="5432"
|
|
storage_endpoint="http://object-storage:8333"
|
|
else
|
|
if ! postgres_binding="$("${compose[@]}" port postgres 5432 2>/dev/null)"; then
|
|
echo "The disposable PostgreSQL loopback port could not be determined." >&2
|
|
exit 1
|
|
fi
|
|
if [[ ! "$postgres_binding" =~ ^127\.0\.0\.1:([0-9]+)$ ]]; then
|
|
echo "The disposable PostgreSQL port is not bound safely to loopback." >&2
|
|
exit 1
|
|
fi
|
|
database_host="127.0.0.1"
|
|
database_port="${BASH_REMATCH[1]}"
|
|
if ((database_port < 1 || database_port > 65535)); then
|
|
echo "The disposable PostgreSQL loopback port is invalid." >&2
|
|
exit 1
|
|
fi
|
|
|
|
if ! storage_binding="$("${compose[@]}" port object-storage 8333 2>/dev/null)"; then
|
|
echo "The disposable object-storage loopback port could not be determined." >&2
|
|
exit 1
|
|
fi
|
|
if [[ ! "$storage_binding" =~ ^127\.0\.0\.1:([0-9]+)$ ]]; then
|
|
echo "The disposable object-storage port is not bound safely to loopback." >&2
|
|
exit 1
|
|
fi
|
|
storage_port="${BASH_REMATCH[1]}"
|
|
if ((storage_port < 1 || storage_port > 65535)); then
|
|
echo "The disposable object-storage loopback port is invalid." >&2
|
|
exit 1
|
|
fi
|
|
storage_endpoint="http://127.0.0.1:$storage_port"
|
|
fi
|
|
|
|
# The TLS suite provisions its own disposable PostgreSQL rather than a Compose service, so it
|
|
# cannot call `compose_job_network_connect`. It receives the same topology decision this script
|
|
# already made, instead of detecting the topology a second time.
|
|
# The storage credentials come from `.env.example`, the same file `--env-file` already hands the
|
|
# Compose services, so the suite signs requests with exactly what the service was started with.
|
|
EKKLESIA_TEST_JOB_CONTAINER="$(compose_job_network_job_container)" \
|
|
EKKLESIA_MIGRATION_TEST_DATABASE_URL="postgresql://$POSTGRES_USER:$POSTGRES_PASSWORD@$database_host:$database_port/$POSTGRES_DB" \
|
|
EKKLESIA_TEST_STORAGE_ENDPOINT="$storage_endpoint" \
|
|
EKKLESIA_TEST_STORAGE_ACCESS_KEY="$(grep -E '^S3_ACCESS_KEY=' .env.example | cut -d= -f2-)" \
|
|
EKKLESIA_TEST_STORAGE_SECRET_KEY="$(grep -E '^S3_SECRET_KEY=' .env.example | cut -d= -f2-)" \
|
|
pnpm exec vitest run --config vitest.migrations.integration.config.ts
|