-
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(codepipeline): set correct prop names for KMS key #2517
Conversation
It seems like this might actually be a bug in the serialization generator, since the return object doesn't require this to generate the correct Cfn syntax Not sure where to look for that though. In the meantime, this fixes the issue where Cfn will spit out an error for `Encountered unsupported property type`
Thanks for the contribution @CaerusKaru , but this is not the correct solution. See the CI error:
|
@skinny85 Can you advise on the correct solution? There is clearly a bug, but I genuinely think that it's in the serialization, and not here (as CI clearly shows). |
Please wait until #2576 has been applied and see if the error still persists. |
Any updates on this? |
I'm going to close this, as #3694 addresses the issue this PR was opened for. |
Pull Request Checklist
|
Codebuild (Continuous Integration) build failed for current commits. Please check log and resolve before PR is merged. |
Title does not follow the guidelines of Conventional Commits. Please adjust title before merge. |
This changes the scaffolding stack logic for the cross-region CodePipelines to include a KMS key and alias as part of it, which are required if an action is simultaneously cross-region and cross-account. We also change to use the KMS key ID instead of the key ARN when rendering the ArtifactStores property. We also add an alias to the default pipeline artifact bucket. This required a bunch of changes to the KMS and S3 modules: * Alias now implements IKey * Added the keyId property to IKey * Added removalPolicy property to Alias * Granting permissions to a key works if the principal belongs to a stack that is a dependent of the key stack * Allow specifying a key when importing a bucket Fixes #52 Concerns #1584 Fixes #2517 Fixes #2569 Concerns #3275 Fixes #3138 Fixes #3388
It seems like this might actually be a bug in the serialization
generator, since the return object doesn't require this to generate
the correct Cfn syntax
Not sure where to look for that though. In the meantime, this fixes
the issue where Cfn will spit out an error for
Encountered unsupported property type
Pull Request Checklist
design
folderBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.