Goose didn't pick up go migration

[PrashantRaj18198]

Hello, we are using goose for a while now and it's an amazing tool. Thanks for building it first of all.

I encountered an issue with goose, for some reason this go migration wasn't picked up.

filename="migrations/postgres/00042_add_stock_runner_ubuntu_2404_arm64.go"

package postgres

import (
	"github.com/pressly/goose/v3"
	"github.com/<org>/<repo>/internal/runners/migrations"
)

func init() {
	goose.AddMigration(migrations.NewAddStockRunnerU24Arm64().Up, migrations.NewAddStockRunnerU24Arm64().Down)
}

Let me know if you need additional info on this.

[mfridman]

Can you double-check that you imported the postgres package (the one with the init). In other words, when you build your application you should typically have either a direct or blank import.

package main

import (
  _ "github.com/your/project/some/dir/postgres"
) 

func main() {
  goose.Up()
}

[PrashantRaj18198]

Yeah. It's present. What's weird is this isn't the first go migration file that we had. We had filename=migrations/postgres/00035_register_cron_snapshot_storage.go which ran without any issues and the caller file hasn't been changed.

Also, changing the filename to migrations/postgres/00042_stock_u24_arm64_add.go did execute the go migration.

Another thing I noticed is that this specific case was only present when run in a container.

I'm attaching Dockerfile for reference.

FROM golang:1.21.4 AS builder
ARG Version=dev
RUN apt-get update && apt-get install -y libgit2-dev
WORKDIR /go/src/github.com/<org>/<repo>/
COPY . .
RUN CGO_ENABLED=1 GOOS=linux go build -a -installsuffix cgo -o migrator ./migrations/main.go

FROM alpine:latest
RUN echo 'http://dl-cdn.alpinelinux.org/alpine/v3.13/community' >> /etc/apk/repositories && apk update && apk add libc6-compat
WORKDIR /go/src/github.com/<org>/<repo>/
COPY --from=builder /go/src/github.com/<org>/<repo>/ .
RUN chmod +x ./migrator
RUN mkdir -p /root/secrets/
ENTRYPOINT ["/bin/sh", "-c", "cp /root/secrets/* . && ./migrator"]

This file as well hasn't changed.

Another thing which I tried was adding the .go files to the go fs that we pass to goose

var (
	//go:embed postgres/*.sql postgres/*.go
	migrationsFS embed.FS
)

This made the 42 file discoverable at least. I was getting error

Error running migrations: ERROR postgres/00042_add_stock_runner_ubuntu_2404_arm64.go: failed to run Go migration: Go functions must be registered and built into a custom binary (see https://github.com/pressly/goose/tree/master/examples/go-migrations)Released lock
panic: ERROR postgres/00042_add_stock_runner_ubuntu_2404_arm64.go: failed to run Go migration: Go functions must be registered and built into a custom binary (see https://github.com/pressly/goose/tree/master/examples/go-migrations)

goroutine 1 [running]:
main.main()
	/go/src/github.com/warpbuilds/backend-core/migrations/main.go:54 +0x2b

Ignore the Release lock comment we do a mutex lock before doing the migration, but that shouldn't matter.

[mfridman]

Can you jot down the goose version you're using?

I suspect when using If you only specify //go:embed postgres/.sqlgoose is unaware of the.go` files, and if you don't register them (blank or direct import), it silently ignores them.

When goose is made aware of the *.go files it can detect "unregistered" migrations and surface a more meaningful error, since it has access to the files on disk.

I'd gladly help you, but without a reproducible example, it's hard to pinpoint the issue. If possible, creating the absolute minimum repository with a reproducible example would be helpful here.