build(deps): bump libgit2 1.3 → 1.5.0 and git2go v33 → v34

[DoDiODev]

Summary

Bumps the Go binding libgit2/git2go from v33.0.6 to v34.0.0 and the
native libgit2 library from 1.3.x to 1.5.0 at every install site.

git2go majors are bound to exactly one libgit2 minor via the C ABI — there is
no supported version range. The pair must therefore be pinned in lockstep
everywhere, which is what this PR does.

Current pinning (before this PR) is 3.5 years old: libgit2 1.3.0 was released in
Sep 2021, 1.5.0 in Jul 2022 and carries bug/security fixes of the 1.4 and 1.5
series (including several CVE-relevant fixes in the smart-transport/packfile
code paths).

Why v34 / 1.5.0 and not something newer?

libgit2	git2go	Import path	Status
1.5.0	v34	github.com/libgit2/git2go/v34	target — highest importable pair
1.3.x	v33	github.com/libgit2/git2go/v33	current / documented rollback
1.5.0	v35	—	tag exists, but its go.mod still declares the module path .../git2go/v34 → not go get-able
1.6–1.9	—	—	no git2go release exists for these

So v34.0.0 + libgit2 1.5.0 is the ceiling that the canonical, upstream
libgit2/git2go module allows today (verified again on 2026-08-03: the tag list
is unchanged, v35.0.0 still points at the same broken commit as v34.0.0).

No Go code changes are required: the git2go Go API is identical between
v33.0.6 and v34.0.0 for every call used by gitextractor
(DiffOptions.NotifyCallback, Odb.ForEach, NewBranchIterator, Branch.*,
Reference.Target, DiffLine.Origin, DefaultDiffOptions). The major bump only
reflects the C ABI/libgit2 version.

What changed

File	Change
backend/go.mod / backend/go.sum	git2go/v33 v33.0.6 → git2go/v34 v34.0.0 (go mod tidy)
backend/plugins/gitextractor/parser/repo_libgit2.go	import path /v33 → /v34
backend/plugins/gitextractor/models/diffline.go	import path /v33 → /v34
backend/Dockerfile	libgit2 tarball v1.3.0 → v1.5.0 (both cross-build arches)
backend/Dockerfile.local	libgit2 tarball v1.3.0 → v1.5.0
devops/docker/lake-builder/Dockerfile	libgit2 tarball v1.3.2 → v1.5.0; plus two build fixes, see below
.devcontainer/Dockerfile	git clone -b v1.3.0 → -b v1.5.0
backend/plugins/gitextractor/README.md	documented local build version

Out of scope on purpose: devops/docker/alpine-dbt/Dockerfile (apk add libgit2-dev) feeds the dbt image, not the CGO gitextractor build.

⚠️ Action required by the maintainers: republish mericodev/lake-builder

All Go CI jobs (test.yml, golangci-lint.yml, test-e2e.yml,
migration-script-lint.yml) run inside the prebuilt container
mericodev/lake-builder:latest. That image currently ships libgit2 1.3.2
(and Go 1.20.4), so git2go v34 cannot compile in it:

/go/pkg/mod/github.com/libgit2/git2go/v34@v34.0.0/Build_system_dynamic.go:12:3:
  error: #error "Invalid libgit2 version; this git2go supports libgit2 between v1.5.0 and v1.5.0"

This PR's CI will therefore be red until the image is rebuilt — the image is
only published by build-builder.yml, which triggers on a builder-* tag and
needs Docker Hub credentials, i.e. only maintainers can do it.

Two extra commits are included so that the image can actually be rebuilt —
devops/docker/lake-builder/Dockerfile is currently unbuildable on main,
independently of this change:

1. golang:1.26-bullseye (introduced by chore: upgrade go to 1.26 #8875) was never published — Go dropped
   the bullseye variants. The stage does not use Go at all, so it now uses plain
   debian:bullseye with wget/ca-certificates installed explicitly.
2. The libgit2 cmake step failed with "Could not find a python interpreter,
   which is needed to build the tests" on that base → -DBUILD_TESTS=OFF
   (libgit2's own test suite was never built here anyway).

Suggested merge order: merge this PR, then push a builder-* tag so
mericodev/lake-builder:latest is rebuilt with libgit2 1.5.0. Happy to split
the two Dockerfile fixes into a separate, earlier PR if that is preferred.

Validation

CI equivalent (all green): since the published builder image cannot be used,
the identical job matrix was run in a fork workflow that builds
devops/docker/lake-builder/Dockerfile itself and runs every Go job inside it —
run 30828741519,
8/8 jobs successful: builder image, lint (go), unit-test, e2e (mysql),
migration-script-lint, config-ui, ASF license header, grafana dashboards.

Additionally, locally on macOS (arm64) against a self-built libgit2 1.5.0 prefix:

• ✅ go build ./plugins/gitextractor/... — compiles and links against libgit2 1.5.0
• ✅ standalone git2go v34 smoke program (open repo, iterate ODB/branches/tags, diff lines)
• ✅ make mock, plugin build (gitextractor.so builds as a Go plugin)
• ✅ make unit-test — no failures
• ✅ docker build -f backend/Dockerfile.local — green
• ⚠️ docker build -f backend/Dockerfile (multi-arch cross build) fails locally
  with and without this change — the identical failure reproduces on
  unmodified main with libgit2 1.3.0, i.e. it is a pre-existing limitation of
  the local (Rancher Desktop/emulated) environment, not a regression of this PR.
  Left to CI to verify.
• ⚠️ .devcontainer/Dockerfile cannot be built locally either: its base image
  mcr.microsoft.com/devcontainers/go:1-1.26-bookworm does not exist (pre-existing,
  unrelated to this change).

Note for contributors (post-merge)

Anyone building gitextractor locally must rebuild/reinstall libgit2 1.5.0 —
an existing 1.3.x prefix is ABI-incompatible with git2go v34 and will fail at link
or, worse, at runtime. Devcontainer users need a "Rebuild Container".

Question to the maintainers

libgit2/git2go has been inactive since Oct 2022; its highest importable
module is v34 (libgit2 1.5), and the v35.0.0 tag is broken. That means
apache/devlake is permanently cut off from libgit2 ≥ 1.6 security and bug fixes
as long as the canonical module is used.

There is an actively maintained fork, coveord/git2go (last commit
2025-11-25), which publishes correctly tagged majors: v35 → libgit2 1.6,
v36 → libgit2 1.7. It keeps the canonical module path, so using it requires a
Go replace directive (or vendoring) — it is not a drop-in.

Would the maintainers be open to switching to coveord/git2go in a follow-up
PR? This PR deliberately stays on the canonical module (v34 / libgit2 1.5.0)
and does not introduce the fork.

Rollback

Revert to the status quo git2go v33.0.6 + libgit2 1.3.x — same Dockerfile
structure, only the version numbers differ.