-
Notifications
You must be signed in to change notification settings - Fork 4.2k
chore(release): 2.189.1 #34135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(release): 2.189.1 #34135
Conversation
… applications (#34132) Some CDK methods apply mutating Aspects on behalf of users. Since #32333, these Aspects have a priority of `MUTATING` to classify their behavior. If a user-applied Aspect (priority `DEFAULT`) now configures the same property as an implicitly added Aspect: * Before that change, the relative execution order depended on the location of the Aspects in the construct tree. * After that change, the user Aspect always "wins" (executes last) because its priority is higher. In this change, we roll back to the behavior from pre-2.172.0, and introduce a feature flag which gives the Aspects a priority only if the feature flag is enabled. This introduces the feature flag: ```json { "context": { "@aws-cdk/core:aspectPrioritiesMutating": true } } ``` Which sets the priority of Aspects added on your behalf a priority of `MUTATING` (200) (instead of the default `DEFAULT`, 500). * If you have given your own Aspect a priority of `MUTATING` already to make sure it can get overridden by another Aspect of priority `MUTATING`, this current change will not affect you (either with or without feature flag). * If you have come to rely on the new default priority being low already, you can set the above feature flag to re-enable the new behavior. ----------- Did not touch the following Aspects: - In `integ-tests-alpha`: overriding logical IDs in assertions stacks does not affect production infrastructure. - Tags: tags are exclusively manipulated through the official APIs, so there no conflict between custom and implicit Aspects. - CDK Pipelines: there cannot be a conflict because the customer can't create a default pipeline before the implicit Aspect. This PR also introduces some slight rendering and documentation changes to the feature flags to improve clarity of the purpose of certain fields and the produced report.
@@ -50,7 +51,9 @@ export class ApplicationAssociator extends Construct { | |||
this.associateCrossAccountStacks = targetBindResult.associateCrossAccountStacks; | |||
cdk.Aspects.of(scope).add(new CheckedStageStackAssociator(this, { | |||
associateCrossAccountStacks: this.associateCrossAccountStacks, | |||
}), { priority: cdk.AspectPriority.MUTATING }); | |||
}), { | |||
priority: cdk.FeatureFlags.of(this).isEnabled(cxapi.ASPECT_PRIORITIES_MUTATING) ? cdk.AspectPriority.MUTATING : undefined, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha, this doesn't use the mutatingAspectPrio32333
function.
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). |
Comments on closed issues and PRs are hard for our team to see. |
See CHANGELOG
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license