CI guide

Run local YDB in CI

Use the GitHub Action when integration tests need a real YDB endpoint without sharing developer machines or long-lived databases.

Tenant topology

- uses: astandrik/setup-local-ydb@v1
  id: ydb
  with:
    version: 26.1.1.6
    topology: tenant
    tenant: /local/test

Root-only topology

- uses: astandrik/setup-local-ydb@v1
  id: ydb-root
  with:
    version: 26.1.1.6
    topology: root

- run: |
    test "${{ steps.ydb-root.outputs.database }}" = "/local"
    test "${{ steps.ydb-root.outputs.endpoint }}" = "${{ steps.ydb-root.outputs.static-endpoint }}"

Native auth

- uses: astandrik/setup-local-ydb@v1
  id: ydb-auth
  with:
    version: 26.1.1.6
    topology: root
    auth: true

- run: |
    test "${{ steps.ydb-auth.outputs.username }}" = "root"
    test -f "${{ steps.ydb-auth.outputs.password-file }}"

Connection outputs

  • endpoint: application gRPC endpoint; dynamic for tenant topology and equal to static-endpoint for root.
  • static-endpoint: root/static gRPC endpoint.
  • database: tenant path or /local for root.
  • monitoring-url: host monitoring URL.
  • image and resolved-version: concrete image reference and tag.
  • username and password-file: present when auth: true.

Credential boundary

The action exports the username and password-file path when auth is enabled. It never writes the password value as an action output.

Best use cases

  • Integration tests that need LOCAL_YDB_ENDPOINT and LOCAL_YDB_DATABASE.
  • Schema smoke tests against an isolated tenant or root /local database.
  • Auth-enabled test scenarios that should not expose raw passwords.

Agent guidance

For CI setup, prefer the action. For interactive local operations, use the local stdio MCP server so tools can inspect Docker, logs, storage, auth, and version state.