Skip to content
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

(cli-lib-alpha): should be able to disable cloud assembly version check #201

Closed
2 tasks
corymhall opened this issue Feb 7, 2025 · 7 comments · Fixed by #202
Closed
2 tasks

(cli-lib-alpha): should be able to disable cloud assembly version check #201

corymhall opened this issue Feb 7, 2025 · 7 comments · Fixed by #202

Comments

@corymhall
Copy link

Describe the feature

When you use the AwsCdkCli.fromCloudAssemblyDirectoryProducer() it defaults to enforcing a version check on the CloudAssembly. You should be able to disable the version check.

Use Case

For my use case I need it to create a CloudAssembly, but I don't want it to do a version check. I am using the AwsCdkCli to synth and then I will read the resulting cdk.out directory and pull the information I need from it. By enforcing a version check it requires me to keep the version of this library always up to date, otherwise users get an error if they are using a new version of aws-cdk-lib.

Proposed Solution

With the current implementation of fromCloudAssemblyDirectoryProducer it looks like we might not even need to create a cxapi.CloudAssembly. We might be able to change this line https://github.com/aws/aws-cdk/blob/873233b6af6952fca62dfc9cc2a5e92351b0d2d6/packages/@aws-cdk/cli-lib-alpha/lib/cli.ts?plain=1#L128

to be:

  return withEnv(async() => await producer.produce(context), env);

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

CDK version used

2.178.0

Environment details (OS name and version, etc.)

Any

corymhall referenced this issue in pulumi/pulumi-cdk Feb 7, 2025
This PR does a couple of updates.

- Update the dependency on `@aws-cdk/cli-lib-alpha` due to https://github.com/aws/aws-cdk/issues/33338
- Update the devDependency on `aws-cdk-lib` to the latest version
- Update the examples deps to the latest version
- Add some renovate rules to automate this

This is needed because the library will throw an error if the user is
using a version of `aws-cdk-lib` that is above the version of
`@aws-cdk/cli-lib-alpha` so we need to keep this version up to date.
@pahud pahud added the p2 label Feb 7, 2025
@pahud
Copy link

pahud commented Feb 7, 2025

Thank you @corymhall I'll bring it up to the team.

@pahud pahud removed the needs-triage label Feb 7, 2025
corymhall referenced this issue in pulumi/pulumi-cdk Feb 10, 2025
This PR does a couple of updates.

- Update the dependency on `@aws-cdk/cli-lib-alpha` due to https://github.com/aws/aws-cdk/issues/33338
- Update the devDependency on `aws-cdk-lib` to the latest version
- Update the examples deps to the latest version
- Add some renovate rules to automate this

This is needed because the library will throw an error if the user is
using a version of `aws-cdk-lib` that is above the version of
`@aws-cdk/cli-lib-alpha` so we need to keep this version up to date.
corymhall referenced this issue in pulumi/pulumi-cdk Feb 10, 2025
This PR does a couple of updates.

- Update the dependency on `@aws-cdk/cli-lib-alpha` due to
https://github.com/aws/aws-cdk/issues/33338
- Update the devDependency on `aws-cdk-lib` to the latest version
- Update the examples deps to the latest version
- Add some renovate rules to automate this

This is needed because the library will throw an error if the user is
using a version of `aws-cdk-lib` that is above the version of
`@aws-cdk/cli-lib-alpha` so we need to keep this version up to date.
@iliapolo
Copy link
Contributor

@corymhall Generally i'm not opposed to allow this flexibility, especially since this is programatic access, and especially since skipping the version check is already supported inside LoadManifestOptions.

But I'm having trouble understanding the use-case. You mention:

I am using the AwsCdkCli to synth and then I will read the resulting cdk.out directory and pull the information I need from it

In that case, can't you run producer.produce(context) on your side? is it because you need us to create the context object?

I'm leaving this as a p2 for now and poking @mrgrain to comment on whether this is something already addressed or should be addressed in the new programatic CLI library.

@mrgrain
Copy link
Contributor

mrgrain commented Feb 17, 2025

Thanks @corymhall In cli-lib-alpha we definitely need to call createAssembly at some point. The same will be true for the upcoming [Programmatic Toolkit]. It's a feature of the CLI (and thus cli-lib-alpha and [Programmatic Toolkit]) to verify version support.

It sounds like you don't really need the CLI functionality though. Could you just call

await producer.produce(context)

yourself? If not what's missing from it?


For [Programmatic Toolkit] we can look at making this an option. I'll need to check what the consequences are if we do that.

@corymhall
Copy link
Author

It sounds like you don't really need the CLI functionality though. Could you just call
await producer.produce(context)
yourself? If not what's missing from it?

I need the CLI functionality to produce the context for me.

Essentially the use case for pulumi-cdk is that we will synthesize the Cloud Assembly and then use the information there to map each CFN resource to a Pulumi resource. We could just call app.synth or producer.produce(), but then we lose the ability to use context lookups since those are populated by the CLI.

An alternative approach I guess would be to expose the logic of populating missing context in here as a function that I could call to get the context and pass to producer.produce(). Or even just the ability to call the provideContextValues (or the individual context providers) function myself.

@mrgrain
Copy link
Contributor

mrgrain commented Feb 18, 2025

Ah that makes sense. For the [Programmatic Toolkit] I was actually already considering making the context lookup a public feature. This might just be the justification for it. I'm also not at all against adding this new option.

For our planning: What kind of urgency are we talking about here?

@corymhall
Copy link
Author

For our planning: What kind of urgency are we talking about here?

No urgency on my side yet. I think I can work around it for now by always upgrading the cli-lib-alpha dependency whenever there are new versions.

@mrgrain mrgrain transferred this issue from aws/aws-cdk Mar 6, 2025
github-merge-queue bot pushed a commit that referenced this issue Mar 6, 2025
… for sources (#202)

Fixes #201

Feature request was for `cli-lib-alpha`, however we are instead adding
this to the new package that should be used going forward.

---
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache-2.0 license
@mrgrain
Copy link
Contributor

mrgrain commented Mar 6, 2025

@corymhall this will be in the next toolkit-lib release. When you have time to try it out, let me know how it goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants