ci: ran pull request tests on the itkdev image directly

The container ran as `deploy` (uid 1000) while the CI checkout belongs to
the runner's uid, so composer could not create `vendor`. The compose user
now comes from COMPOSE_USER, which the workflow sets to the checkout
owner; the image carries a `runner` user at that uid, so it still has a
writable home.

Only `bin/create-release` needs the rsync the Dockerfile adds, so tests
and linting run on itkdev/php8.3-fpm directly and no longer build an
image. The built image moved to a `php-release` service, used by the
release workflow alone.

Author: tuj

.github/workflows/pr.yml

@@ -21,13 +21,15 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v7
 
-      # Tests run in the project's own compose stack, so the PHP version comes
-      # from the Dockerfile rather than being repeated here.
-      - name: Build the php image
-        run: docker compose build php
+      # The checkout belongs to the runner's uid, so the container has to write
+      # to the bind mount as that uid rather than as the image's `deploy` user.
+      - name: Run the container as the checkout owner
+        run: echo "COMPOSE_USER=$(id -u):$(id -g)" >> "$GITHUB_ENV"
 
+      # Tests run in the project's own compose stack, so the PHP version comes
+      # from compose.yml rather than being repeated here.
       - name: Install dependencies
-        run: docker compose run --rm --no-deps php composer install --no-interaction --prefer-dist --no-progress
+        run: docker compose run --rm --no-deps phpfpm composer install --no-interaction --prefer-dist --no-progress
 
       - name: Run tests
-        run: docker compose run --rm --no-deps php vendor/bin/phpunit
+        run: docker compose run --rm --no-deps phpfpm vendor/bin/phpunit

.github/workflows/release.yml

@@ -14,7 +14,7 @@ jobs:
   release:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v7
 
       - name: Build and create release
         env:
@@ -34,7 +34,7 @@ jobs:
             release_name="release-${tag_name}"
           fi
 
-          docker compose run --user root --rm php bin/create-release "$tag_name"
+          docker compose run --user root --rm php-release bin/create-release "$tag_name"
 
           # Delete release if it already exists.
           gh release view "$release_name" > /dev/null 2>&1 && gh release delete "$release_name" --yes

Dockerfile

@@ -2,7 +2,7 @@ FROM itkdev/php8.3-fpm:latest
 
 USER root
 
-# Add rsync
+# Add rsync, which `bin/create-release` needs and the base image does not carry.
 RUN apt-get update && apt-get --yes install rsync
 
 # Clean up

README.md

@@ -65,8 +65,8 @@ curl https://leantime.local.itkdev.dk/apidata/api/deleted
 
 ## Development
 
-The plugin has no long-running stack, so everything runs in a one-off container
-built from the local `Dockerfile`. Install [Task](https://taskfile.dev), then:
+The plugin has no long-running stack, so everything runs in a one-off
+`itkdev/php8.3-fpm` container. Install [Task](https://taskfile.dev), then:
 
 ```shell
 task setup
@@ -76,6 +76,10 @@ task lint
 
 Run `task --list-all` to see the remaining commands.
 
+The `Dockerfile` exists only for releases: `bin/create-release` needs `rsync`,
+which the base image does not carry. It backs the `php-release` compose service
+and is not used for tests or linting.
+
 Leantime core is not a Composer dependency of this plugin, so the development
 dependencies stand in for it. `illuminate/database` and `nesbot/carbon` are
 pinned to the exact versions the targeted Leantime release locks, so the tests

Taskfile.yml

@@ -2,7 +2,7 @@
 # Run `task` (or `task --list-all`) to see all available commands.
 #
 # This plugin has no long-running stack, so everything runs in a one-off
-# container built from the local Dockerfile (itkdev/php8.3-fpm).
+# itkdev/php8.3-fpm container.
 
 version: "3"
 
@@ -20,14 +20,14 @@ tasks:
   # -------------------------------------------------------------- Wrappers ---
 
   compose:
-    desc: "Run a docker compose command. Example: task compose -- build php."
+    desc: "Run a docker compose command. Example: task compose -- config."
     cmds:
       - "{{ .DOCKER_COMPOSE }} {{ .CLI_ARGS }}"
 
   php:
     desc: "Run a command in a one-off php container. Example: task php -- php --version."
     cmds:
-      - task compose -- run --rm --no-deps php {{ .CLI_ARGS }}
+      - task compose -- run --rm --no-deps phpfpm {{ .CLI_ARGS }}
     silent: true
 
   composer:
@@ -39,9 +39,8 @@ tasks:
   # ------------------------------------------------------------ Lifecycle ---
 
   setup:
-    desc: Build the php image and install dev dependencies.
+    desc: Install dev dependencies.
     cmds:
-      - task compose -- build php
       - task composer -- install
 
   # ------------------------------------------------------------ PHP tests ---

compose.yml

@@ -1,5 +1,20 @@
 services:
-  php:
+  # Tests, linting and composer run straight on the itkdev image — nothing in
+  # that path needs anything added to it.
+  phpfpm:
+    image: itkdev/php8.3-fpm:latest
+    working_dir: /app
+    # `deploy` is right locally, where Docker Desktop masks the ownership of the
+    # bind mount. On a Linux CI runner the checkout belongs to the runner's own
+    # uid, so CI sets COMPOSE_USER to it — otherwise composer cannot create
+    # `vendor`. The image carries a `runner` user at uid 1001, so the overridden
+    # uid still resolves to a writable home.
+    user: ${COMPOSE_USER:-deploy}
+    volumes:
+      - .:/app
+
+  # Only `bin/create-release` needs the built image, for the rsync it adds.
+  php-release:
     build: .
     working_dir: /app
     volumes: