Run CI checks through Docker target

.gitea/workflows/ci.yml

@@ -22,20 +22,8 @@ jobs:
       - name: Checkout
         uses: actions/checkout@v4
 
-      - name: Set up Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: '22'
-          cache: npm
-
-      - name: Install dependencies
-        run: npm ci
-
-      - name: Lint
-        run: npm run lint
-
-      - name: Build app
-        run: npm run build
+      - name: Check app
+        run: docker build --target ci -t evil-wordle-ci .
 
       - name: Validate compose file
         run: docker compose config

Dockerfile

@@ -1,7 +1,14 @@
-FROM node:22-alpine AS build
+FROM node:22-alpine AS deps
 WORKDIR /app
 COPY package*.json ./
 RUN npm ci
+
+FROM deps AS ci
+COPY . .
+RUN npm run lint
+RUN npm run build
+
+FROM deps AS build
 COPY . .
 RUN npm run build
 

README.md

@@ -44,7 +44,7 @@ The workflow also accepts `REGISTRY_TOKEN` as a fallback for `REGISTRY_PASSWORD`
 
 For organization packages such as `space/evil-wordle`, the username is still the actual Gitea user account for the token, not the organization name. That user needs permission to publish packages under `space`.
 
-The workflow uses `catthehacker/ubuntu:act-latest`, Docker Buildx, and links the published package back to the `space/evil-wordle` repository through the Gitea API.
+The workflow uses `catthehacker/ubuntu:act-latest`, validates the app through the Dockerfile `ci` target, publishes with Docker Buildx, and links the package back to the `space/evil-wordle` repository through the Gitea API.
 
 On pushes to `main`, CI publishes: