refactor: swap rust function #152
Conversation
…rate compile directory
…st-function # Conflicts: # lib/workload/stateless/filemanager/.sqlx/query-63da484d18ed2571639cfddadf992fe9ea92767a8274859de371f4e954e554b8.json # lib/workload/stateless/filemanager/.sqlx/query-7495c606d6e756a6e53e45fc0ee6a0765922a5fef3d512c719d4aec543d0d8a6.json # lib/workload/stateless/filemanager/.sqlx/query-c05597a449cf3e2e125bec198486d2bc57b270abf737f64cfe386650fd1d2b9e.json
mmalenic
force-pushed
the
refactor/swap-rust-function
branch
from
a44a62f to
eb3654e
Compare
| @@ -29,10 +29,10 @@ | |||
| "@aws-cdk/aws-apigatewayv2-integrations-alpha": "^2.110.0-alpha.0", | |||
| "@aws-cdk/aws-lambda-python-alpha": "2.110.0-alpha.0", | |||
| "aws-cdk-lib": "^2.126.0", | |||
| "cargo-lambda-cdk": "^0.0.19", | |||
There was a problem hiding this comment.
I'm wondering if this should go in a package.json inside the filemanager directory? I noticed @williamputraintan did this for the postgres manager.
There was a problem hiding this comment.
But will the pipeline environment still have access to install the dependency as part of the CDK? The postgres manager package.json but its for the lambda runtime
There was a problem hiding this comment.
I think, cargo-lambda-cdk here is fine. It is part of the cdk build time or rather cdk synthesis requirement.
There was a problem hiding this comment.
Okay, sounds good. One approach could be to have multiple yarn workspaces as well? Although I think for now that's probably unnecessary for one dependency.
There was a problem hiding this comment.
Yup, yup. Well spotted, Marko. We're gonna hit the yarn workspaces in tick, real soon. Let sit tight for the moment, pls.
|
It builds twice for each function though - migrate and ingest. But I reckon that is fine. We can optimise those bits later. |
Hmm, good point, that might slow things down a bit as there's definitely overlapping code (i.e. |
|
No rush. Early days... |
Closes #133. I think this fixes a few issues around building Rust code.
Changes
query-*files.These changes should make it easier to build the Filemanager code without special dependencies. There is a small downside in that the docker container produces code which isn't owned by the current user, meaning that sometimes permissions errors can occur if trying to remove/clean this directory. Although, I've documented this.