Define infrastructure resources using programming constructs and provision them using HashiCorp Terraform
Breaking changes
We updated our C# template to .NET 6.0 as JSII updated recently and dropped support for netcoreapp3.1:
The runtime library for .NET & generated .NET bindings will no longer support netcoreapp3.1 after this release. Users are advised to upgrade their apps to use net6.0 or net7.0 instead.
from JSII v.1.76.0 release notes
Terraform functions are now generated based on the JSON schema returned by the new metadata functions command which is going to be added to the Terraform CLI in version 1.4 (PR #32487, already available in v1.4.0-beta2).
The following new functions were introduced:
Fn.endswith() - checks the suffix of a stringFn.startswith() - checks the prefix of a stringFn.timecmp() - compares two timestampsThe following functions changed:
Fn.parseInt() is now Fn.parseint() to match the format of all other functionsFn.mergeLists() does not exist anymore, use Fn.concat() insteadFn.mergeMaps() does not exist anymore, use Fn.merge() insteadAs part of this change, we use the same parameter names as Terraform which might require changing keyword arguments in Python.
Fn.join(",", [src.stringResource.result, src.stringResource.result])
Fn.join(separator=",", value=[src.stringResource.result, src.stringResource.result])
terraform init when not required #2572
Breaking changes
*Options and *Props to *ConfigWe had several exports where the configuration passed to constructs or functions was using a class with a different suffix then Config. If you are using a language like C#, Java, Python, or Go you might have needed to specify these classes in your CDKTF application. To simplify the usage we changed every suffix to be Config, so if you currently use one of the others please rename them to use the Config suffix. No options were changed in the process, only the names were aligned.
This would be one example of the change to be made (this is in Java):
import software.constructs.Construct;
import com.hashicorp.cdktf.App;
import com.hashicorp.cdktf.TerraformStack;
import com.hashicorp.cdktf.CloudBackend;
-import com.hashicorp.cdktf.CloudBackendProps;
+import com.hashicorp.cdktf.CloudBackendConfig;
import com.hashicorp.cdktf.NamedCloudWorkspace;
public static class Demo extends TerraformStack{
public Demo(Construct scope, String id){
super(scope, id);
- new CloudBackend(this, CloudBackendProps.builder()
+ new CloudBackend(this, CloudBackendConfig.builder()
.organization("hashicorp")
.workspaces(new NamedCloudWorkspace("demo"))
.build()
);
CDKTF is bumping the minimum supported version of Terraform from 1.0 to 1.2 starting from CDKTF version 0.15. This change is necessary as CDKTF 0.15 uses the Terraform CLI for planning and applying changes for Terraform Cloud and Terraform Enterprise instead of the API used in version 0.14.
Terraform promises compatibility between all v1.x releases, so there shouldn't be any issues with this change. The only changes between these versions are bug fixes, and new feature additions.
Please open an issue if you encounter any issues or bugs with this change.
context field of the cdktf.jsonCDKTF used to use feature flags to enable potentially breaking behaviors in a release. These are no longer needed since most of the changes we introduce from here can not be hidden behind feature flags. When the feature flags are removed, the behavior will be the same as this configuration:
{
"context": {
"excludeStackIdFromLogicalIds": "true",
"allowSepCharsInLogicalIds": "true"
}
}
environment to keys to preserve case #2446
required_version to json schema #2355
1.3.4 to Docker container #2285
Breaking changes
We split up our cdktf-cli package into cdktf-cli for the UI parts, utilizing @cdktf/cli-core for the functionality. If you previously relied on the internal cdktf-cli/lib entrypoint you should switch to @cdktf/cli-core. This was never an official API, but we want to mention it here in case it breaks for anyone.
cdktf with non-admin tokens #2258