-
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): asset bundling skipped when using --exclusively with custom stack name #21248
fix(core): asset bundling skipped when using --exclusively with custom stack name #21248
Conversation
const bundlingStacks = config.settings.get(['bundlingStacks']); | ||
if (bundlingStacks) { | ||
context[cxapi.BUNDLING_STACKS] = bundlingStacks; | ||
} |
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.
An alternative to allowing bundlingStacks
to be undefined when no pattern is supplied on the CLI (as in these changes) would be to set a valid "all" pattern for minimatch here (i.e. globstar **
which matches stacks under a stage) and in settings.ts where the CLI input is parsed. Or handling ['*']
as a special case outside of minimatch (which the first commit does).
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.
I think I would be fine updating it to use **
since I would imagine that was the intention from the start.
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.
I agree, I'd rather have fewer if
s (fewer branches ⇒ fewer things that can behave unexpectedly).
So defaulting to **
seems correct.
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.
Updated. It's worth noting that users explicitly specifying *
on cdk deploy '*'
will need to update it to **
in order to match stacks under stages. Similarly, patterns like *StackNameEnd
will need updating to **/*StackNameEnd
.
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.
I actually think this is fine. Currently specifying *
or *StackNameEnd
does not work for stacks under a stage, you have to do */*
or */*StackNameEnd
which still work after this change.
Please make sure that your PR title confirms to the conventional commit standard (fix, feat, chore) and that it is written in a style that will reflect correctly in the change log (See Contributing Guide, Pull Requests) |
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.
See discussion
a9a48a0
to
dc97adc
Compare
I opened #21925 and chased it for a while before @mrgrain helpfully pointed me at this PR. My issue is where there are multiple layers of nesting, but I think it too will be fixed by the change in this PR. See #21925 (comment) Edit: only other thing I might be able to add is: do you want this test here: https://github.com/aws/aws-cdk/pull/21962/files#diff-f408c19e5bd715b329b76439aaf92dfe47c956a0277896b04e9a0c52b7cbcfe2R939-R961 ? |
…-use-same-logic-as-aws-cdk-take-2
306cc26
to
d1dba12
Compare
Compromise thought: bundle if either the new (path) or old (name) logic says to bundle. This is messy, but guarantees backwards compatibility (at least, won't stop bundling something that was bundled before). Also, I don't really understand why the old name-based logic was required to make pipeline deployments work. I'm not sure if there is a unit test for it anywhere, so I'm not sure if this change, as it stands, will cause that to regress. |
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.
Added |
✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.
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.
@stevehodgkiss sorry for the delay on this. I wanted to make sure I tested this out and I finally was able to.
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). |
Fixes #19927
A previous PR attempted this fix, but it caused another issue where the default pattern (
['*']
, used on cdk synth/deploy when a pattern isn't supplied) doesn't match stacks under a stage (stage/stack
), and that caused bundling to be skipped. The default pattern worked (matched all stacks) previously because stackName was being used (and there are no/
in stack names). See this comment in the issue for more details on this.The first commit 5556b60 adds special handling to the default pattern so that it always returns true (bypassed minimatch which would return false if a stack is under a stage). The second commit a9a48a0 aims to remove the duplication of this pattern across the codebase, by defaulting
BUNDLING_STACKS
toundefined
and returning true in bundlingRequired if that's the case.All Submissions:
Adding new Unconventional Dependencies:
New Features
yarn integ
to deploy the infrastructure and generate the snapshot (i.e.yarn integ
without--dry-run
)?By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license