fix(ecs): new arn format not supported (under feature flag) #18140

jumic · 2021-12-22T22:14:17Z

AWS has changed the ARN format for ECS. Currently, CDK doesn't return the correct values/ARNs if the new ARN format is used in ECS.

Changed methods:

Ec2Service.fromEc2ServiceAttributes()
Ec2Service.fromEc2ServiceArn()
FargateService.fromFargateServiceAttributes()
FargateService.fromFargateServiceArn()

The logic automatically detects whether the old or new format is used. The format cannot be recognized automatically for tokenized values. Therefore the feature flag ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME is introduced, which controls whether the old or the new format should be used.

In Ec2Service.fromEc2ServiceAttributes() and FargateService.fromFargateServiceAttributes() an ARN is created. In these methods the feature flag be considered to construct the ARN in the correct format.

Closes #16634.
Closes #18137.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

gitpod-io · 2021-12-22T22:14:19Z

madeline-k

Thanks for contributing this fix, @jumic! This looks great, I just have a couple questions/comments.

madeline-k · 2021-12-23T21:42:37Z

packages/@aws-cdk/aws-ecs/lib/base/from-service-attributes.ts

@@ -32,22 +37,38 @@ export function fromServiceAtrributes(scope: Construct, id: string, attrs: Servi
    throw new Error('You can only specify either serviceArn or serviceName.');
  }

+  const featureConstruct = new CoreConstruct(scope, randomString());
+  const newArnFormat = FeatureFlags.of(featureConstruct).isEnabled(ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME);


Why did you create a new construct to check the feature flags on here? Shouldn't it be possible to just do this?

Suggested change

const newArnFormat = FeatureFlags.of(featureConstruct).isEnabled(ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME);

const newArnFormat = FeatureFlags.of(scope).isEnabled(ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME);

I tried FeatureFlags.of(scope) first because it should be the preferred solution. Unfortunately, it causes this error:

Argument of type 'import("/Users/julian/dev/aws-cdk/node_modules/constructs/lib/construct").Construct' is not assignable to parameter of type 'import("/Users/julian/dev/aws-cdk/packages/@aws-cdk/core/lib/construct-compat").Construct'. Type 'Construct' is missing the following properties from type 'Construct': node, validate, prepare, synthesizets(2345)

Since FeatureFlags expects a Construct from the core library, I think we can just switch to using that one in the fromServiceAttributes() function. I pushed this change to your branch, waiting for the build to see if this has other impacts.

packages/@aws-cdk/cx-api/lib/features.ts

madeline-k · 2021-12-23T21:51:28Z

packages/@aws-cdk/aws-ecs/lib/ec2/ec2-service.ts

+        if (Token.isUnresolved(ec2ServiceArn)) {
+          if (FeatureFlags.of(this).isEnabled(ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME)) {
+            const components = Fn.split(':', ec2ServiceArn);
+            const lastComponents = Fn.split('/', Fn.select(5, components));
+            this.serviceName = Fn.select(2, lastComponents);
+          } else {
+            this.serviceName = resourceName;
+          }


This logic is repeated (or at least extremely similar) here, in fargate-service.ts and in from-service-attributes.ts. We should factor this out to one place. It could probably be shared from from-service-attributes.ts.

I moved the code to a new function extractServiceNameFromArn in from-service-attributes.ts.

madeline-k · 2021-12-23T21:52:01Z

packages/@aws-cdk/aws-ecs/lib/ec2/ec2-service.ts

+          const resourceNameSplit = resourceName.split('/');
+          this.serviceName = resourceNameSplit.length === 1 ? resourceName : resourceNameSplit[1];


This should be factored out to one place as well.

I moved the code to a new function extractServiceNameFromArn in from-service-attributes.ts.

madeline-k · 2021-12-23T21:53:04Z

packages/@aws-cdk/aws-ecs/lib/ec2/ec2-service.ts

    }
-    return new Import(scope, id);
+    return new Import();


I might be missing something here, but I don't understand this. Can you explain why is this changing?

