Unable to build rust binary in non-release mode

[GeeWee]

Version

Fastly CLI version v10.14.1 (b3926881) Built with go version go1.22.7 linux/amd64 (2024-10-01) Viceroy version: viceroy 0.12.0

What happened

We want to run our rust binaries in non-release mode locally, when e.g. performing integration or manual tests against them, due to debug mode builds being significantly faster.

I have tried changing the build script to simply omit the --release flag. However, I get the error failed to copy wasm binary: cannot read source file: /home/runner/work/edge-api/edge-api/target/wasm32-wasi/release/edge-api.wasm, which makes sense, as that is no longer the correct path, instead it is located under /target/wasm32-wasi/debug/edge-api.wasm

Internally it looks like the internalPostBuildCallback has a fixed idea of where the binary is located.

Currently we're performing a workaround by copying the binary with this monstrosity of a build script.

[scripts]
build = """
cargo build --bin edge-api --target wasm32-wasi --color always &&
TARGET_DIR=$(cargo metadata --format-version=1 | python3 -c "import sys, json; print(json.load(sys.stdin)['target_directory'])") &&
mkdir -p ${TARGET_DIR}/wasm32-wasi/release &&
command cp -f ${TARGET_DIR}/wasm32-wasi/debug/edge-api.wasm ${TARGET_DIR}/wasm32-wasi/release/edge-api.wasm
"""

I tried using a post_build script as well, but the internalPostBuildCallback seems to run before that.

I believe this is related to #1317 as that is also caused by the internalPostBuildCallback having a fixed idea of where the binary is located.

A good solution would be to rely on the build script to actually produce the binary at the correct location, or allow me to specify where the binary to be copied resides.

[kpfleming]

Thanks for the excellent issue, as always :-) Your analysis of the problem seems to be completely correct, we've got code making assumptions that it should not make.

[GeeWee]

Good thing the build script is just a shell script so we can workaround it for now! If anyone else is reading, this workaround also works for #1317 :)