fix(docker): bump golang-migrate in Dockerfile.test to v4.19.1 #45

Activity

1. cristim

   added

   triagedItem has been triagedItem has been triaged

   priority/p3Polish / idea / may never shipPolish / idea / may never ship

   severity/lowMinor harmMinor harm

   urgency/this-quarterWithin the quarterWithin the quarter

   impact/internalTeam-internal onlyTeam-internal only

   effort/xsTrivial / one-linerTrivial / one-liner

   type/choreMaintenance / non-user-visibleMaintenance / non-user-visible

   on Jun 19, 2026
2. cristim commented on Jul 27, 2026

   

   cristim

   on Jul 27, 2026

   MemberAuthor

   More actions

   Verification sweep against main (101f099fb) on 2026-07-27 finds the premise of this issue no longer exists on main.
   Dockerfile.test no longer installs golang-migrate at all; it became a minimal stdlib-only Go test-runner image, so there is no golang-migrate version left to bump.
   Evidence: commit 877653d38; Dockerfile.test.
   Recommending close as obsolete, not as fixed.
3. cristim commented on Jul 28, 2026

   

   cristim

   on Jul 28, 2026

   MemberAuthor

   More actions

   Reviewed commit: be11bdcb5. Note: origin/main moved to 3e9660d06 during the review; re-verify against current main before changing code, since a finding may have been fixed or moved.

   Dockerfile.test is not the only file left behind by LeanerCloud/cloud-commitments-cli#1240. Dockerfile.dev has the same drift, so both should move in one change rather than leaving a third round of this.

   Where

   • Dockerfile.dev:29 - golang-migrate v4.17.0, with its own SHA256 pair at :25-27
   • Everything else is already on v4.19.1: Dockerfile:49, .github/workflows/ci.yml:164, .github/workflows/database-migration.yml:185,261,328, Makefile:18

   What

   The hot-reload dev container applies migrations with a migrate binary two minors older than production. Dockerfile.dev:7 explicitly instructs:

   Keep this digest in sync with the builder stage in Dockerfile

   for the base image, and the base image did stay in sync; the migrate pin drifted anyway, because nothing checks it.

   Failure scenario

   A migration that relies on a feature or DO-block behaviour introduced between v4.17 and v4.19 applies cleanly in production and fails, or applies differently, in the developer's container. The developer's local run is the cheapest place to catch a migration defect, and it is the one environment running the oldest tool - so the discrepancy is found after the migration has already reached an environment where it costs something to fix.

   Fix direction

   Bump Dockerfile.dev:29 to v4.19.1 with the matching checksums (the same pair this issue already records for Dockerfile.test, since both download the same release artefacts):

   • arm64 SHA256: 2fea2455c0f3f07cc3f4b98471c951ad1a716059574b20b6416bd1e9058751c5
   • amd64 SHA256: 2ac648fbd1b127b69ab5a7b33cf96212178f71e22379fc50573630c6f4c7ce18

   Verify the arch mapping against the release before committing rather than copying blind.

   Worth noting for the same PR: there is no automation that would have caught either drift. The repo has no dependabot.yml or renovate.json, despite Dockerfile:17 and Dockerfile.dev:6 both saying such a config "can automate this if desired". That is filed as a MEDIUM in the grouped chore(ci) issue from this review.
4. cristim

   transferred this issue fromLeanerCloud/cloud-commitments-clion Sep 27, 2026
5. IAmJSD commented on Oct 22, 2026

   

   IAmJSD

   on Oct 22, 2026

   Collaborator

   More actions

   Claiming: working on this
6. IAmJSD

   self-assigned this

   on Oct 22, 2026
7. IAmJSD commented on Oct 22, 2026

   

   IAmJSD

   on Oct 22, 2026

   Collaborator

   More actions

   The fix for this (Dockerfile.dev building migrate from source with the pgx5 tag, matching the production Dockerfile) is in #1210, which now closes this issue too.