agiledancers/docs/s4-validation.md

> Historical validation evidence from application commit `bd898e92d22f6c412e671908770f4d89c8ae12bc`. Commands retain their original paths; current tooling is documented in README.md.

# S4 verification evidence

Updated: 2026-10-29. S4 is **complete**. Main publication/pullback passed in run
#7. Real registry recovery, rerun and stale-main checks passed against isolated
validation image repositories. Server defaults are confirmed from the maintainer's
configuration report and Gitea 1.25.4 documentation; explicit skip markers are an
accepted exception to branchpush triggering.

## Verified locally

- Gitea reports version 1.25.4; repository `wanjakrah/agiledancers` has Actions
  enabled and uses `main` as its default branch.
- Docker Desktop was started on the existing Linux x86_64 mini-PC. Its Docker
  daemon reports `linux/x86_64` (`linux/amd64`). This is not evidence of the
  Synology's architecture.
- `mvn clean verify` passed, including all 20 backend tests and architecture tests.
- `npm ci`, all 14 frontend unit tests with JUnit output, and the production build
  passed in the full verification script.
- Both runtime images built successfully with the `prebuilt` targets. The images
  package the same outputs that passed verification.
- Both existing Playwright tests passed (2/2) using the built frontend and backend
  containers, the frontend `/api/` proxy and Chromium in the version-matched
  Playwright container. No Angular development server was used.
- The full `ci/verify.sh` execution exited successfully; its trap removed all three
  temporary test containers and the run network.
- Eleven isolated CI tests pass: failed verification removes its success marker,
  feature branches do not publish, unverified commits cannot publish, reruns
  preserve commit tags, partial publication is recoverable, authentication and
  pull failures block publication, older commits do not move `main`, platform
  mismatches fail, and daemon configuration preserves existing settings.
- Shell syntax, Python compilation, workflow YAML parsing and the changed files'
  whitespace checks passed.
- Runner v0.2.13 was downloaded from the official source, SHA-256 checked, and
  installed with its user-service configuration using `--prepare-only`.
  The runner was subsequently registered and its user service started using the
  supplied repository administration credentials.
- The internal registry was merged into Docker Desktop's daemon configuration,
  preserving existing settings and a backup. Docker Desktop was restarted and
  the running daemon confirmed that `192.168.2.28:3000` is an active HTTP registry.

Local outputs are in `ci/artifacts/` (ignored by Git): verify log, backend test
reports, frontend unit JUnit report, Playwright JUnit/HTML report and container
logs. These are local files, not yet artifacts uploaded by a real Gitea run.
The unit JUnit report uses a separate directory so Playwright output cleanup
cannot delete it.

The local test used working-tree changes on base commit
`e3e362c2ac30d6b365f752f3da6c8b0250c019db`, with run ID `s4local`. These local
images are test outputs, not published release images for that commit.

Local image IDs (not registry digests):

- Backend: `sha256:bd77a46e3dbdcaea9662d21c608098999fe17dfdf241cd28a24a935f47401f61`.
- Frontend: `sha256:ce8e6ab21fb8f9cbee280ac2c4d7b4ca24a30e899a457382f1e45c6baf99dfb6`.

## Operational acceptance

- [x] Synology architecture confirmed by the maintainer: `x86_64`,
      `linux/amd64`; repository variable `TARGET_PLATFORM=linux/amd64` configured.
- [x] Activate and verify the Docker Desktop HTTP-registry setting.
- [x] Repository `REGISTRY_USER`/`REGISTRY_TOKEN` secrets configured using the
      supplied token files. A temporary Docker login with the registry token
      succeeded; actual main publication and pullback are now confirmed below.
- [x] Runner ID 1 (`agiledancers-mini-pc`) registered, service started and
      online in Gitea. Real feature/failure jobs ran on this runner.
- [x] The maintainer reports no `[actions]` section in app.ini. Gitea 1.25.4
      therefore uses the documented artifact/log defaults of 90/365 days; the
      workflow explicitly requests fourteen days for diagnostic artifacts.
      The maintainer accepts intentional `[skip ci]`-style opt-outs. No server
      change or SSH access was required.
