You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: INTEGRATION_TESTS.md
+9-9
Original file line number
Diff line number
Diff line change
@@ -49,8 +49,8 @@ an integration test for the new feature can ensure that it works and avoid unnec
49
49
50
50
**3. Involves configuring resource types across services (i.e. integrations)**
51
51
For example, you are adding functionality that allows for service x to integrate with service y.
52
-
A good example of this is the [aws-stepfunctions-tasks](./packages/@aws-cdk/aws-stepfunctions-tasks) or
53
-
[aws-apigatewayv2-integrations](./packages/@aws-cdk/aws-apigatewayv2-integrations) modules. Both of these
52
+
A good example of this is the [aws-stepfunctions-tasks](./packages/aws-cdk-lib/aws-stepfunctions-tasks) or
53
+
[aws-apigatewayv2-integrations-alpha](./packages/@aws-cdk/aws-apigatewayv2-integrations-alpha) modules. Both of these
54
54
have L2 constructs that provide functionality to integrate services.
55
55
56
56
Sometimes these integrations involve configuring/formatting json/vtl or some other type of data.
@@ -82,8 +82,8 @@ Lambda Function would look like this:
82
82
83
83
_integ.lambda.ts_
84
84
```ts
85
-
import*asiamfrom'@aws-cdk/aws-iam';
86
-
import*ascdkfrom'@aws-cdk/core';
85
+
import*asiamfrom'aws-cdk-lib/aws-iam';
86
+
import*ascdkfrom'aws-cdk-lib/core';
87
87
import*aslambdafrom'../lib';
88
88
import*asintegfrom'@aws-cdk/integ-tests-alpha';
89
89
@@ -230,11 +230,11 @@ to deploy the Lambda Function _and_ then rerun the assertions to ensure that the
230
230
### Assertions
231
231
232
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
233
+
test succeeds. A good example of this is the `aws-cdk-lib/aws-stepfunctions-tasks` module which creates integrations between
234
234
AWS StepFunctions and other AWS services.
235
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`
236
+
If we look at the [integ.put-events.ts](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk-testing/framework-integ/test/aws-stepfunctions-tasks/test/eventbridge/integ.put-events.ts)
237
+
integration test we can see that we are creating an `aws-cdk-lib/aws-events.EventBus` along with a `aws-cdk-lib/aws-stepfunctions.StateMachine`
238
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
239
infrastructure deployed successfully would be enough of a validation that the test succeeded. In this case though, we ideally
240
240
want to validate that the _integration_ connecting `StepFunctions` to the `EventBus` has been setup correctly, and the only
@@ -269,8 +269,8 @@ Not every test requires an assertion. We typically do not need to assert CloudFo
269
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
270
Some things you should look for in deciding if the test needs an assertion:
271
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)
272
+
- Integrations between services (i.e. integration libraries like `aws-cdk-lib/aws-lambda-destinations`, `aws-cdk-lib/aws-stepfunctions-tasks`, etc)
273
+
- Anything that bundles or deploys custom code (i.e. does a Lambda function bundled with `aws-cdk-lib/aws-lambda-nodejs` still invoke or did we break bundling behavior)
274
274
- IAM/Networking connections.
275
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
Copy file name to clipboardExpand all lines: design/aws-ecs/aws-ecs-fargate-capacity-providers.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -103,11 +103,11 @@ This new field would be added to the BaseService, not only for better extensibil
103
103
104
104
Implications Setting Launch Type
105
105
106
-
Since it can be reasonably assumed that any CapacityProvideStrategies defined on the Service are what the customer intends to use on the Service, the LaunchType will *not* be set on the Service if CapacityProvideStrategies are specified. This is similar to how the LaunchType field is unset if the service uses an external DeploymentController (https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/base/base-service.ts#L374).
106
+
Since it can be reasonably assumed that any CapacityProvideStrategies defined on the Service are what the customer intends to use on the Service, the LaunchType will *not* be set on the Service if CapacityProvideStrategies are specified. This is similar to how the LaunchType field is unset if the service uses an external DeploymentController (https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/base/base-service.ts#L587).
107
107
108
108
On the other hand, this intent would not be as obvious with Default Capacity Provider Strategies defined a cluster. A *defaultCapacityProviderStrategy* specified on a cluster is used for any service that does not specify either a launchType or its own CapacityProviderStrategies. From the point of view of the ECS APIs, similar to how custom CapacityProvideStrategies defined on the Service are expected to supersede the defaultCapacityProviderStrategy on a cluster, the expected behavior for an ECS Service that specifies a launchType is for it to also ignore the Cluster’s defaultCapacityProviderStrategy.
109
109
110
-
However, since the two Service constructs in the CDK (Ec2Service and FargateService) do not support having the launchType field passed in explicitly, it would not possible to infer whether the intent of the customer using one of these Service constructs is to use the implied launchType (currently set under the hood in the service’s constructor (https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/fargate/fargate-service.ts#L155)) or the defaultCapacityProviderStrategy. For this reason, we will not be adding the defaultCapacityProviderStrategy field on the Cluster construct for this iteration.
110
+
However, since the two Service constructs in the CDK (Ec2Service and FargateService) do not support having the launchType field passed in explicitly, it would not possible to infer whether the intent of the customer using one of these Service constructs is to use the implied launchType (currently set under the hood in the service’s constructor (https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/fargate/fargate-service.ts#L134) or the defaultCapacityProviderStrategy. For this reason, we will not be adding the defaultCapacityProviderStrategy field on the Cluster construct for this iteration.
111
111
112
112
_*Note*_: Future for support will be dependent on a re-design of the existing Service strategies. This will be treated in v2 of the ECS modules, likely with a single Service L2 construct and deprecation of the Ec2Service and FargateService constructs.
Copy file name to clipboardExpand all lines: design/aws-ecs/aws-ecs-priv-registry-support.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -2,11 +2,11 @@
2
2
3
3
To address issue [#1698](https://github.com/aws/aws-cdk/issues/1698), the ECS construct library should provide a way for customers to specify [`repositoryCredentials`](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html#ECS-Type-ContainerDefinition-repositoryCredentials) on their container.
4
4
5
-
Minimally, this would mean adding a new string field on `ContainerDefinition`, however this doesn't provide any added value in terms of logical grouping or resource creation. We can instead modify the existing ECS CDK construct [`ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/container-image.ts) so that repository credentials are specified along with the image they're meant to access.
5
+
Minimally, this would mean adding a new string field on `ContainerDefinition`, however this doesn't provide any added value in terms of logical grouping or resource creation. We can instead modify the existing ECS CDK construct [`ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/container-image.ts) so that repository credentials are specified along with the image they're meant to access.
6
6
7
7
## General approach
8
8
9
-
The [`ecs.ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-ecs/lib/container-image.ts) class already includes constructs for 3 types of images:
9
+
The [`ecs.ContainerImage`](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-ecs/lib/container-image.ts) class already includes constructs for 3 types of images:
Copy file name to clipboardExpand all lines: packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.vpc-flow-logs-customformat.js.snapshot/FlowLogsTestStack.assets.json
Copy file name to clipboardExpand all lines: packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.vpc-flow-logs-customformat.js.snapshot/FlowLogsTestStack.template.json
Copy file name to clipboardExpand all lines: packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.vpc-flow-logs-customformat.js.snapshot/manifest.json
Copy file name to clipboardExpand all lines: packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.vpc-flow-logs-customformat.js.snapshot/tree.json
Copy file name to clipboardExpand all lines: packages/@aws-cdk-testing/framework-integ/test/aws-ec2/test/integ.vpc-flow-logs-interval.js.snapshot/FlowLogsTestStack.assets.json
0 commit comments