Bring the application and Gitea build pipeline to main #1

wanjakrah · 2026-10-28T17:53:57+01:00

wanjakrah commented

2026-10-28 17:53:57 +01:00

The main branch still contains only the initial commit. This PR therefore includes the existing application history from feature/setup (Quarkus backend, Angular frontend and school JSON import/export), followed by the S4 build pipeline. The S4 changes themselves are the commits after e3e362c.

Every branch push builds and tests both applications and runs Playwright against their Docker images. Successful main builds publish matching full-SHA images to the Synology registry and update main aliases under a publication lock. Diagnostics are retained for fourteen days. No application deployment is performed.

Gitea Actions and the linux/amd64 target variable are configured, registry credentials are stored as repository secrets, and the runner is registered and online on the mini-PC. Docker registry login succeeds.

Validation: real feature run #1 passed, including both container E2E tests; temporary failure run #2 stopped at the deliberately failing backend test. Both diagnostic archives were downloaded successfully. A follow-up feature run validates unique diagnostic names on Gitea 1.25. Main-branch publication and pullback evidence will be recorded after merge approval.

See docs/gitea-ci.md and docs/s4-validation.md. Merging this PR starts the main publication pipeline and also brings the pre-existing feature/setup application history into main.

The main branch still contains only the initial commit. This PR therefore includes the existing application history from feature/setup (Quarkus backend, Angular frontend and school JSON import/export), followed by the S4 build pipeline. The S4 changes themselves are the commits after e3e362c. Every branch push builds and tests both applications and runs Playwright against their Docker images. Successful main builds publish matching full-SHA images to the Synology registry and update main aliases under a publication lock. Diagnostics are retained for fourteen days. No application deployment is performed. Gitea Actions and the linux/amd64 target variable are configured, registry credentials are stored as repository secrets, and the runner is registered and online on the mini-PC. Docker registry login succeeds. Validation: real feature run #1 passed, including both container E2E tests; temporary failure run #2 stopped at the deliberately failing backend test. Both diagnostic archives were downloaded successfully. A follow-up feature run validates unique diagnostic names on Gitea 1.25. Main-branch publication and pullback evidence will be recorded after merge approval. See docs/gitea-ci.md and docs/s4-validation.md. Merging this PR starts the main publication pipeline and also brings the pre-existing feature/setup application history into main.

wanjakrah added 10 commits 2026-10-28 17:53:57 +01:00

set basis and model aa6f50e3c8

WIP: verder uitbreiden model e617bc09c1

upgraded to Java 25 c037abbde9

turned into a quarkus application 2bb3beef60

Add school management REST API and architecture checks 777d9f199d

frontend-toegevoegd 02337fafaa

Spec driven development setup bd497aefd5

import export functionality added e3e362c2ac

Add Gitea build, container tests and registry publication

Build, test and publish / verify (push) Successful in 1m41s

Details