-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix(core): Add stage prefix to stack name shortening process #24443
fix(core): Add stage prefix to stack name shortening process #24443
Conversation
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.
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
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.
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
@@ -1629,7 +1633,7 @@ export function rootPathTo(construct: IConstruct, ancestor?: IConstruct): IConst | |||
* behavior. | |||
*/ | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Iirc, this check is done inside makeUniqueResourceName
so it shouldn't be needed here.
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.
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.
@@ -68,6 +68,9 @@ export function makeUniqueResourceName(components: string[], options: MakeUnique | |||
|
|||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
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?
@@ -46,7 +46,7 @@ const MAX_LEN = 256; | |||
|
|||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add this as an option instead independently like this.
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.
Done!
…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