You’d have better success asking these on Stackoverflow / Suborbital’s dev channels, tbh, as building wasm in Docker isn’t really specific to Fly, at all.
That said, if you’re bought in to suborbital’s ecosystem, then ref this post (and for background see these 1, 2, 3) which is specific to their wasm-as-FaaS toolchain and runtime.
Building Golang in Docker is executing go build / go test / go get / go install commands as you would in your shell.
Specifically, per the articles shared above, to target wasm with go, one would exec:
cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" .
GOOS=js GOARCH=wasm go build -o sha256.wasm
which (I haven’t tested) but for SAT translates to:
# create a build-stage "builder" Docker img w subo:latest
#
FROM suborbital/builder-tinygo:dev AS builder
# setup work dir in builder
RUN mkdir /app
WORKDIR /app
# copy contents of current dir in host into Docker img
COPY . .
# run other commands as needed
# ...
# compile the current go module (ex: sha256.go) to wasm w subo
subo build . --native
# create a deploy-stage "runner" Docker img w suborbital sat
FROM suborbital/sat:latest AS runner
# copy build output from builder into runner's root dir
COPY --from=builder /app/sha256.wasm /
ENV SAT_HTTP_PORT 8080
ENTRYPOINT [ "sat", "./sha256.wasm" ]
If not, you’d have to build with subo outside of Dockerfile (that would then contain only the runner stage).
A better soln would be if someone codes up a “fly deployer” (like so).