Skip to content
Open
Show file tree
Hide file tree
Changes from 6 commits
Commits
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
16 changes: 16 additions & 0 deletions .dockerignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Copied from .gitignore
__pycache__
data
*.pyc
*.db
locale/*/LC_MESSAGES/django.mo
*/locale/*/LC_MESSAGES/django.mo
.sass-cache/
.coverage
.direnv
.envrc
djangoproject/cache
djangoproject/static/css/*.map
djangoproject/static/css/*.css
# Additional ignores for Docker
.git/
16 changes: 15 additions & 1 deletion .github/workflows/docker-test-build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -25,10 +25,24 @@ jobs:
- name: Checkout repository
uses: actions/checkout@v4

- name: Test docker image build (local development)
- if: matrix.req_file != 'tests.txt'
name: Test docker image build (${{ matrix.req_file }})
uses: docker/build-push-action@v6
with:
context: .
push: false
build-args: |
REQ_FILE=requirements/${{ matrix.req_file }}
Comment on lines +28 to 35
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For production, we just build the image, and then nothing else? 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just building the image will be a weak test (and burn CI minutes). Since we are building the image, we might also want to check the startup, something like:

- if: matrix.req_file == 'prod.txt'
  name: Test production image starts successfully
  run: |
    docker compose up -d
    sleep 5
    docker compose ps
    docker compose logs
    # Maybe curl a health endpoint


- if: matrix.req_file == 'tests.txt'
name: Set up Docker Compose
uses: docker/setup-compose-action@v1

- if: matrix.req_file == 'tests.txt'
name: Run the tests via Docker
run: |
docker compose build
docker compose up -d db
# Wait for Postgres to be ready
docker compose exec db sh -c 'until pg_isready ; do sleep 1; done'
docker compose run --rm web make ci
Comment on lines 37 to 45
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this affect the existing test workflow? It looks like we will be running tests in CI twice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like we will be running tests in CI twice.

That's correct, as a regression test for #2193 / assurance that the docker compose instructions aren't broken again.

Longer term it might be nice to consolidate the settings so they're the same for local dev docker and non-docker, and run tests only in docker, but I don't mind running them twice in the interim.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assurance that the docker compose instructions aren't broken again.

Wouldn't be enough to run check to validate the setup works? I feel like make ci  is a bit of overkill.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check wouldn't have caught the Docker-only test failures fixed by the change to PARENT_HOST, but it looks like we can remove that altogether now (done).

I don't see the downside to running tests with both configurations temporarily, but I also don't mind removing make ci here if it seems unnecessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any other feedback on this (either way), @django/django-website ?

Copy link
Member

@ulgens ulgens Oct 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My vote here would be to make Docker-based testing the main/only testing suite in CI in long term but I'm not sure it in this PR's scope.

7 changes: 7 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -30,3 +30,10 @@ test:

watch-scss:
watchmedo shell-command --patterns=*.scss --recursive --command="make compile-scss-debug" $(SCSS)

reset-local-db:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can move the migrate command too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I don't mind leaving migrate where it is: Running migrations on container startup seems far less detrimental than wiping all the data from the database, and it might even be expected by some developers.

What do others think? @django/django-website

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running migrations on container startup

This creates problems when the contributor doesn't want to immedietaly apply the migrations. I think it's better that non of the data related operations are applied automatically, but I agree that contexts are different 👍🏻

python -m manage flush --no-input
python -m manage loaddata dev_sites
python -m manage loaddata doc_releases
python -m manage loaddata dashboard_production_metrics
python -m manage update_metrics
20 changes: 17 additions & 3 deletions README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -343,12 +343,26 @@ Running Locally with Docker

docker compose up

3. View the site at http://localhost:8000/

4. Run the tests::
3. Run the tests::

docker compose run --rm web python -m manage test

4. Load the sample / local dev data::

docker compose run --rm web make reset-local-db

If preferred, refer to the "Install and run locally from a virtual environment"
for more granular management commands to load specific data sets.

5. View the site at http://www.djangoproject.localhost:8000/
or http://dashboard.djangoproject.localhost:8000/.

6. For docs, download the documentation (takes awhile)::

docker compose exec -it web python -m manage update_docs

7. View the docs at http://docs.djangoproject.localhost:8000/.

Pre-commit checks
-----------------

Expand Down
5 changes: 0 additions & 5 deletions djangoproject/settings/docker.py
Original file line number Diff line number Diff line change
Expand Up @@ -24,8 +24,3 @@
SECRET_KEY = os.environ.get("SECRET_KEY")

ALLOWED_HOSTS = [".localhost", "127.0.0.1", "www.127.0.0.1"]

LOCALE_MIDDLEWARE_EXCLUDED_HOSTS = ["docs.djangoproject.localhost"]

# django-hosts settings
PARENT_HOST = "djangoproject.localhost:8000"
7 changes: 6 additions & 1 deletion docker-compose.yml
Original file line number Diff line number Diff line change
Expand Up @@ -42,4 +42,9 @@ services:
timeout: 10s
retries: 10
volumes:
- ./initdb/tracdb.sql:/docker-entrypoint-initdb.d/tracdb.sql
# Mount the Postgres initialization scripts
- ./docker-entrypoint-initdb.d:/docker-entrypoint-initdb.d
# This file contains the initial Trac database schema, but needs
# to be loaded into the database manually (via 02_trac_schema.sh)
# since it applies to the trac database, not the main Django database.
- ./tracdb/trac.sql:/trac.sql
File renamed without changes.
3 changes: 3 additions & 0 deletions docker-entrypoint-initdb.d/02_trac_schema.sh
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
#!/bin/sh

PGPASSWORD=secret psql --username=code.djangoproject --dbname=code.djangoproject < /trac.sql
9 changes: 0 additions & 9 deletions docker-entrypoint.dev.sh
Original file line number Diff line number Diff line change
@@ -1,16 +1,7 @@
#!/bin/sh

python -m manage flush --no-input
PGPASSWORD=secret psql --host db --port 5432 --username=code.djangoproject --dbname=code.djangoproject < tracdb/trac.sql
python -m manage migrate
make compile-scss # must come before collectstatic
python -m manage collectstatic --no-input --clear
python -m manage loaddata dev_sites
python -m manage loaddata doc_releases
# git config --global url."https://".insteadOf git://
# python -m manage update_docs
python -m manage loaddata dashboard_production_metrics
# python -m manage loaddata dashboard_example_data
python -m manage update_metrics

exec "$@"