-
Notifications
You must be signed in to change notification settings - Fork 11
Enable python debugger for main Django container #953
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.
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
Conversation
✅ Deploy Preview for antenna-preview canceled.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR enables Python debugging capabilities for the main Django container by configuring debugpy to listen on port 5679. The change allows developers to attach a remote debugger to the Django application running in Docker for improved development experience.
- Modified Django container startup command to run with debugpy for remote debugging
- Added port mapping for debugger communication (5679:5679)
- Created separate VS Code launch configuration for Django debugging
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docker-compose.yml | Configured Django container to run with debugpy and exposed debugger port |
| .vscode/launch.json | Added Django-specific debugger configuration and renamed existing Celery config |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
|
@mohamedelabbas1996 where did you add your django debugger updates? I know I saw them somewhere! |
|
@carlosgjs Will you review this and also update celeryworker to use the same method? |
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughThis pull request introduces remote debugging support for Django development environments using debugpy. Debug configurations are added to VS Code's launch settings, and the Django startup process is modified to conditionally activate debugpy when Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor Developer
participant Docker as Docker Container
participant Debugpy as debugpy
participant Uvicorn as Uvicorn/ASGI
participant VSCode as VS Code Debugger
Developer->>Docker: Start container with DJANGO_DEBUG=1
Docker->>Debugpy: Launch Python with debugpy (port 5679)
activate Debugpy
Debugpy->>Debugpy: Listen on 0.0.0.0:5679
Debugpy->>Uvicorn: Start Uvicorn with reload
activate Uvicorn
Developer->>VSCode: Attach debugger to localhost:5679
VSCode->>Debugpy: Connect to debugpy session
activate VSCode
Developer->>Uvicorn: Send request
Uvicorn->>VSCode: Breakpoint hit, control to debugger
rect rgb(200, 220, 255)
Note over Developer,VSCode: Debug session active
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.vscode/launch.json(2 hunks)compose/local/django/start(1 hunks)docker-compose.yml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: test
🔇 Additional comments (1)
.vscode/launch.json (1)
1-35: LGTM! Clean separation of debug configurations.The VS Code launch configurations correctly separate Django (port 5679) and Celery (port 5678) debugging, with consistent pathMappings for both. The naming clearly distinguishes the two services.
| if [ "$DJANGO_DEBUG" = "1" ]; then | ||
| echo "Starting Django under debugpy..." | ||
| python -m debugpy --listen 0.0.0.0:5679 \ | ||
| -m uvicorn config.asgi:application \ | ||
| --host 0.0.0.0 \ | ||
| --reload \ | ||
| --reload-include '*.html' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix variable handling and add exec for proper signal propagation.
Two issues with the debug path:
-
Missing default value: With
set -o nounset(line 5), the script will fail ifDJANGO_DEBUGis undefined. Use parameter expansion to provide a default. -
Missing
exec: The debug branch doesn't useexec(unlike line 18), leaving the shell process alive. This prevents proper signal handling (e.g., SIGTERM won't reach the Python process), causing graceful shutdown issues.
Apply this diff:
-if [ "$DJANGO_DEBUG" = "1" ]; then
+if [ "${DJANGO_DEBUG:-0}" = "1" ]; then
echo "Starting Django under debugpy..."
- python -m debugpy --listen 0.0.0.0:5679 \
+ exec python -m debugpy --listen 0.0.0.0:5679 \
-m uvicorn config.asgi:application \
--host 0.0.0.0 \
--reload \
--reload-include '*.html'🤖 Prompt for AI Agents
In compose/local/django/start around lines 9 to 15, the debug branch fails under
set -o nounset when DJANGO_DEBUG is undefined and does not use exec so signals
don't propagate to the Python process; update the condition to use parameter
expansion (e.g. ${DJANGO_DEBUG:-0}) to provide a default value and prepend exec
to the python -m debugpy command so the shell is replaced by the Python process
for proper signal handling.
| command: > | ||
| python -m debugpy --listen 0.0.0.0:5679 -m uvicorn config.asgi:application --host 0.0.0.0 --reload --reload-include '*.html' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Critical: Command overrides the conditional startup logic in the start script.
The hardcoded command completely bypasses the compose/local/django/start script, which contains conditional logic to enable debugpy only when DJANGO_DEBUG=1. This means:
- The debugger will always be active, regardless of the
DJANGO_DEBUGvariable - The conditional startup logic in the start script becomes unreachable and useless
- There's no way to disable debugging without modifying docker-compose.yml
Solution: Remove the command override to allow the start script's conditional logic to work:
- command: >
- python -m debugpy --listen 0.0.0.0:5679 -m uvicorn config.asgi:application --host 0.0.0.0 --reload --reload-include '*.html'Then ensure DJANGO_DEBUG=1 is set in .envs/.local/.django to enable debugging during development, or add it to the environment section:
environment:
- DJANGO_DEBUG=1🤖 Prompt for AI Agents
In docker-compose.yml around lines 37-38, the hardcoded command that launches
debugpy/uvicorn overrides the service's start script and forces the debugger on;
remove this command override so the service uses compose/local/django/start
(which contains the DJANGO_DEBUG conditional), and ensure DJANGO_DEBUG is set to
enable debugging when desired (either by adding DJANGO_DEBUG=1 to
.envs/.local/.django or by adding it under the service's environment section).
|
Closing for #1048 instead. Thanks for your help @mohamedelabbas1996! I kept the env variable flag. |
TODO
Summary by CodeRabbit