Pin caddy-geoip2 to a real upstream tag once one exists

[Wikid82]

Split out from #1304 (task 2) — the only remaining item there; #1304's other four follow-ups landed via #1309, #1313, #1314.

Problem

github.com/zhangjiayin/caddy-geoip2 publishes no semver tags, so Dockerfile:90 carries a Go pseudo-version:

# renovate: datasource=go depName=github.com/zhangjiayin/caddy-geoip2
ARG CADDY_GEOIP2_VERSION=v0.0.0-20260623062220-3675c6e7e63d

Renovate cannot track a pseudo-version, so this pin never gets update PRs.

Mitigation already in place

CADDY_GEOIP2_VERSION is part of the toolchain content-hash key (scripts/toolchain-key.sh), and toolchain-key.bats has a sensitivity test (changes when the CADDY_GEOIP2_VERSION plugin pin is bumped). So any manual bump moves the key and is caught by verify-toolchain-pin — it can't drift silently. This is not urgent; it's a tracking placeholder.

Action when upstream cuts a tag

1. Bump CADDY_GEOIP2_VERSION to the real vX.Y.Z tag.
2. Confirm the # renovate: datasource=go comment resumes tracking (it should, once a semver tag exists).
3. Let toolchain-image.yml rebuild + the freshness guard sync the pin.

Watch

Upstream releases: https://github.com/zhangjiayin/caddy-geoip2/tags

[Wikid82]

Update: upstream now has real semver tags (v1.0–v1.3), and Charon is already building against v1.3. The current pin v0.0.0-20260623062220-3675c6e7e63d embeds commit 3675c6e7e63d, which is the v1.3 tag (published 2026-06-23).

So this is no longer 'wait for upstream' — it's a cosmetic string swap: CADDY_GEOIP2_VERSION v0.0.0-…3675c6e7e63d → v1.3. Same source commit → functionally identical binary; the toolchain key moves (guard-caught) and Renovate tracking resumes.

Upstream health: last push 2026-06-23 (~2.5mo), 56⭐, 0 open issues, not archived; recent commits are genuine maintenance (ServeHTTP data-race fix, dir-creation bugfix, added tests). Low-activity but alive. Alternative (porech/caddy-maxmind-geolocation) is a request matcher, not a placeholder provider — switching would require rewriting the {geoip2.country_code} CEL expression logic in backend/internal/caddy/config.go; not worth it now.

PR to pin v1.3 incoming.

[Wikid82]

Correction to the previous update. Upstream's v1.0–v1.3 tags are two-part (vX.Y), not canonical vX.Y.Z semver. Go's module system only recognizes 3-part version tags, so these are invisible to go, xcaddy, and Renovate's datasource=go:

go list -m -versions github.com/zhangjiayin/caddy-geoip2   -> (empty)
go list -m ...@v1.3     -> no matching versions for query "v1.3"
go list -m ...@v1.3.0   -> unknown revision v1.3.0
go list -m ...@latest   -> v0.0.0-20260623062220-3675c6e7e63d
xcaddy build ... --with github.com/zhangjiayin/caddy-geoip2@v1.3   -> [FATAL] v1.3: invalid semantic version

Attempted in #1330 (closed) — the build fails on both arches.

So there is still no consumable version. The pseudo-version pin (v0.0.0-20260623062220-3675c6e7e63d, = the v1.3 commit) is the only form Go/xcaddy accept and remains correct; it's a toolchain-key input so any manual bump is guard-caught.

Paths forward

1. Preferred: open an upstream issue/PR asking @zhangjiayin to re-tag v1.3.0 (canonical). One-line fix for them; then this pin becomes trackable.
2. Wait for upstream to cut a proper vX.Y.Z on their own.
3. If upstream goes unresponsive/dark, reassess porech/caddy-maxmind-geolocation (needs rewriting {geoip2.*} CEL logic in backend/internal/caddy/config.go).

Keeping open under path 1/2.

[Wikid82]

Decision (2026-09-09): hold on the current pseudo-version pin — it builds fine and is guard-caught. No upstream nag for now.

Plan:

• Keep watching https://github.com/zhangjiayin/caddy-geoip2/tags — act whenever they cut the next release (canonical vX.Y.Z → just swap the pin; another vX.Y → stay on the pseudo-version of that commit).
• Last upstream activity was 2026-06-23. If there's still no release/commit activity by ~2026-12, treat the module as effectively unmaintained and evaluate migrating to porech/caddy-maxmind-geolocation (cost: rewrite the {geoip2.country_code}-style CEL expressions in backend/internal/caddy/config.go to that module's request-matcher API).

No action until then.

[zhangjiayin]

Upstream update: we have published the canonical Go module release v1.3.0.

It points to the same commit (3675c6e7e63d) as the current pseudo-version pin, so switching the pin should not change the built source. The Go module proxy now resolves github.com/zhangjiayin/caddy-geoip2@v1.3.0 successfully.