Skip to content

chore(backend): remove dead Dockerfile.mentorship-sync #195

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mlehotskylf wants to merge 2 commits into
base: main
Choose a base branch
from
Open

chore(backend): remove dead Dockerfile.mentorship-sync #195

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6a7352c
chore(backend): remove dead Dockerfile.mentorship-sync
mlehotskylf Jun 22, 2026
84051ba
Merge branch 'main' into chore/remove-dead-mentorship-dockerfile
mlehotskylf Jun 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 0 additions & 36 deletions backend/Dockerfile.mentorship-sync
View file
Open in desktop

This file was deleted.

15 changes: 7 additions & 8 deletions backend/docs/rewrite/02-decisions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -299,18 +299,17 @@ New backend is Go, same DDD pattern as LFF (domain/, usecases/, interfaces/repos

Deployed as a long-running Go HTTP service on Kubernetes, not Lambda. Background jobs become Kubernetes CronJobs (not CloudWatch Events).

### Background jobs — monorepo, separate binaries, separate container images
### Background jobs — monorepo, separate binaries, single container image

All code lives in one repository (monorepo). Each entrypoint under `cmd/` builds to a **separate container image** via its own Dockerfile:
All code lives in one repository (monorepo). Each entrypoint under `cmd/` builds to its own binary, and all binaries are bundled into a **single container image** via `backend/Dockerfile`:
Comment thread
mlehotskylf marked this conversation as resolved.

| Entrypoint | Dockerfile | K8s resource |
| Entrypoint | Binary | K8s resource |
|---|---|---|
| `cmd/api/` | `Dockerfile.api` | `Deployment` |
| `cmd/mentorship-sync/` | `Dockerfile.mentorship-sync` | `CronJob` |
| `cmd/ledger-stats-sync/` | `Dockerfile.ledger-stats-sync` | `CronJob` |
| `cmd/migrate/` | `Dockerfile.migrate` | one-off `Job` |
| `cmd/initiatives-api/` | `/app/initiatives-api` | `Deployment` |
| `cmd/ledger-stats-sync/` | `/app/ledger-stats-sync` | `CronJob` |
| `cmd/mentorship-sync/` | `/app/mentorship-sync` | `CronJob` |

Rationale: a single container serving both HTTP requests and being invoked as a CronJob (via a flag) conflates two distinct runtime responsibilities. Separate images are minimal, contain only the code they need, and make it obvious what each K8s resource is doing. Shared business logic in `internal/` is compiled into each binary — no duplication of source, no runtime coupling.
Rationale: the binaries are compiled statically (`CGO_ENABLED=0`), so bundling them in one image adds negligible size while keeping the build and release pipeline simple — one image to build, push, and track per release. Each K8s resource selects its binary via the container `command`. The CronJob Helm templates default to the same `image.repository`/`image.tag` as the API `Deployment`, overriding only when a different image is explicitly needed.
Comment thread
mlehotskylf marked this conversation as resolved.

### Chi router (same as today)

Expand Down
Loading