You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Go 1.26.4, linux/amd64 (module declares go 1.25.0)
Frontend built first (npm ci && npm run build in web/), so the web/dist embed resolves
Symptom
go build ./... fails on current master:
# github.com/containeroo/heartbeats/internal/notify
internal/notify/receivers.go:124:3: unknown field Vars in struct literal of type "github.com/containeroo/notifykit/notify".Receiver
internal/notify/receivers.go:191:5: unknown field SubjectTmpl in struct literal of type webhook.Target
internal/notify/receivers.go:324:4: unknown field Vars in struct literal of type "github.com/containeroo/notifykit/notify".Payload
internal/notify/receivers.go:337:4: unknown field Vars in struct literal of type "github.com/containeroo/notifykit/notify".Payload
I also probed older notifykit releases to see whether a pin rollback would help: v0.0.10, v0.0.9, v0.0.8, and v0.0.7 all fail to compile internal/notify too (v0.0.10 still lacks SubjectTmpl on webhook.Target). So master currently builds against no released notifykit version. The v0.23.0 tag compiles fine, so releases and published images are unaffected.
Why CI didn't catch it
The Unit Tests workflow only triggers on pull requests targeting main, but the repository's default branch is master:
Adapt internal/notify/receivers.go to the current notifykit API (the Vars/SubjectTmpl fields moved or were renamed upstream), or pin notifykit back to whatever version the pre-fix(deps): update module github.com/containeroo/notifykit to v0.0.11 #228 code was written against until the adaptation lands. I didn't attempt the adaptation myself since the intended API mapping is your call.
Merge-order note: once #244 lands, the first PR touching Go code goes red until the compile break above is fixed; that's the gate doing its job, but fixing the compile break first avoids the red window.
Environment
masterat9290055go 1.25.0)npm ci && npm run buildinweb/), so theweb/distembed resolvesSymptom
go build ./...fails on current master:I also probed older notifykit releases to see whether a pin rollback would help: v0.0.10, v0.0.9, v0.0.8, and v0.0.7 all fail to compile
internal/notifytoo (v0.0.10 still lacksSubjectTmplonwebhook.Target). So master currently builds against no released notifykit version. The v0.23.0 tag compiles fine, so releases and published images are unaffected.Why CI didn't catch it
The Unit Tests workflow only triggers on pull requests targeting
main, but the repository's default branch ismaster:tests.ymllines 5-8 at9290055filterpull_requesttobranches: [main].master, so the gate never runs. fix(deps): update module github.com/containeroo/notifykit to v0.0.11 #228 (the bump to notifykit v0.0.11 ingo.modline 9) merged with only the Autorelease checks green, and the build break landed unnoticed.make testfails at compile before running a single test.Suggested fix
Two independent parts:
tests.ymlbranch filter tomaster(one line). That restores the gate for every future PR, including Renovate bumps like fix(deps): update module github.com/containeroo/notifykit to v0.0.11 #228. Submitted as ci: run the unit-test gate on PRs to master #244.internal/notify/receivers.goto the current notifykit API (theVars/SubjectTmplfields moved or were renamed upstream), or pin notifykit back to whatever version the pre-fix(deps): update module github.com/containeroo/notifykit to v0.0.11 #228 code was written against until the adaptation lands. I didn't attempt the adaptation myself since the intended API mapping is your call.Merge-order note: once #244 lands, the first PR touching Go code goes red until the compile break above is fixed; that's the gate doing its job, but fixing the compile break first avoids the red window.
Happy to test a branch either way.