tl;dr When you run fly launch on a Golang app, we no longer use Buildpack gcr.io/paketo-buildpacks/go.
Instead we generate a Dockerfile for you.
why? We’ve seen users hit errors with the Go buildpack, and thought it was time to setup something a bit more opinionated for Fly. Your opinions are also welcome as well [pr here].
tweaking the Setup The good news if that if our opinions aren’t what you want, you can pretty easily change it (maybe you need CGO_ENABLED=1 or want to include ldflags).
The fly launch command will read your go.mod file and use the Go version set there. You can over-ride that in your fly.toml by adding build args:
# fly.toml
[build.args]
GO_VERSION = "1.21.5"
As I’m writing this, the Dockerfile created looks something like this:
ARG GO_VERSION=1
FROM golang:${GO_VERSION}-alpine as builder
WORKDIR /usr/src/app
COPY go.mod go.sum ./
RUN go mod download && go mod verify
COPY . .
RUN go build -v -o /run-app .
FROM alpine:latest
COPY --from=builder /run-app /usr/local/bin/
CMD ["run-app"]
You can set release command in the deploy section of your fly.toml.
[deploy]
release_command = "bin/rails db:prepare"
how the binary can access source files, for instance to execute SQL files?
I’m not sure I follow what you’re asking here, the binary can access any source files you’ve added to your docker image by specifying location it’s been copied to. Could you give an example of what you’re trying to do?