Gate risky migrations in CI

The kit reads changed .sql files directly. There is nothing to render, so this config has no service container, no DATABASE_URL, and no setup input.

name: SIXTA SQL review
on:
  pull_request:
    paths: ["**/*.sql"]
permissions:
  contents: read
  pull-requests: write      # PR comment
  security-events: write    # SARIF upload
  id-token: write           # the “SIXTA review” check by the sixta-connect App (optional)
jobs:
  sixta:
    runs-on: ubuntu-latest
    env:
      SIXTA_API_KEY: ${{ secrets.SIXTA_API_KEY }}
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }        # the review diffs against the PR base
      - uses: sixta-systems/sixta-ci@v1
        with:
          engine_version: "16"          # match production (verdicts are version-dependent)
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: sixta.sarif }

Flyway migrations and SQL-format Liquibase changelogs are read directly: no database, no JVM, no setup input. The engine is auto-detected from pom.xml, build.gradle, or application.* (set engine to override). Flyway ${placeholder} values resolve from spring.flyway.placeholders.*, undo files feed the rollback audit, and Java-based Flyway migrations are flagged for human review. Native SQL in Java code (@Query(nativeQuery = true), JdbcTemplate, MyBatis mappers) is reviewed as queries. XML/YAML Liquibase changelogs additionally need the Liquibase CLI on the runner (install it via setup); SQL-format changelogs need nothing.

name: SIXTA SQL review
on:
  pull_request:
    paths: ["**/db/migration/**", "**/db/changelog/**", "**/*.sql", "**/*.java", "**/mapper/**/*.xml"]
permissions:
  contents: read
  pull-requests: write      # PR comment
  security-events: write    # SARIF upload
  id-token: write           # the “SIXTA review” check by the sixta-connect App (optional)
jobs:
  sixta:
    runs-on: ubuntu-latest
    env:
      SIXTA_API_KEY: ${{ secrets.SIXTA_API_KEY }}
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }        # the review diffs against the PR base
      - uses: sixta-systems/sixta-ci@v1
        with:
          engine_version: "16"          # match production (verdicts are version-dependent)
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: sixta.sarif }

Django migrations are Python, so the job renders them to SQL with sqlmigrate first. That needs your project installed (the setup input) and a database for the planner: the disposable, empty postgres service below, never your data.

name: SIXTA SQL review
on:
  pull_request:
    paths: ["**/migrations/*.py", "**/*.sql"]
permissions:
  contents: read
  pull-requests: write      # PR comment
  security-events: write    # SARIF upload
  id-token: write           # the “SIXTA review” check by the sixta-connect App (optional)
jobs:
  sixta:
    runs-on: ubuntu-latest
    services:
      postgres:             # disposable empty DB for sqlmigrate rendering, never your data
        image: postgres:16
        env: { POSTGRES_DB: sixta_ci, POSTGRES_USER: sixta_ci, POSTGRES_PASSWORD: sixta_ci }
        ports: ["5432:5432"]
        options: >-
          --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
    env:
      SIXTA_API_KEY: ${{ secrets.SIXTA_API_KEY }}
      DATABASE_URL: postgres://sixta_ci:sixta_ci@localhost:5432/sixta_ci
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }        # the review diffs against the PR base
      - uses: sixta-systems/sixta-ci@v1
        with:
          engine_version: "16"          # match production (verdicts are version-dependent)
          setup: pip install -r requirements.txt    # whatever makes manage.py runnable
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: sixta.sarif }

Alembic migrations render offline via alembic upgrade --sql, so the job installs Alembic (the setup input) and needs no database at all. If your config isn't at the default alembic.ini, point at it with the alembic_config input. Data migrations (op.bulk_insert, op.get_bind) are flagged for human review, like Django's RunPython.

name: SIXTA SQL review
on:
  pull_request:
    paths: ["**/versions/*.py", "**/*.sql"]
permissions:
  contents: read
  pull-requests: write      # PR comment
  security-events: write    # SARIF upload
  id-token: write           # the “SIXTA review” check by the sixta-connect App (optional)
jobs:
  sixta:
    runs-on: ubuntu-latest
    env:
      SIXTA_API_KEY: ${{ secrets.SIXTA_API_KEY }}
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }        # the review diffs against the PR base
      - uses: sixta-systems/sixta-ci@v1
        with:
          engine_version: "16"          # match production (verdicts are version-dependent)
          setup: pip install alembic    # renders migrations offline, no database needed
      - uses: github/codeql-action/upload-sarif@v3
        if: always()
        with: { sarif_file: sixta.sarif }