engine binaries conflicts on CI

[alampros]

Our schema has two generators (js and go). It builds locally (apple arm m1) and locally in docker (linux/amd64 emu), however, when run in a GitHub Actions workflow, it fails with the following error:

4.235 go: downloading google.golang.org/genproto/googleapis/api v0.0.0-20240604185151-ef581f913117
4.241 go: downloading golang.org/x/text v0.16.0
12.14 # github.com/e2grnd/eec-go/prisma/db
Error: 12.14 prisma/db/query-engine-debian-openssl-3.0.x_gen.go:15:5: data redeclared in this block
Error: 12.14 	prisma/db/query-engine-debian-openssl-1.1.x_gen.go:15:5: other declaration of data
------
dcs-grpc.Dockerfile:19
--------------------
  17 |     RUN go run github.com/steebchen/prisma-client-go generate --generator=db
  18 |     
  19 | >>> RUN go build -o dcs-grpc ./cmd/dcs-grpc
  20 |     RUN go build -o health ./cmd/dcs-grpc/health-dcs
  21 |     
--------------------
ERROR: failed to solve: process "/bin/sh -c go build -o dcs-grpc ./cmd/dcs-grpc" did not complete successfully: exit code: 1
Error: buildx failed with: ERROR: failed to solve: process "/bin/sh -c go build -o dcs-grpc ./cmd/dcs-grpc" did not complete successfully: exit code: 1

Our schema is relatively small (208 lines) with the following generator config:

generator client {
  provider      = "prisma-client-js"
  output        = "dist"
  binaryTargets = ["native", "darwin-arm64", "debian-openssl-1.1.x", "debian-openssl-3.0.x"]
}

generator db {
  provider = "go run github.com/steebchen/prisma-client-go"
}

Any help in getting it built would be much appreciated!

[steebchen]

As discussed on Discord, ["darwin-arm64", "linux-static-x64"] works

It looks like it's still downloading the fully native binary, which creates a conflict if another linux binary is additionally specified in the binaryTargets and if it differs from the system

I think I can find a fix for this, but will have to look in detail in that logic again

[alampros]

Is this happening because we have both the js and go generators in there?

[steebchen]

No, that should be unrelated. It's about the fact that the Go client attempts to download a more specific binary if "native" is defined and that can clash with additional manually defined engines. So it's a bug.