fix(core): Add stage prefix to stack name shortening process#24443
fix(core): Add stage prefix to stack name shortening process#24443mergify[bot] merged 23 commits intoaws:mainfrom
Conversation
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
|
Clarification Request: I was unable to run the integration tests, but created a unit test, and made sure the change was not breaking the already existing unit tests. Do I need to create integration tests for this PR? |
…blo/fix-stack-name-too-long
…stodioPablo/aws-cdk into QustodioPablo/fix-stack-name-too-long
TheRealAmazonKendra
left a comment
There was a problem hiding this comment.
We do this in a lot of places, adding prefixes. I'm thinking it's a better options to add prefix as an optional prop in makeUniqueResourceName and adding the prefix there. What do you think? Also, I if this isn't impacting the outcome of any integ tests, I think omitting one is fine.
packages/@aws-cdk/core/lib/stack.ts
Outdated
| */ | ||
| function makeStackName(components: string[]) { | ||
| if (components.length === 1) { return components[0]; } | ||
| if (components.length === 1 && components[0].length <= 128) { return components[0]; } |
There was a problem hiding this comment.
Iirc, this check is done inside makeUniqueResourceName so it shouldn't be needed here.
There was a problem hiding this comment.
The check done inside makeUniqueResourceName will remove the - from the prefix, as it removes anything that is not a number or a character, unless you specify to keep a special character though parameters, but I was afraid of breaking compatibility with already existing stacks if doing so.
I'll make changes to pass the prefix to the makeUniqueResourceName as an optional parameter as you mentioned in another comment.
Thanks!
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
…blo/fix-stack-name-too-long
Pull request has been modified.
|
|
||
| // Calculate the hash from the full path, included unresolved tokens so the hash value is always unique | ||
| const hash = pathHash(components); | ||
| if (prefix) { |
There was a problem hiding this comment.
The prefix is added after the hash calculation to preserver the same hash for already existing stacks that fall within this scenario.
I'm not sure if I'm worrying too much, as I'm not sure what happens if you create a stack with CDK, then after this change you run CDK again, and the old created stack's name does not match the new name generated.
…blo/fix-stack-name-too-long
…blo/fix-stack-name-too-long
packages/@aws-cdk/core/lib/stack.ts
Outdated
| if (components.length === 1) { | ||
| const stack_name = prefix + components[0]; | ||
| if (stack_name.length <= 128) { | ||
| return prefix + components[0]; |
There was a problem hiding this comment.
When there is a single component and a prefix, passing both the components and the prefix to the makeUniqueResourceName might seem like the simplest and most straight forward implementation, but there is an issue with this approach.
Doing so will make some tests fail, where a stage with an empty stack is defined. Doing so will generate a prefix (the stage name), and a single component with the name of the default stack. The makeUniqueResourceName function removes all components with the default name, leaving us with no resources in the list, which makes makeUniqueResourceName throw an error.
…blo/fix-stack-name-too-long
…blo/fix-stack-name-too-long
TheRealAmazonKendra
left a comment
There was a problem hiding this comment.
Totally understand your concerns about these changes causing breaking changes, but this is adding a lot of extra handling to avoid that. I'm thinking that it might be best to put these changes behind a feature flag so that the changes can be made without worrying about that. What do you think?
| const HASH_LEN = 8; | ||
|
|
||
| export function makeUniqueResourceName(components: string[], options: MakeUniqueResourceNameOptions) { | ||
| export function makeUniqueResourceName(components: string[], options: MakeUniqueResourceNameOptions, prefix: string='') { |
There was a problem hiding this comment.
Let's add this as an option instead independently like this.
…stodioPablo/aws-cdk into QustodioPablo/fix-stack-name-too-long
…blo/fix-stack-name-too-long
Pull request has been modified.
I'm ok with adding this behind a feature flag, but we have stacks deployed with an older version that needs updating. We were not able to upgrade our CDK version yet because of this issue, so I'd like to try and fix this issue while keeping it compatible with older versions as much as possible, since afaik it would be mean having to redeploy everything in case the naming changes. Any suggestion? |
|
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 CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
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). |
|
Gah, I was away when the PR was approved and merged, and didnt have a chance to implement the feature flag. |
There is an issue in the stack name generation process where the prefix generated from assembly's stage name is not taken into account when shortening a stack name to meet the requirement of being equal or less than 128 characters longs. This can lead to generating an invalid stack name greater than 128 characters: since the stack name is shortened to 128 characters, when the prefix is added, the limit is exceeded. Current solution: - Adding a feature flag - With the feature flag on, the prefix is processed within the generateUniqueName function. - With the feature flag off, stack name generation is not changed Fixes #23628 NOTE: This PR was previously opened, but it was merged before I was able to add a feature flag, which ended up adding breaking changes and the changes of the PR were rolled back. Old PR: #24443
There is an issue in the stack name generation process where the prefix generated from assembly's stage name is not taken into account when shortening a stack name to meet the requirement of being equal or less than 128 characters longs.
This can lead to generating an invalid stack name greater than 128 characters: since the stack name is shortened to 128 characters, when the prefix is added, the limit is exceeded.
Current solution:
Alternative solution:
Fixes #23628
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license