Skip to content

Manage data contracts

Limited availability

Data contracts can currently only be managed for tables, views, materialized views, and data products.

Initialize a contract


To generate a contract for an existing asset in Atlan:

atlan init contract \  # (1)
    --asset "Table@CUST_TXN" \  # (2)
    --data-source "snowflake"  # (3)
  1. Use atlan init contract to initialize a contract. If you provide no other arguments, the CLI will generate a skeletal contract you can fill in yourself.
  2. To pre-populate the contract with information about a dataset, you must provide the type and (technical) name of the asset to generate from, in the format TypeName@name.
  3. To pre-populate the contract, you must also provide the name of the data source in which to find the asset.

This will generate a contract in your current working directory, using the details from the asset in Atlan as a starting point. (This requires you to first configure the Atlan CLI with details about your tenant.)

Can I manage contracts without Atlan connectivity?

You can also initialize a contract without any connection to Atlan, by leaving out the --asset and --data-source arguments. This will provide you a skeletal contract you can then fill in yourself.

Validate contract


You can validate the contract file is syntactically correct and refers to an asset known to Atlan:

atlan validate contract \  # (1)
    -f "contract.yaml"  # (2)
  1. Use atlan validate contract to validate a contract.
  2. You must specify the filename that defines the contract.

Push contract


To apply the contract in Atlan, you then need to push the contract:

atlan push contract \  # (1)
    -f "contract.yaml"  # (2)
  1. Use atlan push contract to push a contract.
  2. You must specify the filename that defines the contract.

Managing via CI/CD

You can combine the actions above to manage data contracts via automated CI/CD pipelines. For example, a process to automate publication of data contracts could be as follows:

Configure CLI for CI/CD

First, configure the CLI within your CI/CD environment.

Separate sensitive and non-sensitive configuration

As a general rule, we recommend removing sensitive information (like the API token) from your configuration file. Instead manage this through an environment variable, which your CI/CD environment can inject into the job that runs the CLI. (For example, in GitHub you can use GitHub Secrets to manage the API token and have it automatically injected as an environment variable in GitHub Actions.)

The non-sensitive configuration details can remain in the configuration file, and the configuration file itself can then be version-controlled in your source code repository, too.

Publish contracts from CI/CD

Once configured, you can use the CLI to publish any new contracts or changes to existing contracts:

  1. Commit contract file(s) to your revision control repository.
  2. Apply any validations or approval processes you like in your revision control repository. (For example, GitHub Actions that are triggered by pull request events.)
  3. When the committed changes are merged to a particular branch (for example, main), trigger an action to publish them to Atlan using the command in the push contract step.