rust.aws-cdk-lambda
rust.aws-cdk-lambda copied to clipboard
Don't build on synth
Hey, it looks like RustFunction is trying to execute cargo lambda upon synth, which in my opinion shouldn't happen. I have multiple stacks and don't want to compile the rust function every time I deploy one of the stacks (most don't include rust functions)
Hi @John0x, thanks for opening this issue. It looks like this is closely related to #9 , so I agree that ideally we should avoid calling cargo lambda build
in the case that either cdk synth
or cdk destroy
is run.
I am honestly not sure of the best way to achieve this, so I will likely have to research a bit more into it. I have a feeling like cdk
might expose some kind of context info somewhere, which should help us figure out if cdk deploy
for instance is being run. In the meantime, I would certainly welcome a PR to achieve this, in case anyone has any ideas for example.
Thank you for the response :) I thought that this would be pretty straight forward with CDK. I might look into it as well, if I get the time next week.
@John0x I've opened a discussion on the AWS CDK repo currently in regards to this issue, I'm hopeful that we can get some traction and help with moving this along, or at least someone can maybe point us in the right direction and we can better determine what we should be looking at.
So I think as it pertains short term, there are some relatively quick, hopefully, straightforward steps we can take towards a favorable resolution, at least as a stop-gap solution. This would involve passing a context variable in when invoking the cdk
subcommand. For instance, something along the lines of this is what I had planned:
cdk synth -c build=false
I could also expose this value in the global Settings
object, just so it's a little easier to pass in programmatically if needed. Short term, I think this will be helpful, so when this flag is passed, we can skip calling cargo-lambda
and maybe just put a dummy file in the .build
directory in lieu of the compiled binary. I have a feeling that should resolve the long build/compile times in cases when cdk synth
or cdk destroy
are invoked.
I don't know how discussions work, so putting the link here again. I think you need to copy what the cdk is doing with Go Lambda functions:
https://github.com/aws/aws-cdk/discussions/21486#discussioncomment-3337597
Hi @John0x, I've published a new release, v1.2.1
. Please take a look and let me know if it resolves the issue in your case. I am curious if it does so automatically (without changes needed on your end), since I am using a working (stop-gap) solution that I got from here.
More or less, for now that's doing the equivalent of:
skipBuild = !Stack.of(this).bundlingRequired;
The benefits are that RustFunction
now skips the compile step for Rust code with cargo lambda
when cdk
subcommands such as destroy
and list
are run.
However, it appears to be a limitation in the CDK bundling process, that we aren't able to distinguish between synth
and deploy
. So for now, build step still runs by default for synth. Although, I am curious to know if it resolves the issue in your case -- as you mentioned that you were only deploying specific stacks that were not using RustFunction
at all.
In case that doesn't resolve the issue entirely, also try this as a potential workaround for now:
cdk synth -c build=0
Truthy values as documented are T | true | 1 | Y | yes | ok | on
-- anything else should evaluate to "false" and result in the build step being skipped.