Skip to content

Commit 398e7b6

Browse files
mergify[bot]mergify[bot]
authored
Merge branch 'main' into feature/cloudwatch-row-widget-list
2 parents 6b0cf88 + 23ee450 commit 398e7b6

56 files changed

Lines changed: 2591 additions & 190 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎CONTRIBUTING.md‎

Lines changed: 8 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -256,7 +256,7 @@ Work your magic. Here are some guidelines:
256256

257257
Integration tests perform a few functions in the CDK code base -
258258
1. Acts as a regression detector. It does this by running `cdk synth` on the integration test and comparing it against
259-
the `*.expected.json` file. This highlights how a change affects the synthesized stacks.
259+
the `*.integ.snapshot` directory. This highlights how a change affects the synthesized stacks.
260260
2. Allows for a way to verify if the stacks are still valid CloudFormation templates, as part of an intrusive change.
261261
This is done by running `yarn integ` which will run `cdk deploy` across all of the integration tests in that package. If you are developing a new integration test or for some other reason want to work on a single integration test over and over again without running through all the integration tests you can do so using `yarn integ integ.test-name.js`
262262
Remember to set up AWS credentials before doing this.
@@ -275,9 +275,10 @@ new features unless there is a good reason why one is not needed.
275275
4. Adding a new supported version (e.g. a new [AuroraMysqlEngineVersion](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_rds.AuroraMysqlEngineVersion.html))
276276
5. Adding any functionality via a [Custom Resource](https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.custom_resources-readme.html)
277277

278-
To the extent possible, include a section (like below) in the integration test file that specifies how the successfully
279-
deployed stack can be verified for correctness. Correctness here implies that the resources have been set up correctly.
280-
The steps here are usually AWS CLI commands but they need not be.
278+
All integration tests going forward should use the [IntegTest](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-tests)
279+
construct. Over time we will be updating all of our existing tests to use this construct. It
280+
allows for more control over configuring each tests as well as the ability to perform
281+
assertions against the deployed infrastructure.
281282

282283
```ts
283284
/*
@@ -288,8 +289,8 @@ The steps here are usually AWS CLI commands but they need not be.
288289
```
289290

290291
Examples:
291-
* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-lambda-destinations/test/integ.destinations.ts#L7)
292-
* [integ.token-authorizer.lit.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-apigateway/test/authorizers/integ.token-authorizer.lit.ts#L7-L12)
292+
* [integ.destinations.ts](https://github.com/aws/aws-cdk/blob/master/packages/%40aws-cdk/aws-lambda-destinations/test/integ.destinations.ts#L7)
293+
* [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
293294

294295
**What do do if you cannot run integration tests**
295296

@@ -827,16 +828,7 @@ $ <path to the AWS CDK repo>/link-all.sh
827828

828829
### Running integration tests in parallel
829830

830-
Integration tests may take a long time to complete. We can speed this up by running them in parallel
831-
in different regions.
832-
833-
```shell
834-
# Install GNU parallel (may require uninstall 'moreutils' if you have it)
835-
$ apt-get install parallel
836-
$ brew install parallel
837-
838-
$ scripts/run-integ-parallel @aws-cdk/aws-ec2 @aws-cdk/aws-autoscaling ...
839-
```
831+
See the [Integration testing guide](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md#running-large-numbers-of-tests)
840832

841833
### Visualizing dependencies in a CloudFormation Template
842834

‎INTEGRATION_TESTS.md‎

Lines changed: 51 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -85,6 +85,7 @@ _integ.lambda.ts_
8585
import * as iam from '@aws-cdk/aws-iam';
8686
import * as cdk from '@aws-cdk/core';
8787
import * as lambda from '../lib';
88+
import * as integ from '@aws-cdk/integ-tests';
8889

8990
const app = new cdk.App();
9091

@@ -96,6 +97,10 @@ const fn = new lambda.Function(stack, 'MyLambda', {
9697
runtime: lambda.Runtime.NODEJS_14_X,
9798
});
9899

100+
new integ.IntegTest(app, 'LambdaTest', {
101+
testCases: [stack],
102+
});
103+
99104
app.synth();
100105
```
101106

@@ -223,7 +228,52 @@ but it will not validate that the Lambda function can be invoked. Because of thi
223228
to deploy the Lambda Function _and_ then rerun the assertions to ensure that the function can still be invoked.
224229

225230
### Assertions
226-
...Coming soon...
231+
232+
Sometimes it is necessary to perform some form of _assertion_ against the deployed infrastructure to validate that the
233+
test succeeds. A good example of this is the `@aws-cdk/aws-stepfunctions-tasks` module which creates integrations between
234+
AWS StepFunctions and other AWS services.
235+
236+
If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
237+
integration test we can see that we are creating an `@aws-cdk/aws-events.EventBus` along with a `@aws-cdk/aws-stepfunctions.StateMachine`
238+
which will send an event to the `EventBus`. In a typical integration test we would just deploy the test and the fact that the
239+
infrastructure deployed successfully would be enough of a validation that the test succeeded. In this case though, we ideally
240+
want to validate that the _integration_ connecting `StepFunctions` to the `EventBus` has been setup correctly, and the only
241+
way to do that is to actually trigger the `StateMachine` and validate that it was successful.
242+
243+
```ts
244+
declare const app: App;
245+
declare const sm: sfn.StateMachine;
246+
declare const stack: Stack;
247+
248+
const testCase = new IntegTest(app, 'PutEvents', {
249+
testCases: [stack],
250+
});
251+
252+
// Start an execution
253+
const start = testCase.assertions.awsApiCall('StepFunctions', 'startExecution', {
254+
stateMachineArn: sm.stateMachineArn,
255+
});
256+
257+
// describe the results of the execution
258+
const describe = testCase.assertions.awsApiCall('StepFunctions', 'describeExecution', {
259+
executionArn: start.getAttString('executionArn'),
260+
});
261+
262+
// assert the results
263+
describe.expect(ExpectedResult.objectLike({
264+
status: 'SUCCEEDED',
265+
}));
266+
```
267+
268+
Not every test requires an assertion. We typically do not need to assert CloudFormation behavior. For example, if we create an S3 Bucket
269+
with Encryption, we do not need to assert that Encryption is set on the bucket. We can trust that the CloudFormation behavior works.
270+
Some things you should look for in deciding if the test needs an assertion:
271+
272+
- Integrations between services (i.e. integration libraries like `@aws-cdk/aws-lambda-destinations`, `@aws-cdk/aws-stepfunctions-tasks`, etc)
273+
- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `@aws-cdk/aws-lambda-nodejs` still invoke or did we break bundling behavior)
274+
- IAM/Networking connections.
275+
- This one is a bit of a judgement call. Most things do not need assertions, but sometimes we handle complicated configurations involving IAM permissions or
276+
Networking access.
227277

228278
## Running Integration Tests
229279

‎packages/@aws-cdk/aws-ec2/README.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -962,6 +962,16 @@ new ec2.Instance(this, 'Instance4', {
962962
generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2022,
963963
}),
964964
});
965+
966+
// Graviton 3 Processor
967+
new ec2.Instance(this, 'Instance5', {
968+
vpc,
969+
instanceType: ec2.InstanceType.of(ec2.InstanceClass.C7G, ec2.InstanceSize.LARGE),
970+
machineImage: new ec2.AmazonLinuxImage({
971+
generation: ec2.AmazonLinuxGeneration.AMAZON_LINUX_2,
972+
cpuType: ec2.AmazonLinuxCpuType.ARM_64,
973+
}),
974+
});
965975
```
966976

967977
### Configuring Instances using CloudFormation Init (cfn-init)

‎packages/@aws-cdk/aws-ec2/lib/instance-types.ts‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -368,6 +368,16 @@ export enum InstanceClass {
368368
*/
369369
C6G = 'c6g',
370370

371+
/**
372+
* Compute optimized instances for high performance computing, 7th generation with Graviton3 processors
373+
*/
374+
COMPUTE7_GRAVITON3 = 'c7g',
375+
376+
/**
377+
* Compute optimized instances for high performance computing, 7th generation with Graviton3 processors
378+
*/
379+
C7G = 'c7g',
380+
371381
/**
372382
* Compute optimized instances for high performance computing, 6th generation with Graviton2 processors
373383
* and local NVME drive

0 commit comments

Comments
 (0)