feat(compute/build): support Cargo Workspaces #1023
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1020
Problem
The logic flow prior to this PR would cause a user's custom build script to be replaced with a default build script if the package name they set in their Cargo.toml didn't match the 'default' package name of
fastly-compute-project
.This issue was further exacerbated when a customer used a Cargo Workspace to structure their project. As part of a reduced test case I discovered a bug that caused the user's custom build script to be unexpectedly modified and also changed it in such a way that it would break the build step.
Solution
This PR modifies the logic flow for a Rust project.
The updated flow looks like this...
If using a standard project structure, then the root Cargo.toml won't be a Cargo Workspace, and so it will contain a package name. The CLI will assign that name to
r.packageName
and later on it will use that name to look up the compiled binary and move it to the requiredbin/
directory.If the user has set up a Cargo Workspace but there is no custom build script, then the CLI needs to identify which Workspace package is their application. It does this by checking if the package has a rust-toolchain.toml containing the target
wasm32-wasi
and if so we extract the package name from that package's relevant Cargo.toml manifest. The CLI will assign that name tor.packageName
and later on it will use that name to look up the compiled binary and move it to the requiredbin/
directory.If the user has set up a Cargo Workspace and they define a custom build script, then the CLI will trust their custom script aligns with the relevant Workspace package name (i.e. their custom script is set up to reference the right binary). The CLI will parse the package name specified in their custom script by looking at the value assigned to the
--bin
flag. The CLI will assign that name tor.packageName
and later on it will use that name to look up the compiled binary and move it to the requiredbin/
directory.If there is no custom build script (i.e. the CLI will use a pre-defined default build script), then the CLI will check to see if the package name (assigned to
r.packageName
) matches the default package namefastly-compute-project
. If not, then it will update the default build script to use whatever package name is assigned tor.packageName
.NOTES
I've tested this PR with different project set ups to validate the new logic flows.
Below is an example Cargo Workspace project I tested this with...
Below is the root workspace
Cargo.toml
...Below is the
compute/Cargo.toml
...Below is the fastly.toml file I used with the Cargo Workspace (notice it was moved to the root directory, i.e. I moved it out from the
compute/
directory which contains my Compute application)...