Streamlined and added CI steps for docker compose

[tobiasmcnulty]

This PR makes several improvements to streamline the local Docker setup process:

1. Moves the Trac schema/table creation script out of the entry point and into a one-time initialization script, to avoid Postgres errors when it's inadvertently re-run when the web container is restarted.
2. Moves the management commands that create data out of the Docker entrypoint and into their own reset-local-db Makefile target.
3. Updates the Docker instructions with the applicable *.djangoproject.localhost:8000 links and ties back to the non-Docker setup.
4. Runs tests via Docker, to avoid reoccurrences of Docker only install instructions run into database connection error trac does not exist #2193 (or similar)

[Copilot]

Pull Request Overview

This PR streamlines the Docker development setup by improving the initialization process and adding comprehensive test execution via Docker. The changes simplify the dev entrypoint script, reorganize database initialization, and provide clearer documentation for Docker-based development workflows.

• Moved database initialization logic from the dev entrypoint to dedicated initialization scripts
• Added a new Makefile target for resetting local development data
• Enhanced GitHub Actions workflow to run tests via Docker Compose

Reviewed Changes

Copilot reviewed 7 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
docker-entrypoint.dev.sh	Simplified by removing database initialization commands that are now handled elsewhere
docker-entrypoint-initdb.d/02_trac_schema.sh	New script to handle Trac database schema initialization during container startup
docker-compose.yml	Updated volume mounts to use the new initialization directory structure
README.rst	Enhanced Docker documentation with clearer step-by-step instructions and additional usage examples
Makefile	Added reset-local-db target to consolidate database reset commands
.github/workflows/docker-test-build.yml	Added Docker Compose setup and test execution for the tests.txt matrix
.dockerignore	New file to exclude unnecessary directories from Docker build context

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[tobiasmcnulty]

Hi, @easherma! Thanks again for your helping improving the Docker setup at the sprints. Would you be up for giving this a review when you have a moment? No rush.

[ulgens]

I think we can move the migrate command too.

[tobiasmcnulty]

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

[ulgens]

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 👍🏻

[ulgens]

I added a small comment about the migrate command call, but other than it looks nice 🌻

[ulgens]

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

[tobiasmcnulty]

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.

[ulgens]

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.

[tobiasmcnulty]

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.

[tobiasmcnulty]

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

[ulgens]

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.

[SaptakS]

@tobiasmcnulty makes sense to me. I think you need to rebase and resolve conflicts though. Once that is done, I think should be ready for approval.