|
| 1 | +# Cloud Assembly Schema |
| 2 | + |
| 3 | +This module is part of the [AWS Cloud Development Kit](https://github.com/aws/aws-cdk) project. |
| 4 | + |
| 5 | +## Cloud Assembly |
| 6 | + |
| 7 | +The _Cloud Assembly_ is the output of the synthesis operation. It is produced as part of the |
| 8 | +[`cdk synth`](https://github.com/aws/aws-cdk/tree/main/packages/aws-cdk#cdk-synthesize) |
| 9 | +command, or the [`app.synth()`](https://github.com/aws/aws-cdk/blob/main/packages/@aws-cdk/core/lib/app.ts#L135) method invocation. |
| 10 | + |
| 11 | +Its essentially a set of files and directories, one of which is the `manifest.json` file. It defines the set of instructions that are |
| 12 | +needed in order to deploy the assembly directory. |
| 13 | + |
| 14 | +> For example, when `cdk deploy` is executed, the CLI reads this file and performs its instructions: |
| 15 | +> |
| 16 | +> - Build container images. |
| 17 | +> - Upload assets. |
| 18 | +> - Deploy CloudFormation templates. |
| 19 | +
|
| 20 | +Therefore, the assembly is how the CDK class library and CDK CLI (or any other consumer) communicate. To ensure compatibility |
| 21 | +between the assembly and its consumers, we treat the manifest file as a well defined, versioned schema. |
| 22 | + |
| 23 | +## Schema |
| 24 | + |
| 25 | +This module contains the typescript structs that comprise the `manifest.json` file, as well as the |
| 26 | +generated [_json-schema_](./schema/cloud-assembly.schema.json). |
| 27 | + |
| 28 | +## Versioning |
| 29 | + |
| 30 | +The schema version is specified my the major version of the package release. It follows semantic versioning, but with a small twist. |
| 31 | + |
| 32 | +When we add instructions to the assembly, they are reflected in the manifest file and the _json-schema_ accordingly. |
| 33 | +Every such instruction, is crucial for ensuring the correct deployment behavior. This means that to properly deploy a cloud assembly, |
| 34 | +consumers must be aware of every such instruction modification. |
| 35 | + |
| 36 | +For this reason, every change to the schema, even though it might not strictly break validation of the _json-schema_ format, |
| 37 | +is considered `major` version bump. All changes that do not impact the schema are considered a `minor` version bump. |
| 38 | + |
| 39 | +## How to consume |
| 40 | + |
| 41 | +If you'd like to consume the [schema file](./schema/cloud-assembly.schema.json) in order to do validations on `manifest.json` files, |
| 42 | +simply download it from this repo and run it against standard _json-schema_ validators, such as [jsonschema](https://www.npmjs.com/package/jsonschema). |
| 43 | + |
| 44 | +Consumers must take into account the `major` version of the schema they are consuming. They should reject cloud assemblies |
| 45 | +with a `major` version that is higher than what they expect. While schema validation might pass on such assemblies, the deployment integrity |
| 46 | +cannot be guaranteed because some instructions will be ignored. |
| 47 | + |
| 48 | +> For example, if your consumer was built when the schema version was 2.0.0, you should reject deploying cloud assemblies with a |
| 49 | +> manifest version of 3.0.0. |
| 50 | +
|
| 51 | +## Contributing |
| 52 | + |
| 53 | +The source code for this file has been moved to CDKLabs. |
| 54 | + |
| 55 | +See [Contribution Guide](https://github.com/cdklabs/cloud-assembly-schema/blob/main/CONTRIBUTING.md) |
0 commit comments