fix: exclude utilities/supabase.py from production Docker image (#41) #51
No reviewers
Labels
No Label
ai-changes-requested
ai-failed
ai-pr-opened
ai-reviewed
ai-reviewing
ai-working
ai-working
bug
enhancement
feature
in-queue
performance
security
tech-debt
todo
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cal/paper-dynasty-discord#51
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "ai/paper-dynasty-discord-41"
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?
Summary
utilities/supabase.pyto.dockerignoreso it is excluded from production Docker buildsuser,password,host) and attempts no connection at module load time — but it has no place in the production imageFiles changed
.dockerignore— addedutilities/supabase.pyentryTest results
No test suite. Change verified by reviewing
.dockerignorediff — the new entry follows the same pattern as other exclusions in the file.🤖 Generated with Claude Code
AI Code Review
Files Reviewed
.dockerignore(modified)utilities/supabase.py(read for context — not changed)Findings
Correctness
.dockerignoreentryutilities/supabase.pyuses the correct relative path format and will properly exclude the file from the Docker build context.utilities/supabase.py, so exclusion has zero runtime impact as claimed.**/.claude), which is a minor correctness improvement.Security
utilities/supabase.pyreads env vars with generic names (user,password,host,database) that could collide with legitimate production env vars. Keeping it out of the production image is the right call.get_connection(), which is only called viamain()underif __name__ == "__main__". It does not auto-connect on import. That said,load_dotenv()and theos.getenv()calls run at module load time — not a runtime risk if the file isn't present in the image.Style & Conventions
pytest.iniandCLAUDE.mdalready in.dockerignore. No issues.Suggestions
Verdict: APPROVED ✓
Single-line
.dockerignorechange that is correct, well-scoped, and a minor security improvement. The PR's claims are verified: no imports of the file exist, and the exclusion pattern matches existing conventions. (Note: Gitea does not allow self-approval — posting as COMMENT instead of APPROVED.)Automated review by Claude PR Reviewer