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

Don't build on synth #10

Open
John0x opened this issue May 13, 2022 · 5 comments
Open

Don't build on synth #10

John0x opened this issue May 13, 2022 · 5 comments
Labels
awaiting-response enhancement New feature or request good first issue Good for newcomers

Comments

@John0x
Copy link

John0x commented May 13, 2022

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)

@rnag
Copy link
Owner

rnag commented May 13, 2022

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.

@John0x
Copy link
Author

John0x commented May 13, 2022

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.

@rnag
Copy link
Owner

rnag commented Aug 5, 2022

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

@calavera
Copy link
Contributor

calavera commented Aug 6, 2022

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:

aws/aws-cdk#21486 (comment)

@rnag
Copy link
Owner

rnag commented Feb 4, 2023

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 rnag added enhancement New feature or request good first issue Good for newcomers awaiting-response labels Feb 4, 2023
kikuomax added a commit to codemonger-io/rust.aws-cdk-lambda that referenced this issue Mar 16, 2023
- This work is done according to the comment:
  rnag#10 (comment)
kikuomax added a commit to codemonger-io/rust.aws-cdk-lambda that referenced this issue Mar 16, 2023
- Changes the default asset hash type to `SOURCE` to prevent the costly
  Rust compiler from running when there is no change in the source
  files. `BundlingProps` includes additional properties `assetHashType`
  and `assetHash` to allow a user to change the asset hash type and
  value, but `RustFunction` does not support it yet.
- This change may be a workaround for the issue rnag#10.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-response enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants