Alpha flags
Alpha flags are experimental features that is in an early testing phase and is likely to change or be removed without prior notice. Do not use the product or functionality in production systems.
The Cognite Toolkit uses alpha flags to enable experimental functionality that we often plan to support in the next minor release.
By default, alpha flags aren't enabled. To enable them, you must update the cdf.toml file. For example, to enable the require-kind alpha flag, add the following to your cdf.toml file:
[alpha_flags]
require-kind = true
Cognite toolkit versioning and releases
The Cognite Toolkit uses semantic versioning to manage versions as major, minor, and patch (for example, 0.3.17).
-
A major version increases with breaking changes in the CLI or the format of modules and configuration files. Installing a new major toolkit version may require updating your configuration files or modules.
-
Minor versions increase with new features and patch versions with bug fixes.
As long as the major version is 0, breaking changes may happen between minor versions.
The toolkit follows a release cycle of alpha, beta, and stable releases, shown by 'a' and 'b' in the version number.
- Alpha releases (for example,
0.3.0a1) test new features, may contain breaking changes, and aren't recommended for production. - Beta releases (
0.3.0b1) focus on stability and bug fixes and are suitable for non-production testing. - Stable releases (
0.3.0) are production-ready.
Introducing new functionality in stable versions can lead to new bugs. Alpha flags allow you to selectively enable new functionality, minimizing the risk of introducing new bugs. The state of alpha flags vary, with some planned for future releases and others being experimental, requiring further testing.
Alpha flag: require-kind
Status: planned for 0.4.0
[alpha_flags]
require-kind = true
This flags requires that all resource files have a kind suffix in the filename. For example, a file containing a transformation must be named my_transformation.Transformation.yaml. This is already the case for all resources that have been added from the 0.2.0 release. The flag will be removed in the 0.4.0 release, as it will be the default behavior.
Alpha flag: run-workflow
Status: planned for 0.4.0
[alpha_flags]
run-workflow = true
[plugins]
run = true
This flag enables the cdf run workflow command to run a workflow from the command line. The feature requires the run plugin to be enabled. The flag will be removed in the 0.4.0 release, and the run plugin will have the workflow command enabled by default.
Alpha flag: streamlit
Status: planned for 0.4.0
[alpha_flags]
streamlit = true
This flag enables you to govern streamlit applications with the toolkit. The applications should be in a streamlit directory in a module. For more information, see the Streamlit applications resource. The flag will be removed in the 0.4.0 release, and the streamlit applications will be enabled by default.
Alpha flag: edges
Status: planned for 0.4.0
[alpha_flags]
edges = true
This flag enables you to define edges in the data_models directory to to define a connection between nodes. The flag will be removed in the 0.4.0 release, and edges will be enabled by default. For more information, see the Edges resource.
Alpha flag: classic
Status: Planned for 0.4.0
[alpha_flags]
classic = true
This flag enables you to define Event and Relationship resources in the classic directory. The
flag will be removed in the 0.4.0 release, and the classic resources will be enabled by default.
For more information, see the Event and
Relationships resources.
Alpha flag: module-repeat
Status: Experimental
[alpha_flags]
module-repeat = true
This flag enables you to deploy the same module multiple times, for example, if you have multiple locations that should all have the same module deployed.
To deploy the same module multiple times, you must define a list of variables in the config.[env].yaml file. For
example, if you have a module my_module with a data set resource:
./modules/
└── my_module/
└── data_sets/
└── location.DataSet.yaml
./config.dev.yaml
The location.DataSet.yaml file looks like this:
- externalId: ds_{{ location }}_assets
name: Dataset for assets on {{ location }}
description: This is the dataset for all assets on {{ location }}
In the config.dev.yaml file, define a list under the my_module key:
environment: ...
variables:
modules:
to_repeat:
- location: oslo
- location: new_york
This creates two data sets, one for Oslo and one for New York.
In the build directory, you will get these two files:
- externalId: ds_oslo_assets
name: Dataset for assets on oslo
description: This is the dataset for all assets on oslo
- externalId: ds_new_york_assets
name: Dataset for assets on new_york
description: This is the dataset for all assets on new_york
Alpha flag: force-update
Status: experimental
[alpha_flags]
force-update = true
This flags adds an option --force-update to the cdf deploy command. This option force all resources to update, even if they haven't changed. Use this option, for example, if your credentials have changed and you need to update them in the Cognite Toolkit.
Alpha flag: purge
Status: experimental
[alpha_flags]
purge = true
This flags adds a new command cdf purge to delete all resources in a DataSet or Space.
This command deletes all resources in the DataSet or Space. Use with caution.
Alpha flag: ado-pipelines
Status: planned for 0.4.0
[alpha_flags]
ado-pipelines = true
This flags adds the option Azure Devops when you run the cdf repo init command. The command adds the files deploy-pipeline.yaml and dry-run-pipeline.yaml to the .devops directory. This enables you to deploy your modules using the toolkit from Azure Devops. The flag will be removed in the 0.4.0 release, and the Azure Devops pipelines option will be enabled by default.
Alpha flag: import-cmd
Status: experimental
[alpha_flags]
import-cmd = true
This flag enables the cdf import command. The only subcommand available is transformation-cli. The command converts the transformation-cli manifest files to the Cognite API (Toolkit) format. Use this, for example, if you have transformations managed by the transformation-cli and want to convert them to the toolkit format.