integration.yml

name: Integration Tests
on:
  pull_request:
  merge_group:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  run-integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        # pgvector's own image, which is postgres:16 plus the extension. The
        # backend serves vector indexes where the extension is present, so this is
        # what makes the positive paths reachable in CI. The novector job below
        # keeps the refusal paths covered on a plain image.
        image: pgvector/pgvector:pg16
        env:
          POSTGRES_PASSWORD: devpass
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    steps:
      - uses: actions/checkout@v6

      - uses: dtolnay/rust-toolchain@stable

      - uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true

      - name: Build release
        run: cargo build --release

      - name: Initialize ExtendDB
        id: init
        run: |
          output=$(./target/release/extenddb init --config extenddb.toml \
            --pg-host 127.0.0.1 --pg-port 5432 --pg-user postgres --pg-pass devpass 2>&1)
          echo "$output"
          password=$(echo "$output" | grep -oP 'Password: \K\S+')
          echo "admin_password=$password" >> "$GITHUB_OUTPUT"

      - name: Start ExtendDB
        run: |
          # --write-pid-file so devtools/run-tests can restart the server with
          # 'extenddb stop' when it needs to apply a config change.
          ./target/release/extenddb serve --config extenddb.toml --foreground --write-pid-file &
          for i in $(seq 1 30); do
            if curl -sk https://127.0.0.1:18443/health | grep -q healthy; then
              echo "Server ready"
              exit 0
            fi
            sleep 1
          done
          echo "Server failed to start"
          exit 1

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install Python dependencies
        run: pip install -r requirements.txt

      - name: Run integration tests
        env:
          EXTENDDB_TEST_ENDPOINT: https://127.0.0.1:18443
          EXTENDDB_ADMIN_USER: admin
          EXTENDDB_ADMIN_PASSWORD: ${{ steps.init.outputs.admin_password }}
          EXTENDDB_TEST_PG_ADMIN_CONNECTION_STRING: postgresql://postgres:devpass@127.0.0.1:5432
        run: devtools/run-tests --extenddb --pytest --comprehensive --parallel --filter "not import_export"

      # run-tests restarts the server daemonized to apply the import/export
      # config, and a daemonized server logs to syslog, not the job log. Without
      # this dump, the storage error behind a client-visible 500 leaves no
      # evidence anywhere in CI.
      - name: Dump server syslog on failure
        if: failure()
        run: sudo journalctl -t extenddb --no-pager -n 500 || true

  run-integration-sqlite:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: dtolnay/rust-toolchain@stable

      - uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true

      - name: Build release (SQLite backend)
        run: cargo build --release -p extenddb --no-default-features --features sqlite

      - name: Initialize ExtendDB
        id: init
        run: |
          output=$(./target/release/extenddb init --backend sqlite --config extenddb.toml 2>&1)
          echo "$output"
          password=$(echo "$output" | grep -oP 'Password: \K\S+')
          echo "admin_password=$password" >> "$GITHUB_OUTPUT"

      - name: Start ExtendDB
        run: |
          # --write-pid-file so devtools/run-tests can restart the server with
          # 'extenddb stop' when it needs to apply a config change.
          ./target/release/extenddb serve --config extenddb.toml --foreground --write-pid-file &
          for i in $(seq 1 30); do
            if curl -sk https://127.0.0.1:18443/health | grep -q healthy; then
              echo "Server ready"
              exit 0
            fi
            sleep 1
          done
          echo "Server failed to start"
          exit 1

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install Python dependencies
        run: pip install -r requirements.txt

      - name: Run integration tests
        env:
          EXTENDDB_TEST_ENDPOINT: https://127.0.0.1:18443
          EXTENDDB_ADMIN_USER: admin
          EXTENDDB_ADMIN_PASSWORD: ${{ steps.init.outputs.admin_password }}
        run: devtools/run-tests --extenddb --pytest --comprehensive --parallel --filter "not import_export"

      # Same rationale as the postgres job: the daemonized server logs to
      # syslog, so this dump is the only server-side evidence on failure.
      - name: Dump server syslog on failure
        if: failure()
        run: sudo journalctl -t extenddb --no-pager -n 500 || true

  run-integration-dev-mode:
    # dev-mode was shipped with no CI coverage at all, which is how the batch and
    # transaction authorization regression reached main: the build compiled, so
    # a feature-matrix check passed, while nothing ever issued a request against
    # a dev-mode server. This job starts one and exercises the data plane.
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: dtolnay/rust-toolchain@stable

      - uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true

      - name: Build release (dev mode, in-memory SQLite)
        run: cargo build --release -p extenddb --no-default-features --features sqlite-memory,dev-mode

      - name: Start ExtendDB in dev mode
        run: |
          # No config file on purpose: dev mode falls back to built-in defaults,
          # which is the zero-config path a user gets, and the one the profile
          # documents as a DynamoDB Local replacement.
          ./target/release/extenddb serve --foreground --port 18444 --config /nonexistent.toml &
          for i in $(seq 1 30); do
            if curl -s http://127.0.0.1:18444/health | grep -q healthy; then
              echo "Server ready"
              exit 0
            fi
            sleep 1
          done
          echo "Server failed to start"
          exit 1

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install Python dependencies
        run: pip install -r requirements.txt

      - name: Run dev-mode authorization tests
        env:
          EXTENDDB_TEST_ENDPOINT: http://127.0.0.1:18444
          EXTENDDB_TEST_DEV_MODE: "1"
          AWS_DEFAULT_REGION: us-east-1
          # The seeded zero-config dev credential. AWS's documented example key,
          # which grants nothing anywhere; it exists so SigV4 has a key to verify.
          AWS_ACCESS_KEY_ID: AKIAIOSFODNN7EXAMPLE
          AWS_SECRET_ACCESS_KEY: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
        run: python3 -m pytest tests/test_dev_mode_authorization.py -v

  run-rust-integration:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: pgvector/pgvector:pg16
        env:
          POSTGRES_PASSWORD: devpass
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    steps:
      - uses: actions/checkout@v6

      - uses: dtolnay/rust-toolchain@stable

      - uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true

      - name: Build release
        run: cargo build --release

      - name: Initialize ExtendDB
        id: init
        run: |
          output=$(./target/release/extenddb init --config extenddb.toml \
            --pg-host 127.0.0.1 --pg-port 5432 --pg-user postgres --pg-pass devpass 2>&1)
          echo "$output"
          echo "admin_password=$(echo "$output" | grep -oP 'Password: \K\S+')" >> "$GITHUB_OUTPUT"
          echo "account_id=$(echo "$output" | grep -oP 'Account ID: \K\S+')" >> "$GITHUB_OUTPUT"

      - name: Enable provisioned-capacity throttling enforcement
        run: ./target/release/extenddb settings set throttling_enabled true

      - name: Start ExtendDB
        run: |
          # --write-pid-file so devtools/run-tests can restart the server with
          # 'extenddb stop' when it needs to apply a config change.
          ./target/release/extenddb serve --config extenddb.toml --foreground --write-pid-file &
          for i in $(seq 1 30); do
            if curl -sk https://127.0.0.1:18443/health | grep -q healthy; then
              echo "Server ready"
              exit 0
            fi
            sleep 1
          done
          echo "Server failed to start"
          exit 1

      # Driven through devtools/run-tests rather than a bare `cargo test`, because the
      # harness provisions what several suites require and a raw invocation does not:
      # devtools/provision-test-credentials creates account 123456789012 with an IAM
      # user, access key and full-access policy, and exports the credentials.
      #
      # batch_transact_authz targets that account and skips itself when
      # EXTENDDB_ADMIN_PASSWORD is absent, so under a bare `cargo test` all ten of its
      # tests reported ok WITHOUT EXECUTING, in every run since they landed in #232.
      # The vector backfill tests need the same access to set the batch delay.
      - name: Run Rust integration tests
        env:
          EXTENDDB_TEST_ENDPOINT: https://127.0.0.1:18443
          AWS_DEFAULT_REGION: us-east-1
          EXTENDDB_ADMIN_USER: admin
          EXTENDDB_ADMIN_PASSWORD: ${{ steps.init.outputs.admin_password }}
          # PostgreSQL now serves vector search against a server with pgvector,
          # which this job's image has. Both vector suites adapt to whatever the
          # backend reports, so without a pinned expectation the positive suite
          # could skip every assertion and still report green. "1" makes those
          # tests mandatory. The refusal suite moves to the novector job, which is
          # the only place those assertions still mean anything.
          EXTENDDB_EXPECT_VECTORS: "1"
        run: devtools/run-tests --extenddb --rust-integration --release

      # The control plane for vector indexes is not reachable over the wire while
      # this backend declares no vector search capability, so its tests drive the
      # storage layer directly against this job's PostgreSQL. They build their own
      # throwaway databases; the connection string is the server, not a database.
      - name: Run PostgreSQL storage-level tests
        env:
          EXTENDDB_TEST_PG_CONNECTION_STRING: postgresql://postgres:devpass@127.0.0.1:5432
        run: cargo test --release -p extenddb-storage-postgres --test vector_control_plane

      # The daemonized server logs to syslog; dump it so server-side failures
      # are diagnosable from the job log.
      - name: Dump server syslog on failure
        if: failure()
        run: sudo journalctl -t extenddb --no-pager -n 500 || true

  # The runtime-detection proof: the same binary, against a PostgreSQL with no
  # pgvector, must refuse vector indexes over the wire. Today the job above runs
  # on a plain image too, so this looks like a duplicate of it; it is not, because
  # that job moves to the pgvector image when the search path lands and its
  # EXTENDDB_EXPECT_VECTORS flips to "1". Without this job the refusal surface
  # would stop being tested at exactly that point.
  run-rust-integration-postgres-novector:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: devpass
        options: >-
          --health-cmd "pg_isready -U postgres"
          --health-interval 5s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

    steps:
      - uses: actions/checkout@v6

      - uses: dtolnay/rust-toolchain@stable

      - uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true

      - name: Build release
        run: cargo build --release

      - name: Initialize ExtendDB
        id: init
        run: |
          output=$(./target/release/extenddb init --config extenddb.toml \
            --pg-host 127.0.0.1 --pg-port 5432 --pg-user postgres --pg-pass devpass 2>&1)
          echo "$output"
          echo "admin_password=$(echo "$output" | grep -oP 'Password: \K\S+')" >> "$GITHUB_OUTPUT"

      - name: Start ExtendDB
        run: |
          ./target/release/extenddb serve --config extenddb.toml --foreground --write-pid-file &
          for i in $(seq 1 30); do
            if curl -sk https://127.0.0.1:18443/health | grep -q healthy; then
              echo "Server ready"
              exit 0
            fi
            sleep 1
          done
          echo "Server failed to start"
          exit 1

      - name: Run the vector refusal suite
        env:
          EXTENDDB_TEST_ENDPOINT: https://127.0.0.1:18443
          AWS_DEFAULT_REGION: us-east-1
          EXTENDDB_ADMIN_USER: admin
          EXTENDDB_ADMIN_PASSWORD: ${{ steps.init.outputs.admin_password }}
          # "0" makes the refusal assertions mandatory: the suite adapts to what
          # the backend reports, so without this it could skip every assertion
          # and still report green.
          EXTENDDB_EXPECT_VECTORS: "0"
        run: >-
          devtools/run-tests --extenddb --rust-integration --release
          --filter vector_index_unsupported

      # The daemonized server logs to syslog; dump it so server-side failures
      # are diagnosable from the job log.
      - name: Dump server syslog on failure
        if: failure()
        run: sudo journalctl -t extenddb --no-pager -n 500 || true

      # No storage-level step here on purpose. Those tests build their own
      # extension-free scratch databases, so they behave identically on either
      # image and the job above already runs them; repeating them here would buy
      # a second release build and no coverage.
  run-rust-integration-sqlite:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v6

      - uses: dtolnay/rust-toolchain@stable

      - uses: Swatinem/rust-cache@v2
        with:
          cache-on-failure: true

      - name: Build release (SQLite backend)
        run: cargo build --release -p extenddb --no-default-features --features sqlite

      - name: Initialize ExtendDB
        id: init
        run: |
          output=$(./target/release/extenddb init --backend sqlite --config extenddb.toml 2>&1)
          echo "$output"
          echo "admin_password=$(echo "$output" | grep -oP 'Password: \K\S+')" >> "$GITHUB_OUTPUT"

      - name: Enable provisioned-capacity throttling enforcement
        run: ./target/release/extenddb settings set throttling_enabled true

      - name: Start ExtendDB
        run: |
          ./target/release/extenddb serve --config extenddb.toml --foreground --write-pid-file &
          for i in $(seq 1 30); do
            if curl -sk https://127.0.0.1:18443/health | grep -q healthy; then
              echo "Server ready"
              exit 0
            fi
            sleep 1
          done
          echo "Server failed to start"
          exit 1

      # Driven through devtools/run-tests rather than a bare `cargo test`, because the
      # harness provisions what several suites require and a raw invocation does not:
      # devtools/provision-test-credentials creates account 123456789012 with an IAM
      # user, access key and full-access policy, and exports the credentials.
      #
      # batch_transact_authz targets that account and skips itself when
      # EXTENDDB_ADMIN_PASSWORD is absent, so under a bare `cargo test` all ten of its
      # tests reported ok WITHOUT EXECUTING, in every run since they landed in #232.
      # The vector backfill tests need the same access to set the batch delay.
      - name: Run Rust integration tests
        env:
          EXTENDDB_TEST_ENDPOINT: https://127.0.0.1:18443
          AWS_DEFAULT_REGION: us-east-1
          EXTENDDB_ADMIN_USER: admin
          EXTENDDB_ADMIN_PASSWORD: ${{ steps.init.outputs.admin_password }}
          # Both vector suites self-skip when the backend is the wrong kind, so without
          # this the positive suite could skip every assertion and still report green,
          # which is what would happen if the backend lost the capability. Pinning the
          # expectation turns that skip into a failure.
          EXTENDDB_EXPECT_VECTORS: "1"
        run: devtools/run-tests --extenddb --rust-integration --release

      # The daemonized server logs to syslog; dump it so server-side failures
      # are diagnosable from the job log.
      - name: Dump server syslog on failure
        if: failure()
        run: sudo journalctl -t extenddb --no-pager -n 500 || true

  integration:
    runs-on: ubuntu-latest
    needs:
      [
        run-integration,
        run-integration-sqlite,
        run-integration-dev-mode,
        run-rust-integration,
        run-rust-integration-postgres-novector,
        run-rust-integration-sqlite,
      ]
    if: always()
    steps:
      - run: |
          if [ "${{ needs.run-integration.result }}" != "success" ] || \
             [ "${{ needs.run-integration-sqlite.result }}" != "success" ] || \
             [ "${{ needs.run-integration-dev-mode.result }}" != "success" ] || \
             [ "${{ needs.run-rust-integration.result }}" != "success" ] || \
             [ "${{ needs.run-rust-integration-postgres-novector.result }}" != "success" ] || \
             [ "${{ needs.run-rust-integration-sqlite.result }}" != "success" ]; then
            exit 1
          fi