Merge pull request 'chore(release): prepare v0.1.0 release for main' (#16) from dev into main

Reviewed-on: #16

.changeset/ten-rules-bet.md

@@ -0,0 +1,5 @@
+---
+'luna-charts': minor
+---
+
+Establish the initial project foundation with architecture, documentation, governance, and development tooling.

.gitea/runners/Dockerfile

@@ -1,9 +1,18 @@
 FROM node:22-bullseye
 
+# Install Docker CLI + Compose V2 plugin from Docker's official apt repo
+# (Debian's own docker.io package ships an outdated Docker version and
+# does not include the compose plugin at all).
 RUN apt-get update \
-    && apt-get install -y docker.io \
+    && apt-get install -y ca-certificates curl gnupg \
+    && install -m 0755 -d /etc/apt/keyrings \
+    && curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc \
+    && chmod a+r /etc/apt/keyrings/docker.asc \
+    && echo \
+       "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian bullseye stable" \
+       | tee /etc/apt/sources.list.d/docker.list > /dev/null \
+    && apt-get update \
+    && apt-get install -y docker-ce-cli docker-compose-plugin \
     && rm -rf /var/lib/apt/lists/*
 
-RUN corepack enable
+RUN corepack enable
-
-RUN npm install -g docker-compose

.gitea/workflows/quality-gate.yml

@@ -12,6 +12,9 @@ jobs:
     runs-on: ubuntu-docker-dind
     container:
       image: git.byting-pandas.ninja/ci/node22-docker:latest
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
     steps:
       - uses: actions/checkout@v4
 
@@ -30,6 +33,9 @@ jobs:
     runs-on: ubuntu-docker-dind
     container:
       image: git.byting-pandas.ninja/ci/node22-docker:latest
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
     steps:
       - uses: actions/checkout@v4
         with:
@@ -48,6 +54,9 @@ jobs:
     runs-on: ubuntu-docker-dind
     container:
       image: git.byting-pandas.ninja/ci/node22-docker:latest
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
     steps:
       - uses: actions/checkout@v4
 
@@ -62,19 +71,20 @@ jobs:
   component-tests:
     runs-on: ubuntu-docker-dind
     container:
-      image: git.byting-pandas.ninja/ci/node22-docker:latest
+      image: git.byting-pandas.ninja/ci/luna-charts-test:v1.62.1
+      credentials:
+        username: ${{ secrets.REGISTRY_USER }}
+        password: ${{ secrets.REGISTRY_TOKEN }}
+
     steps:
       - uses: actions/checkout@v4
 
       - run: corepack enable
+
       - run: corepack prepare pnpm@11.11.0 --activate
 
       - run: pnpm install --frozen-lockfile
 
-      - name: Verify Docker availability
+      - name: Run component tests (Playwright)
-        run: |
+        working-directory: packages/luna-charts
-          docker --version
+        run: pnpm test:browser
-          docker compose version
-
-      - name: Run component tests (Docker)
-        run: pnpm test:component

README.md

@@ -50,7 +50,9 @@ luna-charts/
 │
 ├── .changeset/               # Release/versioning configuration
 │
-└── .github/                  # Community health files (Code of Conduct, etc.)
+├── .github/                  # Community health files (Code of Conduct, etc.)
+│
+└── .gitea/                   # CI workflows (Gitea Actions) and CI runner image
 ```
 
 ## Getting Started
@@ -86,6 +88,9 @@ pnpm install
 | `pnpm test` | Run the full test suite (unit + component) |
 | `pnpm changeset` | Record a changeset for your change (required for any user-facing change) |
 | `pnpm run docs` | Start the documentation site locally (astroJS) |
+| `pnpm run lint` | Run the linter to check for code style and quality issues |
+| `pnpm run format` | Run the formatter to automatically fix code style issues |
+| `pnpm run test:browser` | Run browser tests (only works inside the `packages/luna-charts` directory) |
 
 ### Storybook
 
@@ -98,7 +103,7 @@ pnpm run storybook
 
 > **Note:** Running Storybook from the repository root isn't set up yet. This is a known gap — contributions to add a root-level `pnpm --filter` script are welcome.
 
-Component and browser tests run inside Docker (`docker-compose.test.yaml`) to guarantee a reproducible browser environment across all contributors and CI — you don't need Playwright browsers installed locally.
+Component and browser tests run inside Docker (`docker-compose.test.yaml`), based on the same `Dockerfile.test` used to build the image CI tests against, to guarantee a reproducible browser environment — you don't need Playwright browsers installed locally. Locally this image is built on demand; in CI a prebuilt version of the same image is pulled directly (see [ADR-0002](./docs/src/content/docs/architecture/adr/000200-technology-stack.mdx) and the [Technology Architecture](./docs/src/content/docs/architecture/adm/technology-architecture.mdx#66-test-execution-environment) doc for details).
 
 ## Documentation
 
@@ -108,4 +113,4 @@ Component and browser tests run inside Docker (`docker-compose.test.yaml`) to gu
 
 ## License
 
-LUNA Charts is licensed under the [GNU Lesser General Public License v3.0 (LGPL-3.0)](./LICENSE).
+LUNA Charts is licensed under the [GNU Lesser General Public License v3.0 (LGPL-3.0)](./LICENSE).

docs/src/content/docs/architecture/adm/technology-architecture.mdx

@@ -150,19 +150,39 @@ LUNA Charts follows a multi-layer quality assurance model.
 
 ### 6.6 Test Execution Environment
 
-Component and browser tests (Vitest browser mode, see ADR-0002) run inside a **containerized Playwright environment** rather than directly on contributor or CI host machines.
+Component and browser tests (Vitest browser mode, see ADR-0002) run inside
+a **containerized Playwright environment** rather than directly on
+contributor or CI host machines.
 
 #### Characteristics
 
-- A dedicated `Dockerfile.test`, based on the official Playwright container image, provides a reproducible browser environment with pinned browser versions
+- A dedicated `Dockerfile.test`, based on the official Playwright container
-- `docker-compose.test.yaml` orchestrates the test execution, isolating dependencies from the host system
+  image, provides a reproducible browser environment with pinned browser
-- The same containerized environment is used locally by contributors and in Continuous Integration, avoiding "works on my machine" discrepancies caused by differing local Playwright/browser installations
+  versions
+- Locally, `docker-compose.test.yaml` builds this image from source and
+  orchestrates test execution, isolating dependencies from the host system
+- In Continuous Integration, the same `Dockerfile.test` is built and
+  pushed to the project's container registry out-of-band (tagged by
+  Playwright version, e.g. `luna-charts-test:v1.62.1`); CI jobs pull this
+  prebuilt image directly rather than rebuilding it on every run, then
+  check out the current commit and install dependencies inside the running
+  container before executing tests
+- `Dockerfile.test` remains the single source of truth for the test
+  environment definition in both cases — only *when* the image is built
+  (on demand locally, ahead of time for CI) differs
 
 #### Rationale
 
-- Ensures deterministic, reproducible accessibility and browser test results independent of the host operating system
+- Ensures deterministic, reproducible accessibility and browser test
-- Removes the need for contributors to install and maintain matching Playwright browser binaries locally
+  results independent of the host operating system
-- Aligns automated testing (Section 6.1–6.4) with a single, version-controlled execution environment
+- Removes the need for contributors to install and maintain matching
+  Playwright browser binaries locally
+- Avoids rebuilding the Playwright/browser image on every CI run, which
+  would otherwise require Docker-in-Docker access inside the CI runner —
+  significant infrastructure complexity for a single-service image build
+- Aligns automated testing (Section 6.1–6.4) with a single,
+  version-controlled execution environment definition, even though the
+  build trigger differs between local development and CI
 
 ## 7. Release & Distribution Model
 
@@ -255,4 +275,32 @@ Component and browser tests are executed inside a Docker-based Playwright enviro
 
 **Impact**
 
-This clarifies an already-implemented part of the testing strategy (Section 6) and does not change any other architectural decision in this document.
+This clarifies an already-implemented part of the testing strategy (Section 6) and does not change any other architectural decision in this document.
+
+### 2026-08-04 – CI uses a prebuilt test image instead of rebuilding per run
+
+**Reason**
+
+The initial implementation of Section 6.6 assumed CI would build
+`Dockerfile.test` fresh on every run, identical to local execution. In
+practice, this required Docker-in-Docker access inside the CI runner
+purely to build a single-service image — disproportionate operational
+complexity (privileged sidecar container, custom pod networking,
+runner-level configuration) for the orchestration value actually needed,
+since `docker-compose.test.yaml` defines only one service with no
+inter-service dependencies.
+
+**Changes**
+
+- Section 6.6 updated to describe the actual CI flow: `Dockerfile.test` is
+  built and pushed to the registry out-of-band (not on every CI run), and
+  CI jobs pull the prebuilt image, then check out the current commit and
+  install dependencies at runtime
+- Clarified that `Dockerfile.test` remains the single source of truth for
+  the test environment definition; only the build trigger differs between
+  local and CI usage
+
+**Impact**
+
+No other architectural decision in this document is affected. Local
+component testing (`pnpm test:component`) is unchanged.

docs/src/content/docs/architecture/adr/000200-technology-stack.mdx

@@ -235,4 +235,90 @@ During implementation, Jest was replaced with Vitest as the unit testing tool. S
 
 **Impact**
 
-Playwright remains part of the technology stack, but its architectural role changes from an independent browser test runner to the browser engine used by Vitest. No other decisions in this ADR are affected.
+Playwright remains part of the technology stack, but its architectural role changes from an independent browser test runner to the browser engine used by Vitest. No other decisions in this ADR are affected.
+
+### 2026-08-03 – Continuous Integration: GitHub Actions replaced with Gitea Actions
+
+**Reason**
+
+During implementation, the project moved to a self-hosted Gitea instance
+with Gitea Actions (`act_runner`) instead of GitHub Actions. The ADR's
+"Considered Alternatives" and "Decision" tables still listed GitHub
+Actions, which no longer matched the actual CI/CD tooling in use.
+
+**Changes**
+
+- "Considered Alternatives" table: `Continuous Integration` row updated —
+  considered alternatives changed to *GitHub Actions, GitLab CI, Azure
+  Pipelines, Gitea Actions*; selected technology changed to **Gitea
+  Actions**
+- "Decision" table: **GitHub Actions** entry replaced with **Gitea
+  Actions**
+- "Rationale" section: `GitHub Actions` subsection replaced with `Gitea
+  Actions`, noting that workflows run on a self-hosted `act_runner`
+  (Docker-in-Docker mode) against the project's own Gitea instance
+
+**Impact**
+
+Only the Continuous Integration technology choice is affected. Workflow
+syntax remains GitHub-Actions-compatible (Gitea Actions is designed to be
+largely compatible with the GitHub Actions workflow format), so no other
+architectural decisions in this ADR are impacted.
+
+### 2026-08-04 – Component test CI execution: prebuilt image instead of Docker-in-Docker
+
+**Reason**
+
+Component tests run inside a container built from `Dockerfile.test`
+(based on the official Playwright image). Running this build step inside
+every CI job would require Docker-in-Docker (DinD) access on the
+self-hosted Gitea Actions runner — a privileged sidecar container, custom
+pod networking, and runner-level configuration — solely to build a
+single-service image with no inter-service orchestration need.
+
+**Considered Alternatives**
+
+| Alternative | Description |
+| ----------- | ----------- |
+| Build `Dockerfile.test` fresh on every CI run (DinD) | Mirrors the local `docker compose up --build` flow exactly inside a DinD-enabled CI job. |
+| Replicate `Dockerfile.test`'s steps directly as CI workflow steps, using the public Playwright image | Avoids Docker entirely in CI, but duplicates the test environment definition in two places (`Dockerfile.test` and the workflow YAML), risking drift between local and CI environments. |
+| **Build and push `Dockerfile.test` out-of-band, pull the prebuilt image in CI (selected)** | `Dockerfile.test` remains the only definition of the test environment; the resulting image is built and pushed to the registry separately (tagged by Playwright version), and CI jobs simply pull it and run tests — no Docker access needed at test time. |
+
+Building fresh on every run was rejected due to the disproportionate DinD
+infrastructure complexity for a single-service build. Replicating the
+steps in the workflow file was rejected because it reintroduces a second,
+manually-synchronized source of truth for the test environment.
+
+**Decision**
+
+`Dockerfile.test` is built and pushed to the project's container registry
+out-of-band (not as part of the CI pipeline), tagged by Playwright
+version (e.g. `luna-charts-test:v1.62.1`). The `component-tests` CI job
+pulls this prebuilt image directly, checks out the current commit, and
+runs the test command — no Docker access is required inside the CI job
+container.
+
+**Consequences**
+
+*Positive*
+
+- `Dockerfile.test` remains the single source of truth for the test
+  environment definition
+- No Docker-in-Docker, privileged containers, or custom pod networking
+  required in the CI job itself
+- Faster, simpler `component-tests` job
+
+*Negative*
+
+- The test image must be rebuilt and pushed manually (or via a separate,
+  intentionally-triggered process) whenever `Dockerfile.test` changes;
+  forgetting this step means CI runs against a stale image
+- This is considered an acceptable trade-off given how infrequently
+  `Dockerfile.test` changes, versus the ongoing operational cost of
+  maintaining DinD access in the runner
+
+**Impact**
+
+Local component testing (`pnpm test:component` via Docker Compose) is
+unaffected — it continues to build `Dockerfile.test` fresh via
+`docker-compose.test.yaml`. Only the CI-side image sourcing changes.