rust.aws-cdk-lambda icon indicating copy to clipboard operation
rust.aws-cdk-lambda copied to clipboard

Don't build on synth

Open John0x opened this issue 2 years ago • 5 comments

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)

John0x avatar May 13 '22 12:05 John0x

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.

rnag avatar May 13 '22 17:05 rnag

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 avatar May 13 '22 21:05 John0x

@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.

rnag avatar Aug 05 '22 23:08 rnag

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

calavera avatar Aug 06 '22 00:08 calavera

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.

rnag avatar Feb 04 '23 04:02 rnag