Should we add Dockerfile #232

Activity

1. gowrishacv commented on Apr 28, 2026

   

   gowrishacv

   on Apr 28, 2026

   More actions

   @ppetko are you still planning to take this on? Happy to defer if you are. If you've moved on or want a hand, I'm glad to pick it up.

   A few thoughts in case it's useful for whoever does it:

   • Containerfile vs Dockerfile: a single Dockerfile works with both Docker and Podman (Podman reads Dockerfile by default), so one file should cover both runtimes unless there's a specific reason to split.
   • Base image: python:3.12-slim is a safe default. Alpine saves ~30 MB but can hit musl issues with some Python wheels.
   • Runtime needs git: incremental updates rely on git ls-files, so git has to be installed in the runtime stage.
   • Non-root user (uid 1001) and a CRG_VERSION build arg pinned to PyPI by default, with override for dev.
   • Multi-arch: amd64 + arm64 via buildx is low-effort to add upfront and saves a follow-up PR.

   @tirth8205 any preferences on scope (Dockerfile only vs Dockerfile + GHCR publish workflow) before someone starts?

   👍React with 👍1Reacted by pierow2k
2. tirth8205 commented on Jul 27, 2026

   

   tirth8205

   on Jul 27, 2026

   Owner

   More actions

   Reviewed current main: there is still no Dockerfile/Containerfile and no container build/publish workflow, so this request is not implemented. A mergeable contribution should use one Dockerfile compatible with Docker and Podman, include git in the runtime image, run as a non-root user, and validate both amd64 and arm64 builds plus a real graph build inside the container. Keeping this open for that implementation; GHCR publishing can remain a separate follow-up if the first PR only adds the image definition.

   👍React with 👍1Reacted by Gowrisha C. Vishwa Kumar
3. gowrishacv commented on Aug 5, 2026

   

   gowrishacv

   on Aug 5, 2026

   More actions

   Thanks for confirming the requirements. I’d like to work on the first PR with the focused scope you described: one Dockerfile compatible with Docker and Podman, git available at runtime, and execution as a non-root user.

   I’ll validate builds for both linux/amd64 and linux/arm64, and verify a real graph build inside the container. I’ll leave GHCR publishing for a separate follow-up.
4. tirth8205

   added

   enhancementNew feature or requestNew feature or request

   on Sep 16, 2026
5. tirth8205 commented on Sep 16, 2026

   

   tirth8205

   on Sep 16, 2026

   Owner

   More actions

   @gowrishacv yes, go ahead, and sorry for leaving you hanging since August.

   Nobody else is on it. I checked staging today: still no Dockerfile, no Containerfile, no container workflow.

   Your scope is the right one and the requirements in my earlier comment stand. To be concrete about what I will check when the PR arrives:

   • one Dockerfile that works under both docker build and podman build
   • git present in the final image, since collect_all_files() and get_changed_files() shell out to it and the graph is empty without it
   • non-root user at runtime
   • linux/amd64 and linux/arm64 both build
   • a real code-review-graph build runs inside the container against a mounted repo and produces a non-zero node count, with the output in the PR

   Two things worth deciding up front:

   • .code-review-graph/ is written next to the repo, so the mounted repo directory has to be writable by the non-root uid. Say in the README what docker run line you expect people to use, or the first bug report will be a permissions error.
   • Do not bake a graph into the image, and do not run a build at image build time.

   Your point about Alpine and musl wheels matches what I would pick. python:3.12-slim is fine.

   GHCR publishing stays out of this PR as you said.
6. gowrishacv commented on Sep 17, 2026

   

   gowrishacv

   on Sep 17, 2026

   More actions

   Thank you for confirming the scope. I’ll start working on it and will open a focused PR against staging with the requested validation results.