chore(release): 2.94.0 #26975
Merged
chore(release): 2.94.0 #26975
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hi, I found some badges in README.md outdated, fixing them in this PR. [Rendered version](https://github.com/tmokmss/aws-cdk/blob/update_readme_badges/README.md) From:  To:  ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Closes #[25951](#25951) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Add mikewrighton to github-merit-badger.yml as part of onboarding. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…26675) According to the AWS documentation, the TrainingInputMode for a SageMaker Training Job can be one of the following: `Pipe | File | FastFile` https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_Channel.html#sagemaker-Type-Channel-InputMode https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AlgorithmSpecification.html#API_AlgorithmSpecification_Contents I have just added `FastFile` below to align with the official documentation. https://github.com/aws/aws-cdk/blob/v2.90.0/packages/aws-cdk-lib/aws-stepfunctions-tasks/lib/sagemaker/base-types.ts#L458 Closes #26653. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s for HelmChart construct (#26852) > This change was made to improve convenience when working with the HelmChart construct. > For example this allows for simpler creation of aspects for inspecting helm charts as mentioned in #26678 . Closes #26678. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Add author mikewrighton to .mergify.yml. Co-authored-by: Mike Wrighton <[email protected]> Co-authored-by: Kaizen Conroy <[email protected]> Co-authored-by: Colin Francis <[email protected]>
Update constants/doc for ADOT Lambda Layer Reference PR - #26793 **NOTE** This PR requires an update to an integration test and am unable to run the `cdk-integ` tool to perform a real deployment ---- *By submitting this pull request, I confirm that I make my contribution under the terms of the Apache-2.0 license*
) The LogRetention Custom Resource used to be able to handle server-side throttling, when a lot of requests to the CloudWatch Logs service are made at the same time. Handling of this error case got lost during the migration to SDK v3. If we have (read: a lot) `LogRetention` Custom Resources in a _single_ Stack, CloudFormation apparently applies some internal breaks to the amount of parallelism. For example it appears that resources are batched in smaller groups that need to be completed before the next group is provisioned. And within the groups there appears to be a ever so slight delay between individual resources. Together this is enough to avoid rate limiting in most circumstances. **Therefore, in practice this issues only occurs when multiple stacks are deployed in parallel.** To test this scenario, I have added support for `integ-runner` to deploy all stacks of a test case concurrently. Support for arbitrary command args already existed, but needed to explicitly include the `concurrency` option. I then create an integration test that deploys 3 stacks à 25 LogRetention resources. This triggers the error cases described in #26837. The fix itself is twofold: - Pass the `maxRetries` prop value to the SDK client to increase the number of attempts of the SDK internal throttling handling. But also enforce a minimum for these retries since they might catch additional retryable failures that our custom outer loop does not account for. - Explicitly catch `ThrottlingException` errors in the outer retry loop. Closes #26837 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
**Code Changes:** - Refactoring the fact-tables.ts file to make the entire file to be set alphabetically. - Helps while adding new region, looking up values for already set regions and avoid duplication. Closes #26826. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Pull request to implement RealtimeLogConfig on CloudFront Distribution. As well as being able to use `RealtimeLogConfigArn` on `Distribution`, I also added `RealtimeLogConfig` as a Construct so that the Cfn is abstracted too. The reason this is needed so that we can add realtime log config to a `Distribution` without reverting to using `CfnDistribution`. Closes #<issue number here>. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Closes #23153 - Support SnapStart on L2 constructs by setting `snapStart: lambda.SnapStartConfig.ON_PUBLISHED_VERSIONS`. This value will be converted to `SnapStart: {ApplyOn: 'PublishedVersions',}` in template. - Supports checking limitation stated in [SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html) except for Provisioned Concurrency which is at version level and can't be checked with function level props. - This PR is heavily inspired by [PR](#23196) from @DeerajTheepshi and [discussion](#23153 (comment)) in the issue, Thank you ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Two changes to the `jest` tests: - We are currently running the tests directly from `.ts` source files using `ts-jest`. Disable type checking (by setting `isolatedModules: true`) to improve the speed. This brings down running 4 test suites from an arbitrary service (`aws-servicecatalog`) down from `79s` to `19s` on my machine. - Change the "coverage ignore files" a little to get rid of the "Note: The code generator has deoptimised the styling" errors produced by jest when it wants to read the coverage of the generated source files. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…6880) > Describe the reason for this change, what the solution is, and any CFN recently added support for a new [deletion policy called RetainExceptOnCreate](https://aws.amazon.com/about-aws/whats-new/2023/07/aws-cloudformation-deletion-policies-dev-test-cycle/). This policy was added to the removal-policy enum in [e0d5ca](e0d5cad), however it is missing from the [switch/case block in parseDeletionPolicy](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/core/lib/helpers-internal/cfn-parse.ts#L468), which causes errors when this removal policy is used. Closes #26863. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
## Problem
ECS hotswap fails on a task definition containing log configuration like the following.
```ts
const taskDefinition = new ecs.FargateTaskDefinition(stack, 'Task', {});
taskDefinition.addContainer('EcsApp', {
image: ecs.ContainerImage.fromRegistry('nginx:stable'),
logging: ecs.LogDriver.awsLogs({ streamPrefix: 'log' }),
});
```
## Root cause
When we transform object keys in a task definition, we pass `excludeFromTransform` to avoid from transforming keys with arbitrary string, such as [`logDriver.options`](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html#ECS-Type-LogConfiguration-options).
However, it was not working when we transform keys with upperCaseFirstCharacter, because the keys in `excludeFromTransform` was uppercased, where the source object was lowercased.
```
// source task definition
{
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "my-test-stack-TaskEcsAppLogGroupD5C9C1DD-BPB6zgX4S0wU",
"awslogs-region": "ap-northeast-1",
},
},
}
// excludeFromTransform
{
LogConfiguration: {
Options: true,
},
},
}
// where it should be
{
logConfiguration: {
options: true,
},
},
}
```
This misconfiguration resulted in the output task definition uppercased in an unexpected way:
```json
{
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"Awslogs-group": "my-test-stack-TaskEcsAppLogGroupD5C9C1DD-BPB6zgX4S0wU",
"Awslogs-region": "ap-northeast-1",
},
},
}
```
The problem was not detected by unit tests because they only contained cases with uppercase keys in a source task definition.
## Fix
Use lowercased `excludeFromTransform` when we use it with `upperCaseFirstCharacter`, also adding a test case with lowercased keys in a source task definition.
Closes #26871.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
For people working over SSH, that can't comfortably look at `coverage/index.html`, generate `coverage/coverage.txt` instead. Closes #26078 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…hon 3.7 which is EOL (#26884) Update `SecretRotationApplication` versions to `1.1.367` - the latest available in the Serverless Application Repository. This will bump the deployed lambdas from Python 3.7 (which is EOL) to Python 3.9 (which is still within security support). Closes #26866. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
In #24024, we added the ability to specify Docker cache flags during ecr-asset builds. However, it was not added to the `DockerImage` class. This PR adds the ability to specify the `--cache-from` and `--cache-to` flag to `DockerImage` builds. This logic was primarily lifted directly from #24024. Fixup of issues from #25925 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…vided (#26886) In #19796 we added additional validation to sns subscription. For that purpose the Queue `encryptionType` was exposed as a public property. However the PR forgot to take into account that the provided `encryption` property is automatically changed when a `encryptionMasterKey` is provided. This PR ensures that the public `encryptionType` has the correct value. Additionally, adds a warning for an incorrect configuration scenario where `encryptionMasterKey` is provided together with an `encryption` other than QueueEncryption.KMS. This feature was supposed to allow users to simply provide an encryption key and have the encryption type being selected automatically. However it now unintentionally allows for wrong configurations that are silently fixed, e.g. setting QueueEncryption.UNENCRYPTED and providing an encryption key. The warning keeps backwards compatibility, but instructs users to fix their configuration. Closes #26719 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ceiveMessageWaitTime (#26882) Currently, the document for aws_lambda_event_sources module includes the following description. https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_lambda_event_sources-readme.html#sqs > receiveMessageWaitTime: Will determine long poll duration. The default value is 20 seconds. However, from SQS perspective, the default value is 0. So, the above description is incorrect. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html > ReceiveMessageWaitTimeSeconds – The length of time, in seconds, for which a ReceiveMessage action waits for a message to arrive. Valid values: An integer from 0 to 20 (seconds). Default: 0. Also, when we use SQS queue as Lambda's source, Lambda uses long polling regardless of the queue's ReceiveMessageWaitTimeSeconds setting. https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-scaling > For standard queues, Lambda uses long polling to poll a queue until it becomes active. So, in this context, `receiveMessageWaitTime` prop for Queue construct does not affect the behavior of Lambda EventSource. To avoid confusion, this PR remove the description regarding `receiveMessageWaitTime` from document. Closes #24795 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
### Problem: The Amplify App L2 construct does not support the ability for customers to configure a SSR app without reaching down into the lower level L1. ### Solution: Expose the `platform` field used to set SSG vs SSR hosted applications. Do not expose `WEB_DYNAMIC` as SSRv1 is on the deprecation path. ### Testing Done: * `yarn build+test` * added new tests for `platform` field * updated snapshots for new default value Closes #24076 and #23325 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…dZone anymore (#26888) `Identity.publicHostedZone` takes an `IPublicHostedZone`, but because of TypeScript structural typing it would also accept an `IHostedZone`. When in [this PR](#26333) the `grantDelegation` method was added to the `IPublicHostedZone` interface, this passing was no longer allowed and code that used to work on accident, no longer works. For example: ``` const zone = HostedZone.fromHostedZoneId(stack, 'Zone', 'hosted-id'); const sesIdentity = ses.Identity.publicHostedZone(zone); ``` It raises an error because the imported `zone` does not implement the `grantDelegation` method. This fix moves the `grantDelegation` method declaration into the `IHostedZone` interface and makes it available to all imported zones. Closes #26872. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sagemaker integration for ApiGateway. Pulled the IEndpoint from the alpha module. Stabilizes `sagemaker.IEndpoint` from `aws-sagemaker-alpha` so that it can be used in the integration. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Closes #26707. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ts (#26885) To move the assets into the target bucket, a `BucketDeployment` was created for every `ProductStack`. Instead, we will now share the same `BucketDeployment` for all `ProductStacks`. This moves the custom resource around in the construct tree (leading to replacement), but that is a safe operation. Nothing will be destroyed by this move. Closes #25189. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This PR contains implementation for Schedule Targets: 1. Creates a separate module for targets 2. Support imported resources, but not cross account, cross region resources as we discussed in RFC. The unit tests should cover 4 cases (target and role within the same stack, target is imported, role is imported, target and role are imported), 3. I have moved out class `Schedule` from private package to depend on it in `schedule-targets` unit tests. Implementation is based on RFC: https://github.com/aws/aws-cdk-rfcs/blob/master/text/0474-event-bridge-scheduler-l2.md Advances #23394 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
… newer runtimes (#26903) >Hello, > >We are contacting you as we have identified that your AWS Account currently has one or more Lambda functions using the Node.js 14 runtime. > >We are ending support for Node.js 14 in AWS Lambda. This follows Node.js 14 End-Of-Life (EOL) reached on April 30, 2023 [1]. > >As described in the Lambda runtime support policy [2], end of support for language runtimes in Lambda happens in two stages. Starting November 27, 2023, Lambda will no longer apply security patches and other updates to the Node.js 14 runtime used by Lambda functions, and functions using Node.js 14 will no longer be eligible for technical support. In addition, you will no longer be able to create new Lambda functions using the Node.js 14 runtime. Starting January 25, 2024, you will no longer be able to update existing functions using the Node.js 14 runtime. > >We recommend that you upgrade your existing Node.js 14 functions to Node.js 18 before November 27, 2023. > >End of support does not impact function execution. Your functions will continue to run. However, they will be running on an unsupported runtime which is no longer maintained or patched by the AWS Lambda team. > >This notification is generated for functions using the Node.js 14 runtime for the $LATEST function version. For a list of your affected Lambda functions, please see the 'Affected resources" tab of your AWS Health Dashboard > >The following command shows how to use the AWS CLI [3] to list all functions in a specific region using Node.js 14, including published function versions. To find all such functions in your account, repeat this command for each region: > >aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='nodejs14.x'].FunctionArn" > >If you have any concerns or require further assistance, please contact AWS Support [4]. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
… PROVIDED_AL2 (#26904) `We recommend that you upgrade your existing Custom Runtime based on Amazon Linux 1 functions to Custom Runtime based on Amazon Linux 2 ('provided.al2') before December 31, 2023.` >Hello, > >We are contacting you as we have identified that your AWS Account currently has one or more Lambda functions using Custom Runtime based on Amazon Linux 1 ('provided') runtime. > >We are ending support for Custom Runtime based on Amazon Linux 1 in AWS Lambda, in line with Amazon Linux AMI end of maintenance support on December 31, 2023 [1]. > >As described in the Lambda runtime support policy [2], end of support for language runtimes in Lambda happens in two stages. Starting December 31, 2023, Lambda will no longer apply security patches and other updates to the Custom Runtime based on Amazon Linux 1 runtime used by Lambda functions, and functions using Custom Runtime based on Amazon Linux 1 will no longer be eligible for technical support. In addition, you will no longer be able to create new Lambda functions using the Custom Runtime based on Amazon Linux 1 runtime. Starting January 30, 2024, you will no longer be able to update existing functions using the Custom Runtime based on Amazon Linux 1 runtime. > >We recommend that you upgrade your existing Custom Runtime based on Amazon Linux 1 functions to Custom Runtime based on Amazon Linux 2 ('provided.al2') before December 31, 2023. > >End of support does not impact function execution. Your functions will continue to run. However, they will be running on an unsupported runtime which is no longer maintained or patched by the AWS Lambda team. > >This notification is generated for functions using the Custom Runtime based on Amazon Linux 1 for the $LATEST function version. A list of affected resources can be found in the 'Affected resources' tab of your AWS Health Dashboard. The following command shows how to use the AWS CLI [3] to list all functions in a specific region using Custom Runtime based on Amazon Linux 1, including published function versions. To find all such functions in your account, repeat this command for each region: > >aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='provided'].FunctionArn" > >If you have any concerns or require further assistance, please contact AWS Support [4]. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ROVIDED_AL2 runtime (#26899) Lambda runtime `GO_1_X` will cease to receive support on Dec,31 2023. Uee `PROVIDED_AL2` runtime instead. > Hello, > > We are contacting you as we have identified that your AWS Account currently has one or more Lambda functions using the Go 1.x runtime. > > We are ending support for the Go 1.x runtime in AWS Lambda, in line with Amazon Linux AMI end of maintenance support on December 31, 2023 [1]. Lambda continues to support the Go programming language, using the provided.al2 runtime. Using the provided.al2 runtime offers several benefits over the go1.x runtime, including support for AWS Graviton2 processors and a streamlined implementation with a smaller deployment package and faster function invoke path. For more information, see our blog post [2]. > > As described in the Lambda runtime support policy [3], end of support for language runtimes in Lambda happens in two stages. Starting December 31, 2023, Lambda will no longer apply security patches and other updates to the Go 1.x runtime used by Lambda functions, and functions using Go 1.x will no longer be eligible for technical support. In addition, you will no longer be able to create new Lambda functions using the Go 1.x runtime. Starting January 30, 2024, you will no longer be able to update existing functions using the Go 1.x runtime. > > We recommend that you upgrade your existing Go 1.x functions to the provided.al2 runtime before December 31, 2023. > > End of support does not impact function execution. Your functions will continue to run. However, they will be running on an unsupported runtime which is no longer maintained or patched by the AWS Lambda team. > > This notification is generated for functions using the Go 1.x runtime for the $LATEST function version. A list of your impacted Lambda functions can be found in the 'Affected resources' tab of your Personal Health Dashboard. The following command shows how to use the AWS CLI [4] to list all functions in a specific region using Go 1.x, including published function versions. To find all such functions in your account, repeat this command for each region: > > aws lambda list-functions --function-version ALL --region us-east-1 --output text --query "Functions[?Runtime=='go1.x'].FunctionArn" > > There is a difference in Lambda billing between the go1.x runtime and the provided.al2 runtime. With the go1.x runtime, Lambda does not bill for time spent during function initialization (cold start), whereas with the provided.al2 runtime Lambda includes function initialization time in the billed function duration. Since Go functions typically initialize very quickly, and since Lambda reduces the number of initializations by re-using function execution environments for multiple function invokes, in practice the difference in your Lambda bill should be very small. > > If you have any concerns or require further assistance, please contact AWS Support [5]. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Add support for [AppSync Merged API](https://aws.amazon.com/blogs/mobile/introducing-merged-apis-on-aws-appsync/) feature. At the moment, a GraphQL schema can be passed using the `schema` property. I deprecated this property because it is not used for merged APIs. Depecreated syntax: ```ts const api = new appsync.GraphqlApi(this, 'Api', { name: 'demo', schema: appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql')), }); ``` Instead, I introduced a new property `apiSource` that can be used to create a AppSync GraphQL API or Merged API. GraphQL API: ```ts const api = new appsync.GraphqlApi(this, 'Api', { name: 'demo', apiSource: appsync.ApiSource.fromSchema(appsync.SchemaFile.fromAsset(path.join(__dirname, 'schema.graphql'))), // short version apiSource: appsync.ApiSource.fromFile(path.join(__dirname, 'schema.graphql')), }); ``` Merged API: ```ts const api = new appsync.GraphqlApi(this, 'Api', { name: 'demo', apiSource: appsync.ApiSource.fromSourceApis({ sourceApis: [ { sourceApi: firstApi, mergeType: appsync.MergeType.MANUAL_MERGE, }, { sourceApi: secondApi, mergeType: appsync.MergeType.AUTO_MERGE, }, ], }), }); ``` Closes #25960. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…26921) Upgrades a few runtime versions from `NODEJS_14_X` (which is EOL and will enter Deprecation Phase 1 on Nov 27, 2023) to `NODEJS_16_X`. Also updates all the tests. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
They execute correctly locally and in a PR build, but not in the Pipeline because the `framework-integ` package gets an `-alpha.999` suffix (whereas the actual constructs get an `-rc.0` suffix). The test used to read the expected version from its own `package.json`. It will now read the expected version from `aws-cdk-lib`'s `package.json`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Ran npm-check-updates and yarn upgrade to keep the `yarn.lock` file up-to-date.
Its deprecation is causing problems for `cdk-nag`, which has a use case for unsuppressible warnings. Undeprecate for now until we come up with a better all-round solution. Relates to #26914. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
I felt it best to keep most of the details in the linked documentation, but I believe this provides a good overview. Closes #21103. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ld counts (#26949) `HealthyThresholdCount` and `UnhealthyThresholdCount` do not need to be the same. In fact, the [docs](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html#health-check-settings) have their default values as 5 and 2. Closes #26941. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s-cdk/aws-lambda-python-alpha/test/lambda-handler-poetry (#26956) Bumps [certifi](https://github.com/certifi/python-certifi) from 2023.5.7 to 2023.7.22. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/certifi/python-certifi/commit/8fb96ed81f71e7097ed11bc4d9b19afd7ea5c909"><code>8fb96ed</code></a> 2023.07.22</li> <li><a href="https://github.com/certifi/python-certifi/commit/afe77220e0eaa722593fc5d294213ff5275d1b40"><code>afe7722</code></a> Bump actions/setup-python from 4.6.1 to 4.7.0 (<a href="https://redirect.github.com/certifi/python-certifi/issues/230">#230</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/2038739ad56abec7aaddfa90ad2ce6b3ed7f5c7b"><code>2038739</code></a> Bump dessant/lock-threads from 3.0.0 to 4.0.1 (<a href="https://redirect.github.com/certifi/python-certifi/issues/229">#229</a>)</li> <li><a href="https://github.com/certifi/python-certifi/commit/44df761f4c09d19f32b3cc09208a739043a5e25b"><code>44df761</code></a> Hash pin Actions and enable dependabot (<a href="https://redirect.github.com/certifi/python-certifi/issues/228">#228</a>)</li> <li>See full diff in <a href="https://github.com/certifi/python-certifi/compare/2023.05.07...2023.07.22">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/aws/aws-cdk/network/alerts). </details>
…26917) Currently, the region parameter in `AwsCustomResource` only controls where the action is performed. If a role needs to be assumed, the `assumeRole` call is made from the region the stack is deployed into. This presents a problem if the stack is deployed into an opt-in region, and the role being assumed lives in a separate stack in an account without the opt-in region enabled. This change makes the `assumeRole` call and the sdk call performed in the same region. Therefore, to solve the above problem, pass any region that is enabled for the account that owns the role to be assumed. Closes #26562. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action
This adds the ability to use the latest two NodeJS runtimes in your Synthetics construct. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…nnot be set at once (#26971) This PR adds comments that both defaultInterval and start for dashboard cannot be set at once. The following is a validation code for them. https://github.com/go-to-k/aws-cdk/blob/05d1c524e356f0e3cbd4799c6f7d233a44301954/packages/aws-cdk-lib/aws-cloudwatch/lib/dashboard.ts#L135-L137 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
aws-cdk-automation
added
auto-approve
pr/no-squash
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
aws-cdk-automation
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
vinayak-kukreja
added
the
pr/do-not-merge
Signed-off-by: Vinayak Kukreja <[email protected]>
vinayak-kukreja
had a problem deploying
to
test-pipeline
GitHub Actions
Failure
vinayak-kukreja
removed
the
pr/do-not-merge
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be automatically updated and merged without squashing (do not update manually, and be sure to allow changes to be pushed to your fork). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See CHANGELOG