Socket
Socket
Sign inDemoInstall

@aws-cdk/cloud-assembly-schema

Package Overview
Dependencies
2
Maintainers
5
Versions
443
Alerts
File Explorer

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies

Install

@aws-cdk/cloud-assembly-schema


Version published
Maintainers
5
Created

Package description

What is @aws-cdk/cloud-assembly-schema?

@aws-cdk/cloud-assembly-schema is a package that defines the schema for AWS Cloud Development Kit (CDK) cloud assemblies. It provides a set of TypeScript interfaces and JSON schemas that describe the structure of the cloud assembly, which is the output of the CDK synthesis process. This package is essential for tools and libraries that need to interact with or manipulate CDK cloud assemblies.

What are @aws-cdk/cloud-assembly-schema's main functionalities?

Cloud Assembly Schema Definition

Defines the schema for a cloud assembly, including the version and artifacts. This schema is used to validate the structure of a cloud assembly JSON file.

{"type":"object","properties":{"version":{"type":"string"},"artifacts":{"type":"object","additionalProperties":{"$ref":"#/definitions/Artifact"}}},"required":["version","artifacts"],"definitions":{"Artifact":{"type":"object","properties":{"type":{"type":"string"},"properties":{"type":"object"}},"required":["type"]}}}

Artifact Type Definitions

Defines the schema for different types of artifacts, such as CloudFormation stacks and CDK assets. This schema is used to validate the structure of artifact definitions within a cloud assembly.

{"type":"object","properties":{"type":{"type":"string","enum":["aws:cloudformation:stack","aws:cdk:asset"]},"properties":{"type":"object","properties":{"templateFile":{"type":"string"},"parameters":{"type":"object","additionalProperties":{"type":"string"}}},"required":["templateFile"]}},"required":["type","properties"]}

Other packages similar to @aws-cdk/cloud-assembly-schema

Changelog

Source

1.78.0 (2020-12-11)

⚠ BREAKING CHANGES TO EXPERIMENTAL FEATURES

  • cloudfront-origins: Default minimum origin SSL protocol for HttpOrigin and LoadBalancerOrigin changed from SSLv3 to TLSv1.2.
  • apigatewayv2: domainName property under DomainName has been renamed to name.
  • appmesh: the properties dnsHostName and awsCloudMap of VirtualNodeProps have been replaced with the property serviceDiscovery
  • kms: change the default value of trustAccountIdentities to true, which will result in the key getting the KMS-recommended default key policy. This is enabled through the '@aws-cdk/aws-kms:defaultKeyPolicies' feature flag.

Features

  • appmesh: add ClientPolicy to VirtualNode, VirtualGateway and VirtualService (#11563) (bfee58c)
  • appmesh: change Virtual Node service discovery to a union-like class (#11926) (f75c264)
  • appsync: support appsync functions for pipelineConfig (#10111) (cb703c7), closes #9092
  • batch: Log configuration for job definitions (#11771) (84c959c), closes #11218
  • cloudfront: responseHttpStatus defaults to httpStatus in errorResponses (#11879) (c6052ae)
  • cloudfront: the Distribution construct is now Generally Available (stable) (#11919) (442bf7e)
  • cloudfront-origins: ability to specify minimum origin SSL protocol (#11997) (a0aa61d), closes #11994
  • cloudfront-origins: CloudFront Origins is now Generally Available (#12011) (daace16), closes #11919
  • codeguruprofiler: the CodeGuru Profiler Construct Library is now Generally Available (stable) (#11924) (cbe7a10)
  • ecs: introduce a new Image type, TagParameterContainerImage, to be used in CodePipeline (#11795) (4182c40), closes #1237 #7746
  • eks: kubernetes resource pruning (#11932) (1fdd549), closes #10495
  • kms: change default key policy to align with KMS best practices (under feature flag) (#11918) (ff695da), closes #5575 #8977 #10575 #11309
  • s3: add support to set bucket OwnershipControls (#11834) (0d289cc), closes #11591

Bug Fixes

  • apigateway: base path url cannot contain upper case characters (#11799) (8069a7e)
  • cfn-include: cfn-include fails in monocdk (#11595) (45e43f2), closes #11342
  • cli: cross-account deployment no longer works (#11966) (6fb3448), closes #11350 #11792 #11792
  • codebuild: incorrect SSM Parameter ARN in Project's IAM permissions (#11917) (7a09c18), closes #9980
  • core: autogenerated exports do not account for stack name length (#11909) (0df79a2), closes #9733
  • ecs: cannot disable container insights of an ECS cluster (#9151) (e328f22), closes #9149
  • eks: kubectl provider out-of-memory for large manifests/charts (now 1GiB) (#11957) (2ec2948), closes #11787
  • synthetics: metricFailed uses Average instead of Sum by default (#11941) (3530e8c)
  • apigatewayv2: rename 'domainName' to 'name' in the DomainName construct (#11989) (1be831a)

Readme

Source

Cloud Assembly Schema


cdk-constructs: Stable


This module is part of the AWS Cloud Development Kit project.

Cloud Assembly

The Cloud Assembly is the output of the synthesis operation. It is produced as part of the cdk synth command, or the app.synth() method invocation.

Its essentially a set of files and directories, one of which is the manifest.json file. It defines the set of instructions that are needed in order to deploy the assembly directory.

For example, when cdk deploy is executed, the CLI reads this file and performs its instructions:

  • Build container images.
  • Upload assets.
  • Deploy CloudFormation templates.

Therefore, the assembly is how the CDK class library and CDK CLI (or any other consumer) communicate. To ensure compatibility between the assembly and its consumers, we treat the manifest file as a well defined, versioned schema.

Schema

This module contains the typescript structs that comprise the manifest.json file, as well as the generated json-schema.

Versioning

The schema version is specified in the cloud-assembly.version.json file, under the version property. It follows semantic versioning, but with a small twist.

When we add instructions to the assembly, they are reflected in the manifest file and the json-schema accordingly. Every such instruction, is crucial for ensuring the correct deployment behavior. This means that to properly deploy a cloud assembly, consumers must be aware of every such instruction modification.

For this reason, every change to the schema, even though it might not strictly break validation of the json-schema format, is considered major version bump.

How to consume

If you'd like to consume the schema file in order to do validations on manifest.json files, simply download it from this repo and run it against standard json-schema validators, such as jsonschema.

Consumers must take into account the major version of the schema they are consuming. They should reject cloud assemblies with a major version that is higher than what they expect. While schema validation might pass on such assemblies, the deployment integrity cannot be guaranteed because some instructions will be ignored.

For example, if your consumer was built when the schema version was 2.0.0, you should reject deploying cloud assemblies with a manifest version of 3.0.0.

Contributing

See Contribution Guide

Keywords

FAQs

Last updated on 12 Dec 2020

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Packages

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc