​
Summary

  • Git Repositories: The Gable CLI runs as part of the CI/CD process and relies on access to a local git repository that’s checked out on a CI/CD runner. Gable processes only the files it’s explicitly configured to read. Processing includes sending the contents of the schema metadata of code and file based assets.
  • Relational Databases: When registering database assets, Gable collects metadata (information schema) from the relational databases it’s configured to register or check for contract violations, including schema and table names, table schemas, and CHECK constraints. Gable does not require SELECT grants on any tables outside information_schema, preventing access to the data itself. Gable also intentionally does not require access to production databases, instead opting to use a proxy database instance to extract metadata. For more information see Registering Relational Database Tables

​
Data Contract Publishing

Data contracts define the expected structure and semantics of your data. You can manage them in either of two ways:
  1. UI-managed contracts Create and edit contracts directly in the Gable web UI. Gable stores, versions, and serves these contracts via an authenticated API. During CI/CD, the Gable CLI (or the provided GitHub Action) pulls the latest versions automatically to validate changes.
  2. Git-backed YAML contracts You can optionally keep your contracts as YAML files in a repository you control. In your CI/CD workflow, the Gable CLI reads the local checkout of that repo, validates any changes to the contract, and pushes the relevant contract definitions to Gable via an authenticated REST API.

​
Registering Data Assets

​
Code & File Based

Gable collects schema information from code-based assets and serialization schema files such as Protobuf, Avro, and JSON Schema stored in your git repositories via the Gable CLI or provided Github Actions. This requires a local instance of the git repository to be available in either a development or CI/CD environment. Gable’s CLI only processes the files provided to the register command. The metadata read from the files is sent to the Gable platform by the CLI via authenticated REST API. Registering File Based Data Assets

​
Relational Database Tables (Postgres, MySQL, MS SQL Server)

Gable collects metadata about the structure of tables and views in RDBMS databases via the Gable CLI, or provided Github Actions that wrap the calls to the CLI. The CLI allows the user to specify which specific schemas and tables to collect metadata on. The metadata Gable collects includes the names and descriptions of tables, views, and fields as well as field types and any constraints on those fields. Gable does not require access to the underlying data, nor does it require access to your production databases, instead opting to use a proxy database instance created during the CI/CD process. Registering Database Tables For more information on the use of proxy databases, which eliminate the need to connect to production databases, see the documentation for registering database tables as data assets. You can use any role to connect to the proxy database that has at least read-only permissions on the Information Schema of the database, though we recommend creating a separate role with the least required privilege:
The metadata collected is then sent to the Gable platform by the CLI via authenticated REST API.