Previously, passing the parameters was necessary because they were passed to the super class. The new implementation contains a constructor. In this case, the super() call has to be implemented in the constructor. Therefore, the parameters are not necessary anymore.

If you prefer the existing code (return new Import(scope, id);), I could implement it too. For example:

constructor(importScope: Construct, importId: string) { super(importScope, importId); // ... } } return new Import(scope, id);

However, we have to use new attribute names. If I use scope instead of importScope, the following error is displayed:'scope' is already declared in the upper scope.eslint@typescript-eslint/no-shadow.

Which option do you prefer?

No constructor is used anymore --> done.

madeline-k · 2021-12-23T22:02:53Z

packages/@aws-cdk/aws-ecs/test/ec2/ec2-service.test.ts

+            'Fn::Select': [
+              1,
+              {
+                'Fn::Split': [
+                  '/',
+                  {
+                    'Fn::Select': [
+                      5,
+                      {
+                        'Fn::Split': [
+                          ':',
+                          { Ref: 'ARN' },
+                        ],
+                      },
+                    ],


Oof, this is very hard to determine if this is correct (although I am pretty sure it is). And unfortunately, I don't think there is another way to implement this to make the resulting template more readable.

Should I add integration tests that show the result using CloudFormation Outputs? I tested the changes using this code:

const cluster = new ecs.Cluster(this, 'Cluster', { vpc, }); const param = new CfnParameter(this, 'Param', { default: 'arn:aws:ecs:us-west-2:123456789012:service/my-http-service', }) const fromFargateServiceArn = ecs.FargateService.fromFargateServiceArn(this, 'fromFargateServiceArn', param.valueAsString); new CfnOutput(this, 'fromFargateServiceArnOutput', { value: fromFargateServiceArn.serviceName, }); const fromEc2ServiceArn = ecs.Ec2Service.fromEc2ServiceArn(this, 'fromEc2ServiceArn', param.valueAsString); new CfnOutput(this, 'fromEc2ServiceArnOutPut', { value: fromEc2ServiceArn.serviceName, }); const fromEc2ServiceAttributes = ecs.Ec2Service.fromEc2ServiceAttributes(this, 'fromEc2ServiceAttributes', { cluster, serviceArn: param.valueAsString, }); new CfnOutput(this, 'fromEc2ServiceAttributesOutput', { value: fromEc2ServiceAttributes.serviceName, }); const fromFargateServiceAttributes = ecs.FargateService.fromFargateServiceAttributes(this, 'fromFargateServiceAttributes', { cluster, serviceArn: param.valueAsString, }); new CfnOutput(this, 'fromFargateServiceAttributesOutput', { value: fromFargateServiceAttributes.serviceName, });

New ARN Format and feature flag enabled (CfnParameter: arn:aws:ecs:us-west-2:123456789012:service/cluster-name/my-http-service) - Output:

MyStack.fromEc2ServiceArnOutPut = my-http-service MyStack.fromEc2ServiceAttributesOutput = my-http-service MyStack.fromFargateServiceArnOutput = my-http-service MyStack.fromFargateServiceAttributesOutput = my-http-service

Old ARN Format and feature flag disabled (CfnParameter: arn:aws:ecs:us-west-2:123456789012:service/my-http-service) - Output:

MyStack.fromEc2ServiceArnOutPut = my-http-service MyStack.fromEc2ServiceAttributesOutput = my-http-service MyStack.fromFargateServiceArnOutput = my-http-service MyStack.fromFargateServiceAttributesOutput = my-http-service

tobytipton · 2021-12-24T00:25:59Z

Implementing this as a feature flag impacts both existing and new services. The use case would be if you have an service which was created with the old Arn format and are extending your CDK to create a addition new ECS service which would use the new Arn format. The feature flag would need to be set for the new ECS service with the new Arn Format. But it would impact the existing service as well.

Maybe a property would be more desirable?

Pull request has been modified.

jumic · 2021-12-27T16:54:33Z

Implementing this as a feature flag impacts both existing and new services. The use case would be if you have an service which was created with the old Arn format and are extending your CDK to create a addition new ECS service which would use the new Arn format. The feature flag would need to be set for the new ECS service with the new Arn Format. But it would impact the existing service as well.

Maybe a property would be more desirable?

You're right. The solution in this PR doesn't provide an option to use the new and the old format in a single stack at the same time. I also proposed a new property in my original comment.

@tobytipton Do you have the requirement to mix the old and the new format in a single stack for tokenized ARNs? In this case, we could think about implementing a property. If there is no requirement, I wouldn't support this because we don't know if somebody will ever use it.

In any case, the feature flag should be implemented. This simplifies the use of the method, since the newFormat property does not have to be defined every time in new stacks.

tobytipton · 2022-01-03T16:03:07Z

Implementing this as a feature flag impacts both existing and new services. The use case would be if you have an service which was created with the old Arn format and are extending your CDK to create a addition new ECS service which would use the new Arn format. The feature flag would need to be set for the new ECS service with the new Arn Format. But it would impact the existing service as well.
Maybe a property would be more desirable?

You're right. The solution in this PR doesn't provide an option to use the new and the old format in a single stack at the same time. I also proposed a new property in my original comment.

@tobytipton Do you have the requirement to mix the old and the new format in a single stack for tokenized ARNs? In this case, we could think about implementing a property. If there is no requirement, I wouldn't support this because we don't know if somebody will ever use it.

In any case, the feature flag should be implemented. This simplifies the use of the method, since the newFormat property does not have to be defined every time in new stacks.

The current code for creating the code which would be generating the tokenized ARN has the clusterName and the physicalName in the ARN, which means the token would in theory be the new format. That has issues as well though, I have created #18246 for that.

Here is the scenario I can think of for having new and old formats in the token.
Prior to the change of the ARN format Sept 2020 a ECS/Fargate service is generated using CDK, that would have the old ARN format.
Today (after the new ARN format is the default) I want to add an additional ECS/Fargate service to the same stack or application which adds on to the original CDK, that new service would have the new ARN format.

I see in your tests you are having the token coming from a CFN parameter, but still you could have a new and old format at the same time.

So possibly there does need to be both a feature flag and a property?

jumic · 2022-01-11T19:06:53Z

Here is the scenario I can think of for having new and old formats in the token. Prior to the change of the ARN format Sept 2020 a ECS/Fargate service is generated using CDK, that would have the old ARN format. Today (after the new ARN format is the default) I want to add an additional ECS/Fargate service to the same stack or application which adds on to the original CDK, that new service would have the new ARN format.

I see in your tests you are having the token coming from a CFN parameter, but still you could have a new and old format at the same time.

So possibly there does need to be both a feature flag and a property?

I totally agree. In this case, we need both. A property and a feature flag.

@madeline-k Should I add a property to support parsing the old and the new format from a tokenized ARN in a single stack?
So far I haven't seen a feature request / bug report that requests this functionality. So I'm not sure we should really add this feature. Of course we can add it later if requested.

madeline-k · 2022-01-25T00:55:19Z

Hey @tobytipton and @jumic, thanks for working on this issue! There is currently some overlap between this PR and #18382.

What I'm thinking is this PR should fix the issues with ecs.Fargate/Ec2Service.fromXXX() producing an IService with the wrong values for serviceArn and serviceName. And #18382 should address only that the tokenized ARN for a newly created service does not have region/account info. This means that this PR will need to cover some of the test cases that @tobytipton included in #18382. Let me know if that makes sense!

madeline-k · 2022-01-25T00:57:01Z

@jumic, regarding:

@madeline-k Should I add a property to support parsing the old and the new format from a tokenized ARN in a single stack? So far I haven't seen a feature request / bug report that requests this functionality. So I'm not sure we should really add this feature. Of course we can add it later if requested.

I'd say if this is something that we can support later, and this implementation is not going to be closing a door to that, then we should no implement the property in this PR, and keep the scope smaller.

jumic · 2022-01-25T18:15:43Z

@madeline-k Yes, this makes totally sense. Keeping the pull requests small was also my original idee when I asked to create a separate issue for the region/account topic.

I'd say if this is something that we can support later, and this implementation is not going to be closing a door to that, then we should no implement the property in this PR, and keep the scope smaller.

We can add this feature later if it will be requested. The current logic must not be changed. Therefore, we are free to add it later if necessary.

…ries should be using Construct from core

madeline-k

Thanks for making this contribution @jumic! Sorry for the delay in getting back to reviewing this. To summarize what has already been said on this thread: this change will use the new ARN format when the ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME feature flag is enabled. Since feature flags operate at the stack level, this means the old and new ARN formats cannot both be used in a single stack. If there is a need to be able to use both the old and new ARN format in a single stack, then we can open an issue for that and add a property to control the ARN format at the construct level.

The last change that is needed here is an update to the README to explain the feature flag, and explain the restriction about not being able to use the old and new formats within one stack. @jumic, if you are able to include that that would be great!

This change is motivated by #18140, where we are running into trouble because the current scope is a `constructs.Construct` but `FeatureFlags.of` required a `core.construct`. ---- ### All Submissions: * [ ] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [ ] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/master/INTEGRATION_TESTS.md)? * [ ] Did you use `cdk-integ` to deploy the infrastructure and generate the snapshot (i.e. `cdk-integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Pull request has been modified.

TheRealAmazonKendra · 2022-06-15T15:35:26Z

@jumic I tried to do some quick fixes because of the branch change but there are still some test failures to look at. Could you please take a look at those?

…s-new-arn-format

jumic · 2022-06-30T20:52:46Z

@TheRealAmazonKendra I analyzed the test failures. The test are not executed correctly because there is an issue with the feature flag logic in CDK v2. I opened issue #20890. I will check this PR again after the issue is resolved.

TheRealAmazonKendra · 2022-07-05T15:39:01Z

Ah, the feature flag issue strikes again. I'm actually working on this issue. In the meantime, the tests can still be done by manually adding the feature flag to the app in the tests instead of using these testing functions. If you feel any urgency about getting this merged, that would be my suggestion as a path forward. Otherwise, I'll update when we have a path forward for the feature flag fix.

TheRealAmazonKendra · 2022-07-06T22:15:43Z

Just in case you don't want to wait on the feature flag changes, here is a model for testing with and without the feature flag enabled https://github.com/aws/aws-cdk/pull/21021/files.

github-actions · 2022-07-21T00:08:40Z

This PR has been in the BUILD FAILING state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.

…s-new-arn-format

jumic · 2022-07-27T21:13:06Z

@TheRealAmazonKendra I added the suggested fix for the current feature flag issue.

TheRealAmazonKendra · 2022-07-28T18:18:20Z

packages/@aws-cdk/aws-ecs/README.md

+
+Since AWS has changed the [ARN format for ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-account-settings.html#ecs-resource-ids), 
+feature flag `@aws-cdk/aws-ecs:arnFormatIncludesClusterName` must be enabled to use the new ARN format.
+The feature flag changes behavior for the entire CDK project. Therefore it is not possible to mix the old and the new format in one CDK project.


This is not strictly true, but we generally recommend to not do this inline and have zero (I think?) instructions on how to do it so I don't think I mind this note here.

mergify · 2022-07-28T18:29:32Z

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

TheRealAmazonKendra · 2022-07-28T18:31:48Z

Thanks for all your effort on this and for bearing with us on the feature flag issues! Glad we could get this one merged!

aws-cdk-automation · 2022-07-28T19:06:29Z

AWS CodeBuild CI Report

CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
Commit ID: f88e7fb
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

mergify · 2022-07-28T19:06:42Z

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

AWS has changed the [ARN format for ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-account-settings.html#ecs-resource-ids). Currently, CDK doesn't return the correct values/ARNs if the new ARN format is used in ECS. Changed methods: - `Ec2Service.fromEc2ServiceAttributes()` - `Ec2Service.fromEc2ServiceArn()` - `FargateService.fromFargateServiceAttributes()` - `FargateService.fromFargateServiceArn()` The logic automatically detects whether the old or new format is used. The format cannot be recognized automatically for tokenized values. Therefore the feature flag `ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME` is introduced, which controls whether the old or the new format should be used. In `Ec2Service.fromEc2ServiceAttributes()` and `FargateService.fromFargateServiceAttributes()` an ARN is created. In these methods the feature flag be considered to construct the ARN in the correct format. Closes aws#16634. Closes aws#18137. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license* cr: https://code.amazon.com/reviews/CR-73367009

AWS has changed the [ARN format for ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-account-settings.html#ecs-resource-ids). Currently, CDK doesn't return the correct values/ARNs if the new ARN format is used in ECS. Changed methods: - `Ec2Service.fromEc2ServiceAttributes()` - `Ec2Service.fromEc2ServiceArn()` - `FargateService.fromFargateServiceAttributes()` - `FargateService.fromFargateServiceArn()` The logic automatically detects whether the old or new format is used. The format cannot be recognized automatically for tokenized values. Therefore the feature flag `ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME` is introduced, which controls whether the old or the new format should be used. In `Ec2Service.fromEc2ServiceAttributes()` and `FargateService.fromFargateServiceAttributes()` an ARN is created. In these methods the feature flag be considered to construct the ARN in the correct format. Closes aws#16634. Closes aws#18137. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

fix(ecs): new ARN format not recognized

3223be3

github-actions bot assigned madeline-k Dec 22, 2021

github-actions bot added the @aws-cdk/aws-ecs Related to Amazon Elastic Container label Dec 22, 2021

madeline-k previously requested changes Dec 23, 2021

View reviewed changes

refactor duplicate code, add URL

f5a3560

jumic requested a review from madeline-k December 27, 2021 16:54

refactor from*ServiceArn methods

b5c9bf5

tobytipton mentioned this pull request Jan 12, 2022

chore(codepipeline): add example of an ECS Deploy Action #18059

Closed

madeline-k mentioned this pull request Jan 25, 2022

fix(ecs): fix serviceArn token to have region/account in serviceArn #18382

Closed

Merge branch 'master' into ecs-new-arn-format

a534380

rix0rrr added bug This issue is a bug. p1 and removed @aws-cdk/aws-ecs Related to Amazon Elastic Container labels Mar 4, 2022

madeline-k added 2 commits March 24, 2022 17:01

Merge branch 'master' into ecs-new-arn-format

dc8bcff

switch fromServiceAttributes to use Construct from core. All v1 libra…

30546e6

…ries should be using Construct from core

madeline-k previously requested changes Mar 25, 2022

View reviewed changes

madeline-k changed the title ~~fix(ecs): new ARN format not recognized (under feature flag)~~ feat(ecs): Support new ARN format for ECS services (under feature flag) Mar 25, 2022

github-actions bot added the @aws-cdk/aws-ecs Related to Amazon Elastic Container label Mar 25, 2022

madeline-k changed the title ~~feat(ecs): Support new ARN format for ECS services (under feature flag)~~ fix(ecs): New ARN format for ECS services not supported (under feature flag) Mar 25, 2022

madeline-k mentioned this pull request Mar 25, 2022

chore(core): change FeatureFlags to use constructs.IConstruct #19567

Merged

4 tasks

github-actions bot added the effort/medium Medium work item – several days of effort label Jun 13, 2022

Merge branch 'main' into ecs-new-arn-format

dd295d8

TheRealAmazonKendra previously approved these changes Jun 13, 2022

View reviewed changes

fix typo

92136f2

typo fix

4db80e2

jumic added 3 commits June 21, 2022 21:45

Merge branch 'main' into ecs-new-arn-format

66b087f

Merge branch 'main' into ecs-new-arn-format

c3097a7

Merge branch 'ecs-new-arn-format' of github.com:jumic/aws-cdk into ec…

afe21d9

…s-new-arn-format

jumic mentioned this pull request Jun 27, 2022

cdk-build-tools: testFutureBehavior/testLegacyBehavior outdated for CDK v2 #20890

Open

jumic added 3 commits July 25, 2022 20:04

Merge branch 'main' into ecs-new-arn-format

9caa1a5

Merge branch 'ecs-new-arn-format' of github.com:jumic/aws-cdk into ec…

a22ef04

…s-new-arn-format

feature flag issue workaround

764d034

jumic requested a review from TheRealAmazonKendra July 27, 2022 21:13

TheRealAmazonKendra changed the title ~~fix(ecs): New ARN format for ECS services not supported (under feature flag)~~ fix(ecs): new arn format not supported (under feature flag) Jul 28, 2022

TheRealAmazonKendra approved these changes Jul 28, 2022

View reviewed changes

Merge branch 'main' into ecs-new-arn-format

f88e7fb

mergify bot merged commit 9749a57 into aws:main Jul 28, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(ecs): new arn format not supported (under feature flag) #18140

fix(ecs): new arn format not supported (under feature flag) #18140

jumic commented Dec 22, 2021

gitpod-io bot commented Dec 22, 2021

madeline-k left a comment

madeline-k Dec 23, 2021

jumic Dec 23, 2021

madeline-k Mar 25, 2022

madeline-k Dec 23, 2021

jumic Dec 27, 2021

madeline-k Dec 23, 2021

jumic Dec 27, 2021

madeline-k Dec 23, 2021

jumic Dec 23, 2021

jumic Dec 27, 2021

madeline-k Dec 23, 2021

jumic Dec 27, 2021

tobytipton commented Dec 24, 2021

jumic commented Dec 27, 2021

tobytipton commented Jan 3, 2022

jumic commented Jan 11, 2022

madeline-k commented Jan 25, 2022

madeline-k commented Jan 25, 2022

jumic commented Jan 25, 2022

madeline-k left a comment

TheRealAmazonKendra commented Jun 15, 2022

jumic commented Jun 30, 2022

TheRealAmazonKendra commented Jul 5, 2022

TheRealAmazonKendra commented Jul 6, 2022

github-actions bot commented Jul 21, 2022

jumic commented Jul 27, 2022

TheRealAmazonKendra Jul 28, 2022

mergify bot commented Jul 28, 2022

TheRealAmazonKendra commented Jul 28, 2022

aws-cdk-automation commented Jul 28, 2022

mergify bot commented Jul 28, 2022

	const newArnFormat = FeatureFlags.of(featureConstruct).isEnabled(ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME);
	const newArnFormat = FeatureFlags.of(scope).isEnabled(ECS_ARN_FORMAT_INCLUDES_CLUSTER_NAME);

		const resourceNameSplit = resourceName.split('/');
		this.serviceName = resourceNameSplit.length === 1 ? resourceName : resourceNameSplit[1];

fix(ecs): new arn format not supported (under feature flag) #18140

fix(ecs): new arn format not supported (under feature flag) #18140

Conversation

jumic commented Dec 22, 2021

gitpod-io bot commented Dec 22, 2021

madeline-k left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobytipton commented Dec 24, 2021

jumic commented Dec 27, 2021

tobytipton commented Jan 3, 2022

jumic commented Jan 11, 2022

madeline-k commented Jan 25, 2022

madeline-k commented Jan 25, 2022

jumic commented Jan 25, 2022

madeline-k left a comment

Choose a reason for hiding this comment

TheRealAmazonKendra commented Jun 15, 2022

jumic commented Jun 30, 2022

TheRealAmazonKendra commented Jul 5, 2022

TheRealAmazonKendra commented Jul 6, 2022

github-actions bot commented Jul 21, 2022

jumic commented Jul 27, 2022

Choose a reason for hiding this comment

mergify bot commented Jul 28, 2022

TheRealAmazonKendra commented Jul 28, 2022

aws-cdk-automation commented Jul 28, 2022

AWS CodeBuild CI Report

mergify bot commented Jul 28, 2022