DoDiODev opened a new pull request, #9028: URL: https://github.com/apache/devlake/pull/9028
## 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/[email protected]/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 #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](https://github.com/DoDiODev/devlake/actions/runs/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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
