server/go.mod reached github.com/hanzoteam/agents/v2 through a replace naming
an absolute path under one machine's agent scratchpad. That directory exists on
no other machine and on no runner, so every build off it opens go.mod and stops:
reading .../scratchpad/agents/go.mod: no such file or directory
The fork itself is pushed — hanzoteam/agents master declares the rebranded
module path — so a pseudo-version pins the same tree, verified against the
checksum database instead of a filesystem. Its newest TAG cannot be used: v2.5.1
predates the rename and still declares mattermost-plugin-agents, which is both a
path mismatch and the upstream public module coming back into the graph.
Measured after: the binary builds, `mattermost version` answers, and
`go list -deps ./cmd/mattermost` names one public/plugin, ours, with no package
from mattermost/mattermost in it at all.
Co-authored-by: Hanzo Dev <[email protected]>
Renaming server/public to github.com/hanzoai/team/server/public left the old
path unclaimed, and mattermost-plugin-ai still imports it — so the binary
linked public/model TWICE, ours and upstream's, and public/plugin's
gob.Register calls ran twice under one name:
panic: gob: registering duplicate types for "[]*model.SlackAttachment":
[]*model.MessageAttachment != []*model.SlackAttachment
at init, before main. The server has not been able to start since that rename
landed, which is why the deployment is still answering from an older build.
server/v8 keeps its new name; nothing outside this repo imports it. public
does not, because its path is not a brand — it is the plugin API, and every
plugin written against Mattermost imports it by that name. Our own agents
fork is proof: it carries a replace pointing that exact path back here.
Reverting the public half is what makes the two copies one again. Measured
after: `go list -deps ./cmd/mattermost` names exactly one public/model, the
binary starts, and it serves.
Every package in this fork announced itself as github.com/mattermost/mattermost —
in 4,553 import lines, in both go.mod module declarations, and in the workspace.
A fork whose own import path names another company is one nobody can read as
theirs, and it is the first thing anyone sees at the top of every file.
server/v8 and server/public are now github.com/hanzoai/team/server/…, rewritten
mechanically and verified: `go build ./...` is clean for both modules and `go vet`
passes.
Three things are deliberately UNTOUCHED, because they are other people's names
rather than our branding: mattermost-plugin-ai and mattermost-plugin-mscalendar
are real dependencies we consume, github.com/mattermost/msgpack is a real
dependency, and the github.com/mattermost/mattermost/pull/… links in comments
point at real upstream discussions that renaming would turn into dead links.
server/public needs a `replace` to resolve locally now: the require still names a
version, and no proxy serves our path. The workspace alone does not satisfy a
require, which is exactly how this failed the first time.
Co-authored-by: Hanzo Dev <[email protected]>
The gate failed on `[build failed]` for symbols that are in this tree. Upstream
publishes server/public and pins v0.4.0 of it; we changed server/public, so
anything that reads the pin compiles against a release with no HanzoSettings, no
ServiceHanzo, no UserAuthServiceHanzo. The workspace is what makes ./public mean
this tree, and it was ignored — so `go build`, `go test`, the gate and the image
each had to arrange it privately, and the one that did not simply failed.
Tracking it states the fact once. The image build no longer arranges anything.
Also:
-tags production. Without it server/public/model selects the DEV service
environment through a build constraint, and a shipped binary points at dev
telemetry and licensing while looking entirely normal.
The runtime tree — data, logs, config, plugins, client/plugins — is made in a
stage that has a shell, because distroless does not and the server has nowhere
to write without them.
The document-extraction binaries are dropped rather than carried. pdftotext
wants GLIBC_2.38 and libstdc++ on a 2.36 base that has no libstdc++ at all;
wvText is a shell script and there is no shell. The library COPYs beside them
read /usr/lib while Ubuntu keeps those under /usr/lib/x86_64-linux-gnu, and a
--from glob matching nothing is a silent no-op — so upstream's image ships five
binaries with no libraries and reports success. Restoring extraction needs a
base that can run it; that is its own decision.
.dockerignore, because .git alone is 1.2 GiB of context and node_modules is a
working tree's results standing in for the build's.
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev