publish Docker images to GHCR and optimize web Dockerfile

[Mateusz-Krajewski]

Summary

Improve deployments using pre-built container images and speed up / slim down the PHP Apache image build.

Changes

• GitHub Actions (docker-publish): Build and push cloudlog-web and cloudlog-db to GitHub Container Registry (ghcr.io). Tags follow semver (MAJOR.MINOR.PATCH), plus workflow_dispatch. Multi-arch linux/amd64 and linux/arm64 only (no linux/arm/v7 for the DB image—the official MariaDB image does not ship that variant).
• Cypress CI: Start the stack from docker-compose.prod.yml (pull then up).
• Web Dockerfile: Single layer for APT cleanup + PHP extensions (docker-php-ext-install -j$(nproc)), --no-install-recommends, enable curl PHP extension (used by the app), write uploads.ini with printf, fewer layers overall.
• .dockerignore: Much smaller build context by excluding large dirs
• fix: disable pasting .env file to image (.env from docker-compose dont work)

Notes for reviewers

• The first successful workflow run must publish images before docker compose pull works in prod/CI without a local build.
• GHCR package visibility may need to be set to public if you want anonymous image pulls.

[Mateusz-Krajewski]

@magicbug

[magicbug]

Thanks for putting this together — I appreciate the work that went into it.

I'm going to pass on merging this. The Compose file in the repo is there for local development, and that's as far as I want to take Docker in Cloudlog. Publishing official images (and changing the default stack around GHCR) would mean taking on Docker support for users, which I'm not in a position to do.

You're still free to run Cloudlog in containers however you like; that part is up to each installer. I just don't want Cloudlog itself to ship and support pre-built images.

Thanks again for the contribution.

[Mateusz-Krajewski]

Thanks for putting this together — I appreciate the work that went into it.

I'm going to pass on merging this. The Compose file in the repo is there for local development, and that's as far as I want to take Docker in Cloudlog. Publishing official images (and changing the default stack around GHCR) would mean taking on Docker support for users, which I'm not in a position to do.

You're still free to run Cloudlog in containers however you like; that part is up to each installer. I just don't want Cloudlog itself to ship and support pre-built images.

Thanks again for the contribution.

Fair enough, I completely understand your decision regarding maintenance overhead.

As a side note, you might want to look into the current docker-compose.yml setup:

 services:
  web:
    build: .
    env_file:
      - .env

Currently, the application doesn't actually consume the variables passed via env_file here. It might be worth explicitly documenting whether configuration should be handled via a copied .env file or native environment variables, as well as allowing define('ENVIRONMENT', 'development'); to be toggled via an environment variable rather than hardcoded in the source.

Thanks for reviewing!