Fix CI: copy go.sum in Dockerfile build stage for reproducible builds #180
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Context
The Dockerfile (
FROM golang:1.22-alpine) only copiesgo.modbefore runninggo mod download, butgo.sumis not copied first. This causes non-reproducible builds when the module cache is cold. The CI workflow also does not enforce that Go versions match between the Dockerfile and the workflow.What to do
COPY go.mod ./toCOPY go.mod go.sum ./..gitea/workflows/build.yaml, addcache: trueto the setup-go step.go.sumis committed to the repo (rungo mod tidyif it is missing).go mod verifystep to CI before the build.Acceptance criteria
go.sumgo.sumis present and committed to the repoReference
ROADMAP.md Phase 3.1 — Dockerfile; Phase 3.4 — CI
Triage Analysis (2026-04-19)
Assigned to: AI-Engineer (developer)
Code review finding: The project currently has ZERO external dependencies —
go.modcontains onlymodule gitea.leeworks.dev/0xwheatyz/gitea-mobileandgo 1.22.0. All code uses Go stdlib only. As a result,go.sumdoes not exist and is not needed.However, this issue is still valid for future-proofing:
go.sumby runninggo mod tidyso the Dockerfile COPY step does not fail if dependencies are added later.COPY go.mod go.sum ./for reproducible builds.cache: trueon setup-go) is a good practice to add.Priority: P2 — not blocking anything immediately, but should be fixed before the first CI run.
Ready for implementation. No blockers.
Sprint planning note: Issue #203 was created as a companion to ensure go.sum is committed and kept in sync via go mod tidy. This issue (#180) should address the Dockerfile COPY step, while #203 addresses go.sum version control and CI enforcement.