- [x] [Feature run #1](http://192.168.2.28:3000/wanjakrah/agiledancers/actions/runs/1),
      API run ID 2, commit `74a5aa12377d4a62cdebe1dcd6e8a8e1443b33fb`: succeeded,
      two container E2E tests passed, publication skipped. Diagnostic ZIP was
      downloaded and verified (23 files).
- [x] [Failure probe #2](http://192.168.2.28:3000/wanjakrah/agiledancers/actions/runs/2),
      API run ID 3, temporary branch `feature/s4-ci-failure`, commit
      `6d94c68756a90c5e87590e6fd137de8aa5cd9395`: failed at the deliberate
      backend test; imagebuild/publication did not run. Diagnostic ZIP was
      downloaded and verified (15 files). The probe is absent from the real
      featurebranch.
- [x] Main run #7 (API run/job ID 8) published both full-SHA images, pulled
      them back and updated/pulled both `main` aliases; digests are recorded below.
- [x] Real publication-code probes against the Synology registry passed:
      partial recovery preserves the first image, reruns preserve both commit
      digests, and an older commit cannot move current main aliases. Details and
      evidence are recorded below.

The isolated publication tests provide automated control-flow coverage; they do
not substitute for real authenticated registry/Gitea acceptance runs. Application
images have now been published by main; no application deployment is performed.


Gitea 1.25 does not populate `gitea.run_attempt`; the workflow generates a unique
attempt identifier for containers and diagnostic artifact names. The Gitea v3
artifact-list API returns an empty list despite successful uploads; artifacts
were verified by downloading the run-page archive URLs. This is separate from
artifact availability and does not require a server upgrade.


## Historical review state before the main merge

[PR #1](http://192.168.2.28:3000/wanjakrah/agiledancers/pulls/1) was initially left open at
the maintainer's explicit request. Main merge and publication were postponed at
that stage; the maintainer has since merged it.

[Feature run #3](http://192.168.2.28:3000/wanjakrah/agiledancers/actions/runs/3),
API run/job ID 4, commit `834584dae06b5976936a5e739871f1164cf81bcd`, succeeded.
The two container E2E tests passed and diagnostics were uploaded as
`diagnostics-4-20261028164607460012324`, confirming unique attempt names work.

Before this merge, main contained only its initial commit. PR #1 therefore
includes the prior application history from `feature/setup` as well as S4. Its
scope is documented in the PR description. The maintainer subsequently merged that full history. Publication and pullback
are confirmed below; the remaining acceptance evidence is still tracked above.


## Java 25 helper migration

CI orchestration, setup and behavior tests now run through `java ci/Ci.java`.
The shell/Python helpers have been removed. The source launcher compiles helper
classes in memory without external dependencies or preview flags. Fifteen Java
behavior tests pass, including JSON/configuration preservation, publication gates,
partial recovery and process deadlines. Feature run #6 passed for the Java implementation before the maintainer merged
PR #1 into main.


## Main publication confirmed after merge

[Main run #7](http://192.168.2.28:3000/wanjakrah/agiledancers/actions/runs/7), API
run/job ID 8, completed successfully for commit
`2356a31aa612c8b0ce4b386a0a65da6589e23285`.

Downloaded and inspected artifact `diagnostics-8-20261029144539933186842`.
Its verified-commit marker, publication log and digest files confirm publication
and pullback of both commit tags and both moving main aliases:

| Image | Digest for the full-SHA tag and main alias |
| --- | --- |
| `192.168.2.28:3000/wanjakrah/agiledancers-backend` | `sha256:483f4593716f94d1c6a7851519b80399b40600e9e49db5b656abed14b4552e93` |
| `192.168.2.28:3000/wanjakrah/agiledancers-frontend` | `sha256:f9be998187751e13a81cbed809938837a3b80fdbfdd122c2126c9792c4320077` |

This closed the original merge/publication blocker. The remaining acceptance
checks have since been completed as recorded below.


## Final acceptance: recovery, rerun and stale-main protection

Completed on 2026-10-29. These were real command-line publication probes using the
production `Pipeline`/`Commands` implementation against the Synology registry,
not a second full Gitea workflow run. The test adapter redirects Docker write
references to dedicated validation repositories and refuses application-image
pushes. Main-head checks use the actual Gitea API.

The verified images from main run #7 were used as the current source. The older
images came from the previously successful feature run #6. The main commit is
`2356a31aa612c8b0ce4b386a0a65da6589e23285`; the older commit is
`aea792307c5d3be43e17c11db3b9f5845dbd5f14`.

Test repositories:

- `192.168.2.28:3000/wanjakrah/s4-validation-1793286292474-backend`
- `192.168.2.28:3000/wanjakrah/s4-validation-1793286292474-frontend`

Evidence/results:

1. Publication was deliberately stopped after backend publication and before
   frontend publication. The operation failed; the backend tag existed and the
   frontend tag did not.
2. Recovery published the missing frontend image and retained the backend digest.
3. A repeat publication retained both full-SHA digests and pushed only the two
   moving validation aliases. No immutable commit tag was pushed again.
4. The older source images were published to the same isolated repositories.
   The real Gitea main-head check detected the newer commit. No moving-alias write
   was attempted, and before/after manifest hashes remained identical.
5. Application `main` manifests were compared before and after the probes and
   remained unchanged.

The backend and frontend immutable digests match the run #7 digests recorded
above. Manifest comparison hashes for the validation main aliases:

| Alias | Before and after SHA-256 of inspected manifest |
| --- | --- |
| Backend main | `b4438f0d32eae92632e1f3c106ca9c4538c87d61d6feda9e0184dd8749b46d8c` |
| Frontend main | `3d2bebc8da4297c54eebeb43ce0f00e61a61e9216dde27c81f08be69cd6c7335` |

Raw local evidence is retained under `ci/artifacts/s4-final-acceptance/`, including
`results.json`, `partial-publication.log`, `recovery.log`, `rerun.log`,
`confirmed-rerun.log` and `stale-main.log`. The isolated validation images remain
available as acceptance artifacts; they are not deployed application instances.

A temporary registry-login timeout interrupted the first stale-run probe. It
failed visibly and cleaned up temporary login state. Retrying the remaining
checks succeeded; the already-passed recovery/rerun evidence was retained.

## Server configuration closure

The maintainer inspected the Synology-hosted Gitea configuration and confirmed
that `[actions]` is absent. Gitea 1.25.4 defaults are:

- Artifact retention: 90 days by default; the workflow's artifact upload requests
  fourteen days explicitly.
- Job log retention: 365 days by default.
- Intentional skip strings such as `[skip ci]` are recognized by default.

The maintainer explicitly approved documenting these skip strings as exceptions:
ordinary branchpushes trigger CI, while an author can intentionally opt out with
an existing supported marker. No Gitea configuration change or broad NAS access
is necessary. This is the agreed interpretation of the trigger criterion.

Sources: [Gitea 1.25 Actions settings](https://docs.gitea.com/1.25/administration/config-cheat-sheet/#actions-actions),
[installed-version defaults](https://github.com/go-gitea/gitea/blob/v1.25.4/modules/setting/actions.go).