chore(release): 1.64.0 #10469
Merged
chore(release): 1.64.0 #10469
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
Bumps [node-fetch](https://github.com/bitinn/node-fetch) from 2.6.0 to 2.6.1. - [Release notes](https://github.com/bitinn/node-fetch/releases) - [Changelog](https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md) - [Commits](node-fetch/node-fetch@v2.6.0...v2.6.1) Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Adds the ability to import secrets by name, including without the SecretsManager assigned suffix. As long as a secret with the same name has been created in each region with the same name, this allows for the same `fromSecretName` usage in stacks across regions. Oddly enough, most CloudFormation templates that take references to secrets accept either the full-form ARN, including the suffix or just the base secret name (not in ARN format). The one place where a full ARN format is needed is in IAM policy statements, where the wildcard is necessary to account for the suffix. Tested this manually against an existing secret with a CodeBuild project; per the CloudFormation docs, this should work equally well with other SecretsManager-integrated services. fixes #7444 fixes #7949 fixes #7994
…#10337) `--cloudformation-execution-policies` was always required for bootstrapping to be useful, but it was only checked for presence if you were adding cross-account trust. People keep making mistakes against forgetting it though. As a stopgap until we get a better UX in place, check that the value is present. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
If there are credentials but using them fails, the "default account lookup" that's used to populate the environment variables fails (should have returned `undefined`) and the CLI aborts before the CDK app is synth'ed. Fixes #7849. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This PR will implicitly select correct bottlerocket variant in consist with the cluster k8s version. For example, if the cluster k8s version is `1.17`, previously only bottlerocket `aws-k8s-1.15` variant is available. Now the variant will be `aws-k8s-1.17` BREAKING CHANGE: Clusters previously running k8s version other than `1.15` and bottlerocket AMI(`aws-k8s-1.15` variant) will trigger AMI and node replacement. Closes: #10188 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Add option to supply a custom bundling image. Closes #10194 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s are used (#10339) @eladb While working on this for the `aws-eks-next` module, i've started to second guess whether we really need to force cluster replacement. This little PR fixes all the circular dependency issues as well as corrects the `cluster.connections` to include the EKS managed cluster security group. **It does not require cluster replacement**. Merging this PR will leave two quirks/limitations: - The cluster will have a redundant control plane security group, just like it has now. While redundant, it doesn't hurt, and doesn't really justify a cluster replacement. - One cluster per stack, just like we have now. I think we've already agreed that this limitation also does not justify cluster replacement, and the only reason we wanted to implement it is because we wanted to piggy back on the previous argument, which I now believe is not strong enough. WDYT? -------- This PR resolves a few problem related to circular dependencies when the cluster is configured with security groups from other stacks. ## Problem Currently, the cluster creates a dedicated security group for the `KubectlProvider` and configures the main control plane security group to allow connections from it: https://github.com/aws/aws-cdk/blob/f5c5d060ffee19ac3daa47cbf6df8d3563133433/packages/%40aws-cdk/aws-eks/lib/cluster.ts#L918-L924 This eventually creates ingress rules in the stack of control plane security group. These ingress rules refer to the `KubectlProvider` creates in the cluster stack, hence, a dependency if formed between the control plane security group stack, and the cluster stack. `Control Plane Security Group Stack => Cluster Stack` (Control plane sg needs to allow connections from kubectl sg) On the other hand, the cluster stack naturally depends on the control plane security group stack because the cluster needs the security group when its created. And so: `Cluster Stack => Control Plane Security Group Stack` (Cluster needs the security group) When these two stacks are different, a circular dependency is created. ## Solution Do not create a security group for the `KubectlProvider` at all, and simply re-use the EKS managed security group. This security group is already configured to allow connections to the control plane, so if we simply attach it to the `KubectlProvider`, everything should work. This avoids the creation of the first dependency direction. Fixes #9754 Fixes #10020 Fixes #9536 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
To prevent future errors like #10343, add a linting rule that would have caught that bug. The use of this linting rule requires normalizing code in multiple places, there's no wait to only positively check for one case. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This workflow runs `npm-check-updates` throughout the repository, and runs an equivalent of `yarn install --force` (equivalent to `yarn install && yarn upgrade`, except in a single command so more efficient). Some packages enjoy "special handling": - `@types/node` will stay on the currently set *major* version (since this reflects the minimal supported `node` version) - `@types/fs-extra` will stay on the currently set *major* version (because the latest major version is known to be broken with `@types/node >=10`, as seen in DefinitelyTyped/DefinitelyTyped#30398 - `typescript` will stay on the currently set *minor* version (since it does not follow semantic versioning, and *Major.Minor* is where the stability point is This ensures all dependencies are up-to-date, on the latest version, including transitive dependencies that may not have been updated by the `dependabot` workflows previously. This files a pull request once done if there are any changes. It requires a secret called `AUTOMATION_GITHUB_TOKEN` that will need to be created, and contain a GitHub token that has `workflows` permissions, so PR validation workflows will trigger on the PR.
Change behavior to match the behavior of the AWS CLI. If `--profile` is set, the given profile from the INI files will be used to the exclusion of everything else. If `--profile` is not set, the regular ambient credential process is followed. `AWS_PROFILE` is part of ambient credentials, and setting it does not lead to triggering the new behavior. This is consistent with how the AWS CLI behaves. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Enable users with existing cluster subnet groups to specify the group name, rather than creating a new subnet group. _Note:_ Marked as `exempt-readme` because I don't think this deserves its own README section. Feel free to disagree. fixes #9241 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Closes #10273 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
There is a problem with the `Parameters` property of the `AWS::SSM::Association` resource type.
Server-side, its type is `Map<String, List<String>>`.
Unfortunately, that type is impossible to represent in the current CloudFormation specification that our code generation is based on.
Add a patch that changes the `Parameters` property of `AWS::SSM::Association` to:
```json
"AWS::SSM::Association": {
"Properties": {
"Parameters": {
"Type": "Map",
"ItemType": "List",
"PrimitiveItemItemType": "String",
"UpdateType": "Mutable",
"Required": false
}
}
}
```
That is not a legal CFN spec type.
But we add a new property type, `MapOfListsOfPrimitives`,
to the `cfnspec` module, that represents it.
We then modify our L1 code generation in `cfn2ts` to use the new type,
allowing `CfnAssociationProps.parameters` to have type `{ [key: string]: string[] }`.
Fixes #3092
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Missed passing the new required `--cloudformation-execution-policies` argument in a couple of tests, and ignore the backwards compatibility tests that don't pass it yet. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Support Logout URLs in UserPoolClient. This is a pretty minimal change to just allow the property to be set. fixes: #10225 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Continuation of #8526 This change adds a feature to SubnetSelection which lets the user provide objects that implements the new `ISubnetSelector` interface. These objects will be used by the VPC class to choose the subnets from the VPC. This commit also provides an implementation of an ISubnetSelector that lets the user select subnets that contain IP addresses. *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…10389) The new ClusterSubnetGroup L2 was added to the cluster in #10340. However, adding this resource with an id of `Default` (to preserve backwards compatibility), means that the implicit logic of `this.node.defaultChild` breaks. Flipping the order, so the ClusterSubnetGroup uses `Default` as the logical ID, fixes both issues. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
A few packages were missing the maturity property.
modifying the description to match what we currently use when we create libraries for new services. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…10373) We erroneously assumed Conditions cannot be used in Outputs and Rules, but we forgot that `Fn::If` actually uses the name of a Condition as the first argument. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
In CloudFormation, it's legal to pass as string where a boolean value is expected. Take that into account when performing diffs, and allow that case in `@aws-cdk/cloudformation-include`. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Co-authored-by: Noah Litov <[email protected]>
Automatically retry on Lambda service exceptions for `LambdaInvoke`. Follows the best practice from https://docs.aws.amazon.com/step-functions/latest/dg/bp-lambda-serviceexception.html ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
In PR #10148, @rix0rrr made it possible to provide a custom CodePipeline pipeline instance to CdkPipeline. This also made the `sourceAction` (Source stage) and `synthAction` (Build stage) props optional. However, validation was added to ensure that if `synthAction` is not provided, the pipeline already contains at least two stages (assuming that would be Source and Build). Logically though, CdkPipeline works perfectly fine without Build stage, if an already-built cloud assembly is provided in the source stage (e.g. S3 source action). A use case for this is, for example, separating CI and CD logic, where CDK synthesis happens within the CI build and the assembly is stored as an artefact to be deployed by a pipeline. This PR makes the Build stage optional, to allow this use case without a need for a dummy build stage. Example pipeline code: ```ts export class PipelineStack extends cdk.Stack { constructor(scope: cdk.Construct, id: string, props: cdk.StackProps) { super(scope, id, props); const versionsBucket = new s3.Bucket(this, 'VersionsBucket', { bucketName: 's3pipeline-app-versions', versioned: true, }); // The CodePipeline const cloudAssemblyArtifact = new codepipeline.Artifact() const codePipeline = new codepipeline.Pipeline(this, 'CodePipeline', { pipelineName: 'S3Pipeline', restartExecutionOnUpdate: true, stages: [{ stageName: 'Source', actions: [new actions.S3SourceAction({ actionName: 'S3', bucket: versionsBucket, bucketKey: 'cloudassembly.zip', output: cloudAssemblyArtifact })] }] }); // CDK Pipeline const cdkPipeline = new pipelines.CdkPipeline(this, 'CdkPipeline', { codePipeline, cloudAssemblyArtifact, }); // Add application stage cdkPipeline.addApplicationStage(new MyAppStage(this, "PreProd")); } } ``` ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…source' resource type (#10415) The resource type 'AWS::CloudFormation::CustomResource' corresponds to the class CfnCustomResource. However, that class is automatically generated, and quite useless; it only supports one property, ServiceToken. It does not support passing in an arbitrary collection of properties, like custom resources in CloudFormation do. As a result, cfn-include would "lose" all properties of resources of type 'AWS::CloudFormation::CustomResource' other than ServiceToken. Fix the problem by handling this resource type with the CfnResource class, that does support an arbitrary collection of properties. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…cy when bucket and lambda are in different stacks (#10426) When the bucket and function are in two different stacks, the following stacks are created: ### Bucket Stack - `s3.Bucket` - `s3.BucketNotificationHandler` (creates a dependency on **lambda stack** since it configures the target of the trigger) ### Lambda Stack - `lambda.Function` - `lambda.Permission` (creates a dependency on the **bucket stack** since it configures the lambda to allow invocations from that specific bucket) The solution is to switch up the `lambda.Permission` scope and use the bucket instead of the function, so that it is added to the bucket stack, leaving the lambda stack independent. Fixes #5760 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
- Fixed incorrect comparison operator (LTE) string from '>=' to '<=' - fixes #8913 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…8828) **[ISSUE]** Imported Lambda functions unable to add new resource policy **[APPROACH]** Add a check for imported Lambda Functions between the account id and the account id from imported Lambda Function. If they match, imported function can add permissions. Fixes #7588 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
One of the contributors of longer runtimes, and we definitely don't need stack traces in it. Relates to #10213. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Fix Parcel detection for non JS/TS CDK projects. For those projects the module `@aws-cdk/aws-lambda-nodejs` is not installed in a `node_modules` folder inside the project. Change the detection logic to `require.resolve` from the project root. Also in this fix: ensure that the Parcel version that is run inside the container is the one installed at `/`. Previously, if an incorrect version of Parcel was detected bundling would happen in a container as expected but with the incorrect version because project root is mounted at `/asset-input` and in this case it contains the incorrect Parcel version at `/asset-input/node_modules`. Again change the `require.resolve` paths to avoid this. Addresses #10123 (not sure yet if it closes it) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Closes #10443 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
CloudFormation allows using short-form versions of intrinsic functions like `!GetAtt`. We handled them correctly in the `@aws-cdk/cloudformation-include` module, so extract that logic to a common package, and use it from the CLI in the `diff` command as well. Fixes #6537 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…10440) There's been some confusion around how to set `GitHubSourceActionProps`'s `oauthToken` property to a github token that was stored as a JSON key-value pair in Secrets Manager. - Updating the [Github Source](https://docs.aws.amazon.com/cdk/api/latest/docs/aws-codepipeline-actions-readme.html#github) section of the docs to clarify how to do so. Closes #8731 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
… to AWSCodeDeployRoleForLambdaLimited (#10276) The managed policy `AWSCodeDeployRoleForLambda` used for Lambda deployments has broad permissions, providing publish access to all SNS topics within the customer's accounts. This change replaces that with a new policy `AWSCodeDeployRoleForLambdaLimited` which removes those permissions. This should be safe, as the SNS publish permission is only ever used when setting up `triggers`, and we don't support that feature in `LambdaDeploymentGroup`. BREAKING CHANGE: the default policy for `LambdaDeploymentGroup` no longer contains `sns:Publish` on `*` permissions ---- *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
the
pr/no-squash
shivlaks
approved these changes
Sep 22, 2020
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically without squashing (do not update manually, and be sure to allow changes to be pushed to your fork). |
eladb
reviewed
Sep 22, 2020
|
Added |
…anges (#10483) ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
skinny85
approved these changes
Sep 22, 2020
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