V1.21.0 #5825
Merged
V1.21.0 #5825
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
- in the middle of document, there is comparison between AWS Fargate vs Amazon ECS. - it should be comparing AWS Fargate & Amazon EC2 - closes #5393
- as suggested on comment(https://github.com/aws/aws-cdk/pull/5394\#discussion_r357787988), it will be easily understandable if we mention what Fargate and EC2 are used for.
* v1.20.0 * chore(cli): fix Java dist integ tests (#5695) (#5699) The Java integ test which is run against the dist is failing because the local `cdk-cx-api` Maven artifact cannot be found. Error message: ``` [ERROR] Failed to execute goal on project cdk-init-test: Could not resolve dependencies for project com.myorg:cdk-init-test:jar:0.1: Failed to collect dependencies at software.amazon.awscdk:core:jar:1.20.0 -> software.amazon.awscdk:cdk-cx-api:jar:[1.20.0]: No versions available for software.amazon.awscdk:cdk-cx-api:jar:[1.20.0] within specified range -> [Help 1] ``` It is not clear to me why just this artifact cannot be found while for example `core` can be found correctly, or why this problem only shows up on the `release` branch, but after some reading of the Maven source and local experimentation I have concluded that the proper filename of the Maven metadata file should be `maven-metadata-local.xml` (instead of just `maven-metadata.xml`), so we rename the files before rsync'ing them into the repository now. * remove breaking change that didn't really happen * chore: fixup entries in the CHANGELOG (#5706) Co-authored-by: Rico Huijbers <rix0rrr@gmail.com> Co-authored-by: Elad Ben-Israel <benisrae@amazon.com>
#5698) Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
#5705) * fix(ecr-assets): unable to use one Dockerfile to build multiple images Since we use the source hash as the image ID, if we use different docker build options such as specifying a different `target`, `buildArgs` or a custom docker file name, we still get the same image ID. This means that if this image ID already exists, we skip the build. This makes it impossible to use the same docker build context to build multiple images. This fix exposes the ability to include extra information to the source hash fingerprint algorithm (in `assets.Staging`), and utilizes this capability to "salt" the hash with build arguments if they are provided. Fixes #5683 * code review feedback - rename `extra` to `extraHash` so it makes more sense when extending `FingerprintOptions`. - build `extraHash` as an object instead of an array. - include `repositoryName` in fingerprint * Update fingerprint.ts * Update copy.ts * fix build * add test for repository name Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Otherwise every single `cdk` command outputs the source hash when
`BucketDeployment` is used in one of the stacks.
Something like:
```
{
sourceHash: '6416c21be320b522db64c705872c0a54d788e3df57b34a5f0d1e8602d7521430'
}
```
Co-authored-by: Elad Ben-Israel <benisrae@amazon.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
…approval action (#5558)
The method onStateChange() in Action, the common superclass for all CDK-vended actions, incorrectly set the `detailType` of the CloudWatch event rule it created to 'CodePipeline Stage Execution State Change', when it should be 'CodePipeline Action Execution State Change'. Fixes #3614 Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
a4e2353 was a squash commit. Record the merge so that future releases will work correctly.
silence trillions of jsii reserved keyword warnings. if we decide we want to get rid of these reserved keywords, we need to do it in one fell swoop as part of 2.0. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Since we are `require()`ing the `sdk-api-metadata.json` file, TypeScript is going to generate a type definition `.d.ts` file for it. However, it forgets to add it to its own ignore list, so upon the next compilation it will both try to read *and* generate '.d.ts' file, leading it to think it's about to overwrite a source file with the following error: ``` Cannot write file 'sdk-api-metadata.d.ts' because it would overwrite input file. ``` Delete the `.d.ts` file before each build so we don't run into this build failure (until tsc fixes this issue upstream). Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Use `this` instead of `scope` and make `props` optional. Fixes #5686 Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
The authorizer name property is marked as optional in CloudFormation docs but is actually not. Use the TokenAuthorizer node's uniquId as the default. fixes #5678 Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
AddressRecordTarget has been deprecated. Use RecordTarget instead. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Implements an ability to assert presence of stack outputs with specific properties being present. Fixes #1906
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
`Principal: "*"` supposedly works to allow any Principal to assume
a Role (restricted by `Conditions`, of course), but doesn't work in
practice. The IAM API rejects it as a MalformedPolicyDocument.
In order to not generate a large diff on existing policies, disable
simplification of `Principal: { AWS: * }` to `Principal: *` only
for AssumeRole policy documents.
Fixes #5732.
* L2: enable server access logs in a S3 bucket use serverAccessLogs and reference the L1 construct directly through LazyValue * un-nested properties * Update bucket.ts * added integration tests * add AC to the log group in the integs * ACL support for logDelivery * updated the test to new format * Throw error if ACL would be changed while calling allowLogDelivery() * allowLogDelivery method moved to Bucket and made private * Bucket's accessControl is not anymore public * README entry and removed accessControl from the import Co-authored-by: Elad Ben-Israel <benisrae@amazon.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* added project dir lookup in cdk.ts * added integration test * revert lock file * phrasing touchup * Use path.dirname() instead of slicing path parts * added sanity test for running cdk outside of project directory * added comment * remove cleanup as the script is being called as a child process * create temp directory instead of relying on parent directory * added cleanup to remove temp directory Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Add a new method to `Role` called `withoutPolicyUpdates()`, which returns a wrapper object that will drop all policy updates. This can be used in situations where you want to skip the default IAM permission adding behavior of CDK. Needs only be used with roles that are created in the same CDK application; for imported roles, supplying `mutable=false` when calling `Role.fromRoleArn()` is sufficient. Fixes #2985. Fixes #4465. Closes #4501.
In the case of an ECS Service runningon EC2 capacity, pointing a Load Balancer to the Service involves updating the SecurityGroups of the capacity associated to the Cluster (to allow traffic from the Load Balancer). If these resources are in different stacks, this is liable to create cyclic references: Service points to Cluster, Security Groups point to Load Balancer, cyclic references arise from the way these resources are typically colocated. This changes makes it so the ingress/egress rules will be created in the same stack as the Service (which points to both Cluster and LB), hence making sure there are no cycles. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
chore(ecs): correct doc with proper comparison between launch types
MrArnoldPalmer
added
the
pr/do-not-merge
MrArnoldPalmer
requested review from
eladb,
garnaat,
nija-at,
rix0rrr,
RomainMuller,
shivlaks,
skinny85 and
SoManyHs
as code owners
|
did you want to add |
MrArnoldPalmer
force-pushed
the
v1.21.0
branch
from
c84a6f7 to
0e44e2a
Compare
shivlaks
approved these changes
Jan 16, 2020
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
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
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license