POC: test reusable workflow job visibility in Gitea Actions (#5)

Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #5
2026-06-13 09:37:47 +03:00
parent 8f1bf7e347
commit dacb8b4ef7
52 changed files with 3887 additions and 645 deletions
@@ -0,0 +1,25 @@
+# 4. Commit-statusviestit — periaate
+
+## Päätös
+
+Gitea Actions näyttää jobien tilan (checkmark, risti, spinner) commit-näkymässä
+**automaattisesti**. Tämä on ensisijainen tapa, eikä sitä korvata.
+
+Commit-status API:a (`/api/v1/repos/{owner}/{repo}/statuses/{sha}`) käytetään
+**vain** kun natiivi toiminta ei riitä — ensisijaisesti custom-raporttilinkin
+välittämiseen commit-näkymään.
+
+## Periaatteet
+
+1. Gitea Actionsin automaattinen commit-status on ensisijainen.
+2. API:a kutsutaan vain tarpeeseen: linkki ulkoiseen raporttiin.
+3. Jokainen API-kutsussa käytettävä `context`-avain on uniikki.
+4. State-arvojen on oltava Gitea API:n valideja (`success`, `failure`,
+   `pending`, `error`, `warning`).
+
+## Tausta
+
+Jenkins-versiossa jokainen build-vaihe raportoi APIin, koska Jenkins ei
+tarjonnut natiivia commit-statusnäkymää. Gitea Actionsissa tämä tulee
+automaattisesti — sama tieto kahdesta paikasta aiheuttaa melua eikä lisää
+arvoa.
@@ -0,0 +1,66 @@
+# 5. Provider & Consumer -malli
+
+## Päätös
+
+Provider (gitea-ci-library) ja Consumer (mikropalveluprojekti) erotetaan
+selkeällä rajapinnalla: `.gitea/workflows/ci-engine.yml` on ainoa pinta,
+jota consumer kutsuu.
+
+Kaikki muu providerin koodi (scriptit, git-pages-helmi, retention) on
+sisäistä toteutusta, johon consumerilla ei ole suoraa pääsyä eikä
+riippuvuutta.
+
+## Rajapinnat
+
+### Consumer → Provider (pakollinen)
+
+```yaml
+# .gitea/workflows/ci.yml — consumerin repo
+jobs:
+  ci:
+    uses: niko/gitea-ci-library/.gitea/workflows/ci-engine.yml@v1
+    secrets: inherit
+```
+
+Consumer:
+- Omistaa pipeline-logiikan (mitä testejä ajetaan, missä järjestyksessä)
+- Luo raportit omiin polkuihinsa (`reports/{sha8}/{step}/`)
+- Luo `.meta`-tiedostot per step
+- Määrittelee Gitea-secretit (`GIT_PAGES_PUBLISH_TOKEN`, `GITEA_TOKEN`)
+
+### Provider → Consumer (mitä provider tarjoaa)
+
+- **Raporttien julkaisu**: consumerin tuottamat raportit viedään
+  git-pages-palveluun osoitteeseen, josta ne ovat selaimella luettavissa.
+- **Commit-status linkillä**: jokaiselle raportille luodaan commit-status,
+  jonka kautta käyttäjä pääsee suoraan raporttiin Gitean commit-näkymästä.
+- **Orkestrointi**: build-ketjun ylittäessä reporajat, provider huolehtii
+  workflown käynnistyksestä ja tilan seurannasta.
+- **Raporttien elinkaari**: vanhat raportit poistetaan automaattisesti
+  retention-sääntöjen mukaan.
+
+### Provider (sisäinen toteutus, ei consumerin rajapinta)
+
+- Git-pages Helm-chartti
+- Retention sidecar
+- Scriptit ja työkalut (toteutus avoin, uudelleenkirjoitettavissa)
+- Kaikki paitsi `ci-engine.yml` on sisäistä toteutusta ja voi muuttua
+  ilman versiopäivitystä
+
+## Periaatteet
+
+1. `ci-engine.yml` on **lukittu rajapinta**. Consumer kutsuu tätä, ei
+   koskaan providerin scriptejä suoraan. `ci-engine.yml` voi muuttua vain
+   version vaihtuessa.
+2. Consumer omistaa pipeline-logiikan. Provider ei tiedä mitä testejä
+   ajetaan, missä järjestyksessä tai millä työkaluilla.
+3. Providerin versiointi: tag (`v1`, `v2`, ...). Branchit ovat kehitystä
+   varten, consumerit käyttävät tageja.
+
+## Tausta
+
+Jenkins-versiossa kaikki logiikka oli yhdessä kirjastossa. Gitea Actionsin
+reusable workflow -mekanismi pakottaa selkeämpään erotteluun: consumer
+kutsuu provideria, mutta omistaa oman pipeline-logiikkansa. Tämä vähentää
+providerin kompleksisuutta ja antaa consumerille vapauden päättää mitä
+ajetaan.
@@ -1,67 +1,98 @@
 # AI Context: Gitea Actions CI -kirjasto

-**Updated**: 2026-06-08
+**Updated**: 2026-06-12 (POC-vaihe, suunniteltu uudelleenkirjoitus)

 ## Project Overview
-Gitea Actions reusable workflow -kirjasto mikropalveluiden build-, testaus-, raportointi-, deployment- ja test flow -prosessien orkestrointiin. Korvaa `ci-jenkins-library`:n Gitea-natiivilla toteutuksella. Mikropalvelut käyttävät kirjastoa `uses:`-direktiivillä ja konfiguroivat itsensä `ci-flow-values.yaml`:lla.
+Gitea Actions reusable workflow -kirjasto mikropalveluiden build-, testaus-,
+raportointi-, deployment- ja test flow -prosessien orkestrointiin. Korvaa
+`ci-jenkins-library`:n Gitea-natiivilla toteutuksella. Mikropalvelut
+käyttävät kirjastoa `uses:`-direktiivillä.

-## Architecture
- 4 reusable workflow'ta: `ci-feature.yml`, `ci-master.yml`, `deploy.yml`, `test.yml`
- 4 jaettua bash-skriptiä (`scripts/`): `report-status.sh`, `dispatch-workflow.sh`, `push-reports.sh`, `tag-commit.sh`
- Raportit MinIO:ssa (S3 + static web), OIDC-autentikointi Traefikin kautta
- Cross-repo commit traceability Gitea REST API:n kautta
- `report-service/`-moduuli samassa repossa: raporttiskriptit, retention CronJob, index.html-generointi
- Normatiivinen arkkitehtuuri: `docs/architecture.md`, perustelut `docs/design-rationale.md`
+POC on valmis: raporttien julkaisu git-pagesiin ja commit-status linkillä
+toimii.
+
+## Monorepo: kaksi erillistä kokonaisuutta
+
+Tämä repo on käytännössä monorepo, jossa on kaksi itsenäistä osaa:
+
+### 1. Juuri (`gitea-ci-library`)
+Provider-kirjasto: reusable workflowt, scriptit, ADRt, dokumentaatio.
+Rajapinta: `.gitea/workflows/ci-engine.yml` — ainoa pinta, jota consumerit
+kutsuvat.
+
+### 2. `git-pages/` — oma kokonaisuus
+Helm-chartti Codeberg git-pagesille. Täysin itsenäinen — oma dokumentaatio,
+omat tekniset valinnat, oma design-rationale. Kohdeltava kuten se olisi jo
+oma reponsa: kaikki git-pages-spesifi tieto kuuluu `git-pages/docs/`- alle,
+ei juuren `docs/`-kansioon.
+
+### Rajapinta juuren ja git-pagesin välillä
+
+Ohut ja yksiselitteinen:
+
+```
+scripts/publish-git-pages.sh <report-dir>
+  → PATCH tar osoitteeseen PAGES_HOST
+  → palauttaa BASE URL:n
+
+git-pages tarjoaa:
+  - HTTP endpoint (GET/PATCH/PUT)
+  - retention (automaattinen)
+  - TLS, BasicAuth (Traefik)
+```
+
+Juuri ei tiedä git-pagesin sisäisestä toiminnasta (storage v2, .index,
+blob-arkkitehtuuri). Git-pages ei tiedä workflowista, scripteistä tai
+provider-logiikasta.
+
+## Architecture (POC-tila)
+- **Provider & Consumer -malli**: `ci-engine.yml` on lukittu rajapinta.
+  ADR 0005.
+- **Raporttien hostaus**: git-pages Helm-chartilla (`git-pages/`).
+- **Retention**: sidecar samassa podissa, HTTP API localhost:3000,
+  Gitea API branch-check.
+- **Commit-status**: Gitea Actions näyttää automaattisesti. API vain
+  custom-linkkiin. ADR 0004.
+- **Julkaisu**: `publish-git-pages.sh` → PATCH tar git-pagesiin.

 ## Repository Structure
+
 | Path | Purpose |
 |---|---|
-| `.gitea/workflows/` | Reusable workflow -tiedostot (`ci-feature.yml`, `ci-master.yml`, `deploy.yml`, `test.yml`) |
-| `scripts/` | Jaetut bash-skriptit |
-| `report-service/` | Raporttipalvelun koodi (retention, indeksigenerointi) |
-| `docs/` | Arkkitehtuuri-, vaatimus- ja konfiguraatiodokumentaatio |
-| `docs/tickets/` | Toteutustiketit (0001–0012), yksi per feature-branch |
-| `docs/test-plan/` | TDD-opas: 3-kerrosmalli, kehityslooppi, mock, kontekstikuratointi |
-| `docs/test-plan/tdd-guide.md` | Testivetoisen kehityksen menetelmädokumentti |
-| `tests/` | Bats-testit skripteille ja workflow-validointi |
-| `tests/features/` | Cucumber `.feature`-tiedostot (yksi per tiketti, tägätty @mock/@real/@ticket-NNNN) |
-| `tests/helpers/` | Jaettu mock-palvelin (Gitea API + MinIO) |
-| `.gitea/workflows/ci.yml` | Kirjaston oma CI — dogfood (käyttää itse itseään) |
+| `.gitea/workflows/` | `ci-engine.yml` (ainoa reusable workflow POC-vaiheessa) |
+| `scripts/` | `publish-git-pages.sh`, `report-status.sh`, `dispatch-workflow.sh` |
+| **`git-pages/`** | **Oma kokonaisuus: Helm-chartti + docs + retention** |
+| `docs/` | Root-tason arkkitehtuuri, ADRt (0001–0005) |
+| `docs/adr/` | Architecture Decision Records |
+| `tests/` | Bats-testit skripteille |
+| `.gitea/workflows/ci.yml` | Dogfood — kutsuu `ci-engine.yml`:a |
+
+**Tarkemmat git-pages-asiat:** `git-pages/docs/` (implementation-notes,
+architecture, design-rationale, secrets, tech-stack).

 ## Key Technical Decisions
- **Vain Gitea.** Ei multi-platform-tukea (GitLab, BitBucket, GitHub)
- **Ei omaa runtimea.** Reusable workflowt, ei Docker custom actioneita (ellei pakko)
- **Konfiguraatio repoon.** `ci-flow-values.yaml` projektin juuressa, infra-asetukset Gitea org secrets/variables
- **Vaiheittainen test flow.** Ei rinnakkaista suoritusta — deterministinen, debuggattava
- **Raportit MinIO:ssa.** Gitea artifact-järjestelmä ei tue HTML-selailtavuutta
- **Docker-rekisterit:** MVP:ssä vain Gitea Packages. Factory/adapter-pattern valmiina Artifactorylle/Nexukselle
- **MVP-scope:** `doNotDowngrade` ei mukana, vain Gitea Packages docker-rekisterinä
+- **Provider & Consumer**: `ci-engine.yml` lukittu rajapinta, muu koodi
+  vapaasti muutettavissa
+- **Vain Gitea, vain reusable workflowt**: ei custom actioneita, ei
+  multi-platform
+- **Raportit git-pagesissa**: HTML selailtavissa, retention automaattinen
+- **Git-pages omana kokonaisuutena**: voi erottaa omaksi repokseen
+  tulevaisuudessa

-## Tech Stack
- **Runtime:** Bash 4.0+, curl 7.0+, jq 1.6+, git 2.30+, MinIO client (`mc`)
- **Alusta:** Gitea Actions 1.21+, Gitea act runner 0.2+
- **Integraatiot:** Gitea REST API (`/api/v1/`), MinIO S3 API, SonarQube REST API
- **Tuetut build-ekosysteemit:** Java/Maven, Java/Gradle, Node.js/npm
- **Tuetut testikehykset:** Cucumber, JUnit, JaCoCo, Maven Site, custom HTML
+## Tech Stack (POC)
+- **Runtime:** Bash, curl, jq, python3 (retention whiteout)
+- **Alusta:** Gitea Actions, Gitea act runner
+- **Hostaus:** git-pages 0.9.1 (Codeberg), Traefik, cert-manager
+- **Integraatiot:** Gitea REST API, Gitea Packages

 ## Common Commands
- Workflow-triggerit: `push` branchiin tai `workflow_dispatch`
- Skriptien kutsuminen tapahtuu workflow-stepeistä, ei paikallisesti
- `ci-flow-values.yaml` validointi: skeema `docs/config-model.md`:ssa
- Bats-testit: `bats tests/` — ajaa kaikki skripti- ja workflow-testit
- Testit vaativat: `bats` (Bash Automated Testing System), `jq`, `yq`
-
-## Development Process
- TDD: Red-Green-Refactor jokaiselle tiketille. Testit ensin, toteutus vasta kun testi epäonnistuu.
- Ominaisuusbranchit: `feature/NNNN-tiketin-nimi` (esim. `feature/0001-report-status-sh`)
- Yksi tiketti per sessio. Tiketit riippuvuusjärjestyksessä 0001 → 0012.
- Ennen jokaista tikettiä: lataa `docs/test-plan/tdd-guide.md` + tiketin Required context -skillin lisäksi
- Dogfood: `.gitea/workflows/ci.yml` — kirjaston oma CI käyttää omia reusable workflow'itaan
+- Helm-asennus: `helm upgrade --install git-pages ./git-pages -n <ns> -f <values>`
+- Julkaisu: `bash scripts/publish-git-pages.sh <report-dir>`
+- Status: `bash scripts/report-status.sh <state> <desc> <url> <context>`

 ## What NOT to Do
- Älä lisää tukea muille Git-alustoille (GitLab, BitBucket, GitHub)
+- Älä lisää tukea muille Git-alustoille
 - Älä lisää Docker custom actioneita ilman pakottavaa syytä
- Älä siirrä konfiguraatiota pois reposita (`ci-flow-values.yaml`)
- Älä lisää rinnakkaista test flow -suoritusta
- Älä lisää ulkoista orkestraattoria — Gitea REST API riittää
- Älä käytä `repository_dispatch`-webhookia test flow -ketjutukseen
+- Älä kirjoita git-pages-spesifiä tietoa juuren `docs/`-kansioon —
+  kuuluu `git-pages/docs/`-alle
+- Älä POSTaa commit-status APIin jokaiselle vaiheelle — natiivi riittää
@@ -0,0 +1,163 @@
+# Miksi oma CI-kirjastoprojekti — ei perus-Gitea-tiedostoja
+
+> Liittyy: [architecture.md](../architecture.md), [config-model.md](../config-model.md), [design-rationale.md](../design-rationale.md)
+
+---
+
+## Taso 1: Miksi kirjastoprojekti, ei repo-kohtaisia workflow'ta
+
+Kirjasto (`gitea-ci-library`) on oma projektinsa, koska sen tarjoamat palvelut
+ovat **cross-cutting** — samat kaikissa mikropalveluissa. Ilman kirjastoa
+jokainen repo kopioisi identtisen CI-logiikan.
+
+### Mitä kirjasto tarjoaa "ilmaiseksi"
+
+| Palvelu | Tiedosto/skripti | Rivimäärä | Jos 20 projektia kopioisi |
+|---|---|---|---|
+| Commit-statusraportointi | `report-status.sh` | ~45 | 900 riviä |
+| Workflow-ketjutus + pollaus | `dispatch-workflow.sh` | ~80 | 1 600 riviä |
+| HTML-raporttien MinIO-pushaus | `push-reports.sh` | ~50 | 1 000 riviä |
+| GitOps-deploy (YAML-muokkaus + commit + cross-repo-trace) | `deploy.yml` | ~100 | 2 000 riviä |
+| Test flow -ketjutus (dispatch + poll + cross-repo-status) | `ci-master.yml` + `test.yml` | ~150 | 3 000 riviä |
+| Feature-branch CI (build-ekosysteemin valinta, concurrency) | `ci-feature.yml` | ~80 | 1 600 riviä |
+
+**Yhteensä ilman kirjastoa: ~10 000 riviä identtistä CI-koodia 20 repossa.**
+
+Yksi bugikorjaus (esim. `push-reports.sh`:n retry-logiikka) = 20 PR:ää, 20 review'tä, 20 mergeä.
+Osa jää tekemättä → eri projektit käyttäytyvät eri tavalla → CI-epäluotettavuus leviää.
+
+**Kirjaston kanssa:** Yksi PR, yksi review, yksi merge. Kaikki projektit saavat korjauksen
+`uses: org/gitea-ci-library/.gitea/workflows/ci-feature.yml@v1`-viittauksen kautta.
+
+### Miksi juuri nämä asiat ansaitsevat oman projektin
+
+Nämä kolme huolta ovat **pitkälle mietitty kokonaisuus**, jonka toteuttaminen
+repo-kohtaisesti olisi massiivista tautologiaa:
+
+1. **Dynaaminen test plan K8s-ympäristössä** — Deploy developmentiin → integraatiotestit
+   → deploy stagingiin → e2e-testit. Jokainen steppi dispatchaa toisen repon workflow'n,
+   pollaa sen valmistumista, ja raportoi cross-repo-statuksen takaisin root-committiin.
+
+2. **HTML-testiraporttien tallennus** — Cucumber, JaCoCo, Maven Site. Pushataan MinIO:hon
+   deterministisellä URL:llä. URL linkitetään commit-statusviestiin. Retention CronJob
+   siivoaa vanhat. Tämä on kokonainen alijärjestelmä, ei yksi steppi.
+
+3. **GitOps-deployment** — Päivitä YAML-arvo Helm-repossa, committaa, pushaa,
+   raportoi cross-repo-status molempiin suuntiin. Sama mekaniikka jokaisessa
+   mikropalvelussa — vain `projectFolder` ja `fileName` vaihtelee.
+
+Näiden toteuttaminen per repo olisi kuin jokainen mikropalvelu toteuttaisi oman
+tietokantakerroksensa sen sijaan että käyttäisi jaettua kirjastoa.
+
+---
+
+## Taso 2: Miksi `ci-flow-values.yaml` — Gitean natiivikonfiguraatio ei riitä
+
+Gitean natiivimekanismit hoitavat salaisuudet ja infra-arvot.
+`ci-flow-values.yaml` hoitaa rakenteisen, versioidun, projekti-spesifin konfiguraation.
+Ne täydentävät toisiaan, eivät kilpaile.
+
+### Mitä Gitea tarjoaa natiivisti
+
+| Mekanismi | Tyyppi | Sijainti | Rajoite |
+|-----------|--------|----------|---------|
+| `workflow_call` `inputs` | Skalaari (`string`, `boolean`, `number`) | Kutsuvan workflow'n parametrit | **Ei tue listoja, objekteja, nested-rakenteita** |
+| Org/repo secrets | `string` (salattu) | Gitea UI | Flat key-value, ei rakennetta |
+| Org/repo variables | `string` | Gitea UI | Flat key-value, ei rakennetta |
+| `.gitea/workflows/*.yml` | YAML | Projektin repo | Täysi workflow-logiikka, ei dataa |
+
+### Ongelma 1: skalaarityypit eivät kanna rakenteista konfiguraatiota
+
+`ci-flow-values.yaml` sisältää mm:
+
+```yaml
+test-flow:
+  - deploy: development
+    wait: true
+  - test:
+      name: "integration fast"
+      repo: tests/integration
+      tags: "@temperature and not @slow"
+  - test:
+      name: e2e
+      repo: tests/e2e
+```
+
+Tämän ilmaiseminen Gitea `inputs`:na vaatisi jokaisen kentän erillisenä parametrina:
+
+```yaml
+with:
+  test_flow_0_deploy: "development"
+  test_flow_1_test_name: "integration fast"
+  test_flow_1_test_repo: "tests/integration"
+  test_flow_1_test_tags: "@temperature and not @slow"
+  # …hajoaa heti kun array pituus vaihtelee
+```
+
+**Gitean `inputs` ei tue dynaamisen pituisia listoja.** Projekteilla on 0–n test flow -steppiä.
+
+### Ongelma 2: konfiguraatio kuuluu repoon, ei Gitean UI:hin
+
+Jos kaikki asetukset vietäisiin Gitea org/repo variables -mekanismiin:
+
+- **Versionhallinta katoaa.** Konfiguraation historiaa ei voi tarkastella (`git log`), reviewata (PR), tai rollbackata (`git revert`).
+- **Konfiguraatio irtoaa koodista.** Kun koodi muuttuu ja tarvitsee uuden konfiguraatioavaimen, muutos tehdään Gitean UI:ssa — eri ajankohtana kuin koodimuutos. CI hajoaa välissä.
+- **Ei PR-prosessia konfiguraatiolle.** Gitean variables/secrets eivät kulje review'n läpi.
+- **Siirtäminen ympäristöjen välillä vaikeutuu.** Staging- ja production-Gitealla on eri variablet. Ei `git cherry-pick` -mekanismia.
+
+### Miksi kaksi tiedostoa, ei yksi
+
+Eli miksi projektilla on **sekä** `.gitea/workflows/ci.yml` **että** `ci-flow-values.yaml`?
+
+```
+.gitea/workflows/ci.yml          → MITEN ajetaan (workflow-valinta + parametrit)
+ci-flow-values.yaml              → MITÄ ajetaan (projektin data)
+```
+
+| `.gitea/workflows/ci.yml` | `ci-flow-values.yaml` |
+|---------------------------|----------------------|
+| Sama kaikissa projekteissa | Uniikki per projekti |
+| Asuu projektin repossa (ohut kutsuja) | Asuu projektin repossa |
+| Kopioitavissa, mutta EI sisällä logiikkaa | Versioituu projektin mukana |
+| Välittää parametrit `with:` → kirjastolle | Sisältää: docker-nimi, sonar-projekti, test-flow-array |
+
+### Työnjako Gitea natiivin ja `ci-flow-values.yaml`:n välillä
+
+| Vaatimus | Gitea natiivi | `ci-flow-values.yaml` |
+|----------|--------------|----------------------|
+| Nested-rakenteet (listat, objekit) | Ei (`inputs` = skalaari) | Kyllä (YAML) |
+| Versionhallinta + PR-review | Ei (UI-pohjainen) | Kyllä (`git`) |
+| Projekti omistaa konffinsa | Osittain (repo variables) | Kyllä |
+| Infra-tason salaisuudet | Kyllä (org secrets) | **Ei** |
+| Jaetut infra-arvot | Kyllä (org variables) | **Ei** |
+
+---
+
+## Yhteenveto: moottori + consumer-tiedostot
+
+```
+gitea-ci-library (MOOTTORI)               Jokainen consumer-repo
+┌──────────────────────────────┐          ┌──────────────────────────────┐
+│ Reusable workflowt            │          │ .gitea/workflows/ci.yml      │
+│ ci-feature.yml                │◄─────────│ uses: .../ci-feature.yml@v1  │
+│ ci-master.yml                 │  kutsuu  │                              │
+│ deploy.yml                    │          │ ci-flow-values.yaml          │
+│ test.yml                      │◄─────────│ build.ecosystem: maven       │
+│                               │  lukee   │ docker.imageName: ...        │
+│ Jaetut skriptit               │          │ test-flow: [...]             │
+│ report-status.sh              │          └──────────────────────────────┘
+│ dispatch-workflow.sh          │
+│ push-reports.sh               │          Gitea org
+│ tag-commit.sh                 │          ┌──────────────────────────────┐
+└──────────────────────────────┘          │ secrets: tokenit, salasanat   │
+                                          │ variables: MinIO URL, Sonar   │
+Kirjasto EI sisällä ci.yml:ää             └──────────────────────────────┘
+consumerille — se on moottori,
+joka syö consumerin tuomia tiedostoja.     ci.yml on kopioitavissa,
+                                            identtinen kaikilla consumereilla.
+```
+
+Salaisuudet (tokenit, salasanat) ja jaetut infra-arvot (MinIO URL, SonarQube URL)
+kuuluvat Gitean natiivimekanismeihin (org secrets/variables).
+CI-logiikka kuuluu kirjastoon (moottori).
+Projektikohtainen data (`ci-flow-values.yaml`) ja ohut kutsuja (`ci.yml`) kuuluvat consumer-repoon.
@@ -1,216 +1,52 @@
 # Architecture — Gitea Actions CI -kirjasto

-> Hub-dokumentti. Komponentit, niiden roolit ja rajapinnat. Yksityiskohtaiset kuvaukset linkitetyissä detail-dokumenteissa.
+> ⚠️ POC-vaihe. Tämä dokumentti kuvaa suunniteltua arkkitehtuuria. Toteutus
+> on edelleen kehitysvaiheessa (`ci-engine.yml` on ainoa reusable workflow).
+> Odota uudelleenkirjoitusta ennen kuin luotat tähän dokumenttiin.
 >
-> Tämä dokumentti on **normatiivinen** — se määrittelee mikä on rakennettava. `design-rationale.md` kertoo miksi.
+> Normatiivinen lähde: ADR 0004, ADR 0005, `docs/design-rationale.md`.

 ---

 ## Yleiskuvaus

-Kirjasto on kokoelma **Gitea Actions reusable workflow** -tiedostoja, jotka orkestroivat mikropalveluiden build-, testaus-, raportointi-, deployment- ja test flow -prosessit. Projekti käyttää kirjastoa `uses:`-direktiivillä `.gitea/workflows/*.yml`-tiedostossaan ja määrittelee konfigurationsa `ci-flow-values.yaml`-tiedostossa.
+Kirjasto on kokoelma **Gitea Actions reusable workflow** -tiedostoja, jotka
+orkestroivat mikropalveluiden build-, testaus-, raportointi-, deployment- ja
+test flow -prosessit. Projekti käyttää kirjastoa `uses:`-direktiivillä.

-Kirjasto on Gitea-spesifi. Se hyödyntää Gitean REST API:a commit-statusraportointiin, workflow-dispatchiin ja run-pollaukseen. Raportit tallennetaan MinIO:hon, josta ne ovat selailtavissa HTML-muodossa.
+Kirjasto on Gitea-spesifi. Raportit hallinnoidaan git-pages Helm-chartilla
+(`git-pages/`).

---
+## Provider & Consumer -malli

-## Komponentit
+| Rooli | Kuvaus |
+|-------|--------|
+| **Provider** | `gitea-ci-library` — tarjoaa `ci-engine.yml`:n (lukittu rajapinta) sekä scriptit |
+| **Consumer** | Mikropalveluprojekti — kutsuu `uses:`-direktiivillä, omistaa pipeline-logiikan |

-### Reusable workflowt (4 kpl)
+Tarkemmin: ADR 0005.

-| Workflow | Tiedosto | Rooli |
-|----------|----------|-------|
-| **Feature flow** | `ci-feature.yml` | Testaa feature-branchin, generoi raportit, raportoi statuksen committiin. Ei buildaa konttia. |
-| **Master flow** | `ci-master.yml` | Testaa, buildaa kontin, pushaa rekisteriin, tagittaa commitin, ketjuttaa test flow'n. |
-| **Deployment flow** | `deploy.yml` | GitOps-deployment: päivittää YAML-arvoa, committaa, pushaa, raportoi cross-repo-statuksen. |
-| **Test flow** | `test.yml` | Vastaanottaa dispatchin, ajaa testit, generoi raportit, raportoi statuksen. |
+## Komponentit (POC)

-> Yksityiskohtaiset kuvaukset: [workflows.md](workflows.md)
+| Komponentti | Tila |
+|-------------|------|
+| `ci-engine.yml` | Toimii POC-tasolla. Ainoa reusable workflow. |
+| `publish-git-pages.sh` | Toimii. PATCH tar git-pagesiin. |
+| `report-status.sh` | Toimii. POSTaa commit-status (vain custom-linkkiin). |
+| `dispatch-workflow.sh` | Suunniteltu, ei toteutettu POCissa. |
+| `git-pages/` | Helm-chartti raporttien hostaukseen. Oma kokonaisuus, tarkemmin: `git-pages/docs/`. |

-### Jaetut skriptit
-
-| Skripti | Rooli |
-|---------|-------|
-| **`report-status.sh`** | POSTaa build-statuksen Gitea `/api/v1/repos/{owner}/{repo}/statuses/{sha}` |
-| **`dispatch-workflow.sh`** | Dispatchaa workflow'n toisessa repossa ja pollaa sen valmistumista |
-| **`push-reports.sh`** | Puskaa testiraportit MinIO:hon ja generoi URL:n |
-| **`tag-commit.sh`** | Tagittaa commitin versiolla Gitea REST API:n kautta |
-
-> Yksityiskohtaiset kuvaukset: [shared-scripts.md](shared-scripts.md)
-
-### Konfiguraatio
-
-| Artefakti | Sijainti | Rooli |
-|-----------|----------|-------|
-| **`ci-flow-values.yaml`** | Projektin repo | Projektikohtainen konfiguraatio (docker, sonar, deployment, test-flow) |
-| **Gitea org secrets** | Gitea organization | Tokenit ja salasanat |
-| **Gitea org variables** | Gitea organization | Infra-tason asetukset (MinIO URL, SonarQube URL) |
-
-> Yksityiskohtaiset kuvaukset: [config-model.md](config-model.md)
-
-### Ulkoiset palvelut
+## Ulkoiset palvelut

 | Palvelu | Rooli |
 |---------|-------|
-| **Gitea REST API** | Commit-statusraportointi, workflow-dispatch, run-pollaus, taggaus |
-| **Gitea Packages** | Docker-imagen ja NPM-paketin säilytys |
-| **Gitea act runner** | Suorittaa workflowt. Konteista, DinD:stä ja label-järjestelmästä: [runner.md](runner.md) |
-| **MinIO** | Testiraporttien tallennus ja staattinen web-hosting |
-| **SonarQube** | Koodin laadun analyysi ja quality gate |
+| **Gitea REST API** | Commit-status, workflow-dispatch, run-pollaus |
+| **Gitea Packages** | Docker-imagen säilytys |
+| **git-pages** | Raporttien hostaus |
+| **SonarQube** | Koodin laadun analyysi (suunniteltu) |

---
+## Arkkitehtuuriset rajoitteet

-## Järjestelmäkaavio
-
-```mermaid
-%%{init: {'theme': 'base', 'flowchart': {'arrowheadScale': 2}}}%%
-flowchart TB
-    subgraph PROJ["Projektin repo"]
-        WF[".gitea/workflows/ci.yml
-        uses: gitea-ci-library/ci-master@v1"]
-        CONF["ci-flow-values.yaml"]
-    end
-
-    subgraph LIB["gitea-ci-library (reusable workflowt)"]
-        FEATURE["ci-feature.yml"]
-        MASTER["ci-master.yml"]
-        DEPLOY["deploy.yml"]
-        TEST["test.yml"]
-    end
-
-    subgraph SCRIPTS["Jaetut skriptit"]
-        REPORT["report-status.sh"]
-        DISPATCH["dispatch-workflow.sh"]
-        PUSHREP["push-reports.sh"]
-        TAG["tag-commit.sh"]
-    end
-
-    subgraph EXT["Ulkoiset palvelut"]
-        GITEA["Gitea API
-        + Packages"]
-        MINIO["MinIO
-        (S3 + static web)"]
-        SONAR["SonarQube"]
-    end
-
-    subgraph HELM["Helm-repo"]
-        VALUES["values-{env}.yaml"]
-    end
-
-    subgraph TESTREPO["Testi-repo"]
-        TESTWF[".gitea/workflows/test.yml"]
-    end
-
-    WF -- "kutsuu" --> MASTER
-    WF -- "lukee" --> CONF
-    MASTER -- "käyttää" --> SCRIPTS
-    DEPLOY -- "käyttää" --> SCRIPTS
-    TEST -- "käyttää" --> SCRIPTS
-    REPORT -- "POST status" --> GITEA
-    DISPATCH -- "dispatch + poll" --> GITEA
-    PUSHREP -- "S3 upload" --> MINIO
-    TAG -- "POST tag" --> GITEA
-    MASTER -- "quality gate" --> SONAR
-    DEPLOY -- "muokkaa" --> VALUES
-    DEPLOY -- "commit + push" --> HELM
-    DISPATCH -- "dispatch" --> TESTWF
-    TESTWF -- "raportoi" --> GITEA
-    MINIO -- "URL commit-statusviestiin" --> GITEA
-
-    style PROJ fill:#1e3a5f,color:#f9fafb,stroke:#64748b
-    style LIB fill:#1f2937,color:#f9fafb,stroke:#64748b
-    style SCRIPTS fill:#064e3b,color:#f9fafb,stroke:#64748b
-    style EXT fill:#5c1a1a,color:#f9fafb,stroke:#64748b
-    style HELM fill:#4a1a6b,color:#f9fafb,stroke:#64748b
-    style TESTREPO fill:#4a1a6b,color:#f9fafb,stroke:#64748b
-    style WF fill:#2563eb,color:#ffffff
-    style CONF fill:#f59e0b,color:#111827
-    style FEATURE fill:#2563eb,color:#ffffff
-    style MASTER fill:#2563eb,color:#ffffff
-    style DEPLOY fill:#2563eb,color:#ffffff
-    style TEST fill:#2563eb,color:#ffffff
-    style REPORT fill:#059669,color:#ffffff
-    style DISPATCH fill:#059669,color:#ffffff
-    style PUSHREP fill:#059669,color:#ffffff
-    style TAG fill:#059669,color:#ffffff
-    style GITEA fill:#dc2626,color:#ffffff
-    style MINIO fill:#dc2626,color:#ffffff
-    style SONAR fill:#dc2626,color:#ffffff
-    style VALUES fill:#9333ea,color:#ffffff
-    style TESTWF fill:#9333ea,color:#ffffff
-    linkStyle default stroke:#9ca3af,stroke-width:3px
-```
-
---
-
-## Tietovuot
-
-### 1. Commit-statusraportointi
-
-```
-Workflow-steppi → report-status.sh → POST Gitea API → commitin status päivittyy
-                                                    ↘ URL → raporttiin / buildiin
-```
-
-Jokainen vaihe (test, build, push) POSTaa oman statusviestinsä uniikilla `key`-arvolla. Samaan committiin kertyy useita rinnakkaisia statuksia.
-
-### 2. Cross-repo traceability
-
-```
-Mikropalvelu (root-build)  →  Helm (deployment)  →  Testi (integraatio)
-       ↓                           ↓                       ↓
-  Status omaan committiin    Status omaan committiin  Status omaan committiin
-       ↑                           ↑                       ↑
-  Status root-committiin ←  Status root-committiin ←  Status root-committiin
-  (deployattu, testattu)   (mistä kontti tuli)       (mitä testattiin)
-```
-
-Root-build-viite kulkee `workflow_dispatch`in `inputs`-parametrina koko ketjun läpi.
-
-### 3. Raporttien URL-generointi
-
-```
-push-reports.sh → mc cp ./reports/ minio/bucket/{repo}/{commit_short}/{report}/
-                → URL = {MINIO_BASE}/{repo}/{commit_short}/{report}/index.html
-                → report-status.sh POSTaa URL:n commit-statusviestiin
-```
-
-### 4. Test flow -ketjutus
-
-```
-ci-master.yml → test-flow-taulukko (ci-flow-values.yaml)
-              → for each step:
-                  dispatch-workflow.sh {test-repo} {inputs}
-                  poll Gitea API run status
-                  success? → next step
-                  failure? → stop
-```
-
---
-
-## Laajennuspisteet
-
-| Piste | Mekanismi | Tila |
-|-------|-----------|------|
-| **Docker-rekisterit** | Factory/adapter — `ci-flow-values.yaml` → `docker.type` → valitsee pusherin | MVP: Gitea Packages. Artifactory, Nexus myöhemmin |
-| **Testikehykset** | `push-reports.sh` tukee mitä tahansa hakemistoa → MinIO | Cucumber, JUnit, JaCoCo, Maven Site, custom |
-| **Build-ekosysteemit** | Workflow'n `container:` määrittelee projektin itse | Maven, Gradle, npm, mikä tahansa |
-| **SonarQube** | Rajapinta vaihdettavissa — parempi kuin pollaus tutkitaan | Quality gate -tarkistus |
-
---
-
-## Top-level rajoitteet
-
- Kaikki integraatio Gitea REST API:n kautta — ei suoria tietokantakytkentöjä, ei jaettua filesysteemiä
- Workflowt eivät jaa tilaa keskenään paitsi `workflow_dispatch`in `inputs`-parametrien kautta
- Raporttien URL on deterministinen: `{MINIO_BASE}/{repo_slug}/{commit_short}/{report}/`
- Cross-repo-statusraportoinnissa root-build on aina se mikropalvelun commit, josta ketju käynnistyi
-
-## Repo-jako
-
-| Repo | Sisältö |
-|------|---------|
-| **`gitea-ci-library`** | Reusable workflowt, jaetut skriptit, `report-service/`-moduuli (raporttiskriptit, retention CronJob, index.html-generointi) |
-| **Deployment / infra -repo** (olemassa oleva) | MinIO Kubernetes-manifestit, Traefik OIDC middleware, ConfigMap, ingress |
-
-`gitea-ci-library/report-service/` on oma moduulinsa samassa repossa — ei erillistä repositoriota, mutta selkeä sisäinen raja workflow-skriptien ja raporttipalvelun koodin välillä. Moduuli sisältää `docs/`-hakemiston deploy-esimerkeillä, mutta varsinainen deployment hoidetaan GitOps/Helm-repon kautta kuten muutkin palvelut.
+- `ci-engine.yml` on ainoa consumerin kutsuma rajapinta (ADR 0005)
+- Gitea Actionsin natiivi commit-status on ensisijainen (ADR 0004)
+- Raportit ovat julkisia URL:lla (osoite tunnettava)
@@ -0,0 +1,62 @@
+# CI Pipeline Practices
+
+## 1. Error Taxonomy
+
+| Taso | Esimerkki | Status URL | Job status |
+|---|---|---|---|
+| Tool failure | npx ei löydy, python3 puuttuu | Gitea Actions logi | fail |
+| Test failure | assertio feilaa, testi palauttaa nollasta poikkeavan | Raportti git-pagesissa | fail |
+| Suite failure | Build ei päässyt ajoon | Raportti git-pagesissa | fail |
+
+- Tool ja test erotetaan omiin steppeihin
+- Tool check: `--help` ei riitä, lataa `--dry-run` moduulit
+- Tool fail → linkki Gitea logiin; test fail → linkki raporttiin
+- Jobin status tulee exit-koodista (`exit $?`), ei raporttitiedostojen olemassaolosta
+
+## 2. Job Reporting
+
+- Jokainen suite julkaisee raporttinsa omaan alihakemistoonsa: `reports/{SHA8}/{suite}/`
+- Commit status URL osoittaa suoraan suitelinkkiin
+- Raportit tuotetaan ja julkaistaan aina (`if: always()`) — testin lopputuloksesta riippumatta
+- Linkkejä summary-sivuille ei tarvita — kukaan ei sinne pääse ilman suoraa URLia
+- Index.html suitetason raporttiin generoidaan aina, linkittää kaikkiin suiten tiedostoihin
+
+## 3. Docker-in-Docker Volume Mount
+
+Runner-kontti ja Docker daemon näkevät eri polut. `-v "$PWD":/path` ei toimi — runner-näkökulman polku ei ole daemonin näkökulman polku.
+
+Kolme toimivaa vaihtoehtoa:
+- `container:` keyword — runner hoitaa mountin oikein
+- `docker volume create -- docker run -v volume:/data -- docker run -v volume:/data`
+- `tar c . | docker run --rm -i -v volume:/data alpine tar x -C /data`
+
+## 4. Env variable scope (validated 2026-06-13)
+
+`env:` — oli se workflow- tai job-tasolla — toimii vain **natiiveissa shell-stepeissä** ja `docker run -e VAR` -komennoissa. `docker run` ilman `-e`-lippua **ei peri** `env:`-muuttujia.
+
+Tämä on validioitu POC-ajolla: `tmp/poc-env-scope.yml`
+
+| Sijainti | Native shell | `docker run` ilman `-e` | `docker run -e VAR` |
+|----------|-------------|------------------------|---------------------|
+| workflow `env:` | ✅ perii | ❌ tyhjä | ✅ perii |
+| job `env:` | ✅ perii | ❌ tyhjä | ✅ perii |
+| `GITHUB_ENV` | ✅ perii | ❌ tyhjä | ✅ perii |
+
+Käytäntö:
+- Workflow-tason `env:` sopii arvoille, joita tarvitaan natiivistepeissä (publish, status, reportointi)
+- Jos `docker run` tarvitsee env-arvoja, välitä ne eksplisiittisesti `-e VAR`-lipulla
+- `GITHUB_ENV` on validi tapa välittää arvoja stepien välille samassa jobissa, mutta ei leviä `docker run`-kontteihin ilman `-e`-lippua
+
+## 5. Pipeline Provides All Dependencies
+
+- Ei luottamusta runnerin esiasennettuihin työkaluihin
+- `apk add`, `npm install`, `apt-get install` — kaikki pipelinesta
+- Erityisesti: `curl`, `lsof`, `jq`, `python3` unohtuvat helposti
+- Node-version päivitettävä jos paketti vaatii uudempaa (`node:20` → `node:22`)
+- Jos kontin entrypoint on `sh` (Alpine ash), käytä `--entrypoint bash`
+
+## 6. Rakenne
+
+- Rinnakkaiset jobit (bats + cucumber) — tuloksia saa heti kun valmistuu
+- Jokainen testisetti omassa jobissaan
+- Finalize/build voi kerätä yhteenvedon (ei julkaista summarya jos kenelläkään ei ole linkkiä)
@@ -1,6 +1,14 @@
 # Konfiguraatiomalli — `ci-flow-values.yaml`

-> Kuuluu arkkitehtuuriin: [architecture.md](architecture.md). Tämä dokumentti määrittelee projektikohtaisen konfiguraation skeeman, `isContainerBuild()`-mekanismin ja version check -skriptin.
+> ⚠️ **POC-vaihe.** Tämä dokumentti on peritty Jenkins-versiosta ja sisältää
+> Docker-spesifistä legacyä (isContainerBuild, Docker-labelit). POC osoitti,
+> että provider on agnostinen consumerin build-ekosysteemille.
+>
+> Uusi ajattelu: `isContainerBuild()` → `isArtifactBuild()`. Provider ei
+> tiedä eikä tarvitse tietää, buildaako consumer kontin, JARin, npm-paketin
+> vai mitään muuta. Dokumentti odottaa uudelleenkirjoitusta.
+>
+> Normatiivinen lähde: `docs/design-rationale.md`, ADR 0005.

 ---

@@ -116,11 +124,20 @@ Array testi-steppejä. Jokainen steppi on joko `deploy` tai `test`.

 ---

-## `isContainerBuild()`-mekanismi
+## `isArtifactBuild()`-mekanismi (POC: suunniteltu, ei toteutettu)

-**Ongelma:** Samaa committia vasten voidaan ajaa master-workflow useita kertoja. On mieletöntä buildata kontti uudestaan, koska commit on jo tagätty versiolla ja kontti on olemassa rekisterissä. Uudelleenbuildaus aiheuttaa versiokonflikteja ja tuhlaa CI-aikaa.
+> **Jenkins-legacy:** Jenkins-versiossa tämä oli `isContainerBuild()`. POC
+> osoitti, että provider ei tiedä eikä tarvitse tietää, buildaako consumer
+> kontin, JARin vai npm-paketin. Siksi `isContainerBuild()` →
+> `isArtifactBuild()`.

-**Ratkaisu:** Workflow'n alussa tarkistetaan, onko tälle commitille jo olemassa versiotagi:
+**Ongelma:** Samaa committia vasten voidaan ajaa master-workflow useita
+kertoja. On mieletöntä buildata artifakti uudestaan, koska commit on jo
+tagätty versiolla ja artifakti on olemassa rekisterissä. Uudelleenbuildaus
+aiheuttaa versiokonflikteja ja tuhlaa CI-aikaa.
+
+**Ratkaisu:** Workflow'n alussa tarkistetaan, onko tälle commitille jo
+olemassa versiotagi.

 ```bash
 # is-container-built.sh
@@ -156,34 +173,8 @@ jobs:

 **Miksi tämä on välttämätöntä:**
 - Estää versiokonfliktit: `1.2.3.42` ei voi olla kahdesti
- Säästää CI-aikaa: kontin buildaus on hitain vaihe
- Pitää commitin ja kontin välisen suhteen yksiselitteisenä: `git tag` kertoo suoraan mikä versio vastaa tätä committia
-
---
-
-## Docker-labelit
-
-Jenkins-versiossa konttiin injektoitiin metadataa Docker-labelien kautta. Sama käytäntö jatkuu:
-
-```bash
-docker build \
-  --label "git.commit=${GITHUB_SHA::8}"      \
-  --label "git.commitBy=${GITHUB_ACTOR}"     \
-  --label "build.date=$(date -u +'%Y-%m-%dT%H:%M:%SZ')" \
-  --label "build.run=${GITHUB_RUN_NUMBER}"   \
-  --label "version=${DOCKER_VERSION}"        \
-  -t ${DOCKER_TAG} .
-```
-
-| Label | Arvo | Lähde |
-|-------|------|-------|
-| `git.commit` | 8-merkkinen hash | `GITHUB_SHA::8` |
-| `git.commitBy` | Ajon laukaisija | `GITHUB_ACTOR` |
-| `build.date` | ISO 8601 UTC | `date -u` |
-| `build.run` | Ajon järjestysnumero | `GITHUB_RUN_NUMBER` |
-| `version` | Kontin versio | `1.2.3.42` |
-
-Näillä labeleilla kontista näkee suoraan: kuka buildasi, milloin, mistä commitista, millä versiolla. Vianjäljitys kontista koodiin on suora.
+- Säästää CI-aikaa: artifaktin buildaus on hitain vaihe
+- Pitää commitin ja artifaktin välisen suhteen yksiselitteisenä: `git tag` kertoo suoraan mikä versio vastaa tätä committia

 ---

@@ -12,21 +12,45 @@ Organisaatiolla on tuotannossa Jenkins-pohjainen CI-järjestelmä (`ci-jenkins-l

 Jenkins on kuitenkin raskas ylläpitää Kubernetesissa, ja organisaatio on siirtymässä Giteaan. Tavoitteena on **sama toiminnallisuus, pienemmällä ylläpitotaakalla**, hyödyntäen Gitea Actionsin natiiveja ominaisuuksia.

-Kirjasto ei ole Jenkins-migraatiotyökalu. Se on Gitea Actions -natiivi uudelleensuunnittelu, joka säilyttää Jenkins-version todistetut patternit mutta hylkää ne osat, jotka olivat sidottuja Jenkinsin arkkitehtuuriin.
+Kirjasto ei ole Jenkins-migraatiotyökalu. Se on Gitea Actions -natiivi
+uudelleensuunnittelu, joka säilyttää Jenkins-version todistetut patternit
+mutta hylkää ne osat, jotka olivat sidottuja Jenkinsin arkkitehtuuriin.
+Gitea Actionsin ja Gitean natiiveja ominaisuuksia hyödynnetään aina kun
+mahdollista — uutta kilpailevaa toteutusta ei kirjoiteta, jos toimiva
+ratkaisu on jo olemassa.

 ---

 ## Suunnitteluperiaatteet

-### 1. Git-commit on universaali statusnäkymä
+### 1. Hyödynnä natiivia
+
+Gitea Actionsin ja Gitean natiiveja ominaisuuksia käytetään aina kun ne
+riittävät. Uutta kilpailevaa toteutusta ei kirjoiteta, jos toimiva ratkaisu
+on jo olemassa.
+
+**Miksi:** Oma toteutus on aina ylläpidettävä, testattava ja
+dokumentoitava. Natiivi ominaisuus tulee ilmaiseksi, kehittyy alustan
+mukana ja on käyttäjälle tuttu.
+
+**Esimerkkejä:**
+- Gitea Actions näyttää jobien statuksen automaattisesti — omaa
+  commit-status API -kutsua ei tarvita jokaiselle vaiheelle
+- Gitea organization secrets/variables korvaa erillisen credential-hallinnan
+- Reusable workflow -mekanismi korvaa custom action -runtimen
+
+### 2. Git-commit on universaali statusnäkymä

 Buildin jokainen vaihe raportoi tilansa Git-committiin. Kehittäjä näkee yhdellä silmäyksellä, missä vaiheessa build on — ei tarvitse navigoida CI-järjestelmän UI:hun.

 **Miksi:** Jenkins-versio osoitti, että commit-statusviestit poistavat tarpeen CI-dashboardille. Kehittäjä työskentelee Gitissä, joten status kuuluu Gitiin. Statusviestien `url`-kenttä linkittää suoraan raportteihin — Cucumber-tulokset, SonarQube-tulokset, Docker-rekisteri — ilman että URL tarvitsee etsiä erikseen.

-**Mitä tarkoittaa käytännössä:** Jokainen `testBegin/End`, `buildBegin/End`, `pushBegin/End`-vaihe POSTaa Gitean REST APIin (`/api/v1/repos/{owner}/{repo}/statuses/{sha}`). Uniikki `key` per vaihe estää duplikaatit ja mahdollistaa rinnakkaiset statukset samassa commitissa.
+**Mitä tarkoittaa käytännössä:** Gitea Actions näyttää jobien tilan
+(checkmark/risti/spinner) commit-näkymässä automaattisesti. API:a
+(`/api/v1/repos/{owner}/{repo}/statuses/{sha}`) käytetään vain
+custom-raporttilinkin välittämiseen. ADR 0004.

-### 2. Reusable workflow — ei omaa runtimea
+### 3. Reusable workflow — ei omaa runtimea

 Kirjasto jaetaan Gitea Actionsin reusable workflow -mekanismilla. Ei Docker-pohjaisia custom actioneita, ei erillistä ajonaikaista palvelinta.

@@ -34,15 +58,17 @@ Kirjasto jaetaan Gitea Actionsin reusable workflow -mekanismilla. Ei Docker-pohj

 **Mitä tämä ei ole:** Tämä ei ole monorepo-työkalu, joka asennetaan projekteihin. Tämä on joukko `.gitea/workflows/`-tiedostoja, joihin mikropalvelut viittaavat `uses:`-direktiivillä.

-### 3. Konfiguraatio kuuluu repoon
+### 4. Konfiguraatio kuuluu repoon

 Projektikohtainen konfiguraatio (`ci-flow-values.yaml`-tyyppinen tiedosto) asuu mikropalvelun omassa repossa. Reusable workflow lukee sen, ei toisinpäin.

 **Miksi:** Mikropalvelun kehittäjä omistaa buildinsa. Hän tietää mitä Dockefileä käytetään, mitä SonarQube-projektia, mitä testi-steppejä tarvitaan. Jos konfiguraatio hajautetaan useaan repoon, muutokset vaativat koordinaatiota, ja yhden totuuden lähteen periaate rikkoutuu.

-**Poikkeus:** Infra-tason asetukset (MinIO-URL, Gitea-instanssin URL) ovat organisaatiotasolla Gitean organization secrets/variables -mekanismissa. Ne eivät ole repokohtaisia, koska DNS voi osoittaa eri paikkaan kuin repo, ja usean repossa toistuva sama arvo on ylläpitoriski.
+**Poikkeus:** Infra-tason asetukset (git-pages host, Gitea-instanssin URL)
+ovat organisaatiotasolla Gitean organization secrets/variables
+-mekanismissa. Ne eivät ole repokohtaisia.

-### 4. Deterministinen testigraafi, vaiheittainen suoritus
+### 5. Deterministinen testigraafi, vaiheittainen suoritus

 Test flow on tunnettu ennen buildin alkua, ja testit ajetaan yksi kerrallaan. Jos steppi epäonnistuu, koko flow pysähtyy.

@@ -50,13 +76,18 @@ Test flow on tunnettu ennen buildin alkua, ja testit ajetaan yksi kerrallaan. Jo

 **Miten:** Orkestroiva workflow käyttää Gitea REST API:a workflow-dispatchiin ja pollaa ajettavan workflow'n tilaa synkronisesti (`GET /api/v1/repos/{owner}/{repo}/actions/runs/{id}`). Tämä vastaa Jenkinsin `buildJob()`-kutsun semantiikkaa, mutta toteutetaan curl + pollaus -silmukalla.

-### 5. Raportit ovat selailtavia URL:n takana
+### 6. Raporttien hallinta erillisellä palvelulla

-Testiraportit (Cucumber HTML, Jacoco HTML, JUnit XML) viedään MinIO:hon, jonka staattinen web-hosting renderöi ne selaimessa. URL linkitetään Git-committiin.
+Raporttien selailtavuudesta ja elinkaaresta vastaa erillinen palvelu, joka
+asennetaan git-pages Helm-chartilla. Raportit ovat julkisia URL:lla
+(osoite tunnettava). URL linkitetään Git-committiin.

-**Miksi:** Jenkins-versiossa linkki Cucumber-raporttiin oli kriittinen feature — kehittäjä klikkasi commitin statusviestistä ja näki heti mitkä testit epäonnistuivat. Gitea Actionsin sisäänrakennettu artifact-järjestelmä ei tue HTML-selailtavuutta (vain ZIP-lataus). MinIO täyttää tämän aukon: se on kevyt, Kubernetes-natiivi, ja sen S3 API on standardi. URL-rakenne `{BASE}/{repo_slug}/{commit_short}/{report_type}/` on ennustettavissa ilman erillistä URL-generaattoria.
+**Miksi:** Jenkins-versiossa linkki Cucumber-raporttiin oli kriittinen
+feature. Gitea Actionsin artifact-järjestelmä ei tue HTML-selailtavuutta
+(vain ZIP-lataus). Erillinen palvelu mahdollistaa hallitun retention ja
+pääsyn ilman CI-alustan rajoitteita.

-### 6. Yksi CI-alusta, yksi integraatiopiste
+### 7. Yksi CI-alusta, yksi integraatiopiste

 Kirjasto tukee vain Giteaa. Ei GitLab-, BitBucket- tai GitHub-abstraktioita.

@@ -64,7 +95,7 @@ Kirjasto tukee vain Giteaa. Ei GitLab-, BitBucket- tai GitHub-abstraktioita.

 **Mitä tarkoittaa tulevaisuudessa:** Jos toinen alusta tulee ajankohtaiseksi, Gitea-versiota käytetään joko pohjana redesignille tai mallina erilliselle toteutukselle. Rajapintoja ei suunnitella etukäteen alustariippumattomiksi — se on ennenaikaista optimointia.

-### 7. Cross-repo commit traceability
+### 8. Cross-repo commit traceability

 Kun build-ketju ylittää reporajat (mikropalvelu → deployment → integraatiotestit → e2e-testit), jokainen vaihe raportoi kahteen suuntaan: omaan committiinsa ja takaisin root-committiin, josta ketju käynnistyi.

@@ -128,18 +159,7 @@ sequenceDiagram

 ---

-## Teknologiavalinnat (seurauksina ylläolevista periaatteista)
-
-| Valinta | Miksi |
-|---------|------|
-| **Gitea Actions reusable workflows** | Periaate 2: natiivein tapa jakaa CI-logiikkaa ilman omaa runtimea |
-| **Gitea REST API** (`/api/v1/...`) | Periaate 1: commit-statusraportointi. Periaate 4: workflow-dispatch ja status-pollaus. Periaate 7: cross-repo statusraportointi useaan committiin |
-| **MinIO** (S3-yhteensopiva) | Periaate 5: HTML-selailtavat raportit ilman ulkoista palvelinta. Kubernetes-natiivi, yksi binääri |
-| **YAML** konfiguraatioformaattina | Periaate 3: repo omistaa konffinsa. YAML on luettava, versioitava ja tuttu Jenkins-versiosta |
-| **curl + jq + bash** integraatiokerroksena | Periaate 2: ei custom action -runtimea. Gitea REST API:a kutsutaan suoraan workflow-stepistä |
-| **Gitea organization secrets/variables** | Periaate 3: infra-tason asetukset (MinIO-URL, tokenit) eivät kuulu reposuuteen |
-
---
+## Mitä tietoisesti hylättiin

 ## Mitä tietoisesti hylättiin

@@ -1,199 +1,6 @@
-# Raporttivarasto — MinIO
+# Raporttivarasto

-> Kuuluu arkkitehtuuriin: [architecture.md](architecture.md). Tämä dokumentti määrittelee testiraporttien tallennuksen, URL-rakenteen, autentikoinnin ja retention policyn.
+Raporttien hostaus: `git-pages/`-Helm-chartti. Tarkempi dokumentaatio:
+`git-pages/README.md` ja `git-pages/docs/`.

---
-
-## Miksi MinIO
-
-Gitea Actionsin sisäänrakennettu artifact-järjestelmä ei tue HTML-selailtavuutta (vain ZIP-lataus), ja artifactien retentio on aikapohjainen (oletus 90 vrk). Jenkins-versiossa raportit olivat selailtavissa suoraan buildista ja pysyivät build-historian mukana.
-
-MinIO täyttää tämän aukon:
-
- **S3-yhteensopiva** — standardi API, laaja työkalutuki (`mc`, `s3cmd`, AWS SDK)
- **Staattinen web-hosting** — HTML-raportit renderöityvät selaimessa suoraan bucketista
- **Kubernetes-natiivi** — yksi binääri, helppo deployata samaan klusteriin
- **Ei per-repo-konfiguraatiota** — yksi bucket palvelee kaikkia projekteja
- **Ennustettava URL** — polku rakentuu deterministisesti reposta ja commitista
-
-## URL-rakenne
-
-```
-{MINIO_BASE}/{repo_slug}/{commit_short}/{report_type}/index.html
-```
-
-| Osa | Lähde | Esimerkki |
-|-----|-------|-----------|
-| `MINIO_BASE` | Gitea org variable `MINIO_BASE_URL` | `https://reports.smith.keskikuja.site` |
-| `repo_slug` | `GITHUB_REPOSITORY` → slug | `temperature-store` |
-| `commit_short` | `GITHUB_SHA` → 8 merkkiä | `abc12345` |
-| `report_type` | Raportin tyyppi | `cucumber`, `jacoco`, `junit`, `site` |
-
-URL rakennetaan `push-reports.sh`-skriptissä ja POSTataan Gitea-commitin statusviestiin `url`-kenttään.
-
-## Staattinen web-hosting
-
-MinIO-bucket konfiguroidaan staattiseksi web-sivustoksi:
-
-```bash
-mc anonymous set download minio/reports
-mc website create minio/reports --region us-east-1
-```
-
-Bucketin rakenne:
-
-```
-reports/
-├── temperature-store/
-│   ├── abc12345/
-│   │   ├── cucumber/
-│   │   │   └── overview-features.html
-│   │   ├── jacoco/
-│   │   │   └── index.html
-│   │   └── site/
-│   │       └── index.html
-│   └── def67890/
-│       └── ...
-├── user-service/
-│   └── ...
-```
-
-Jokaisella buildilla on oma `{commit_short}`-hakemistonsa — ei race conditionia rinnakkaisten buildien välillä.
-
-## Autentikointi: OIDC + Traefik middleware
-
-Raporttien tulee olla katseltavissa ilman erillistä kirjautumista (muuten commitin statusviestin URL-linkki ei toimi suoraan). Samalla julkinen bucket halutaan suojata.
-
-**Ratkaisu:** MinIO asetetaan Traefik reverse-proxyn taakse. Traefik middleware hoitaa OIDC-autentikoinnin, jossa:
-
-1. Käyttäjä klikkaa raportin URL:ää commitin statusviestistä
-2. Traefik ohjaa OIDC-kirjautumiseen (Gitea OAuth2 provider)
-3. Onnistuneen kirjautumisen jälkeen käyttäjä ohjataan raporttiin
-4. Session säilyy — ei tarvitse kirjautua jokaista raporttia varten
-
-```
-Selain ──→ Traefik ──→ OIDC middleware ──→ Gitea OAuth2
-                     │
-                     └──→ MinIO (bucket reports, static web)
-```
-
-**CI-pusku ohittaa OIDC:n:** Workflow'n `push-reports.sh` käyttää MinIO:n S3 API:a suoraan access key + secret key -parilla (Gitea org secrets). CI-liikenne ei kulje julkisen ingressin kautta — `mc`-työkalu puhuu suoraan MinIO-palvelulle klusterin sisällä.
-
-## Retention policy
-
-Pelkkä aikaperustainen retentio ("poista yli 90 vrk vanhat") ei riitä. Retention policyn pitää huomioida:
-
-| Kriteeri | Kuvaus |
-|----------|--------|
-| **Aika** | Raportti säilyy X päivää buildin jälkeen |
-| **Branch** | `master`-branchin raportit säilyvät pidempään kuin feature-branchien |
-| **Tagi** | Version kanssa tagitun commitin raportteja ei poisteta koskaan |
-| **Viimeisin N** | Jokaisesta branchista säilytetään vähintään N uusinta raporttia |
-
-**Toteutus:** Retention policy konfiguroidaan **ConfigMap:lla**, jonka siivousskripti lukee. ConfigMap on osa MinIO-deploymentin Kubernetes-manifestia.
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: minio-report-retention
-data:
-  retention.yaml: |
-    rules:
-      - branch: "master"
-        maxAgeDays: 365
-        keepMin: 20
-      - branch: "feature/*"
-        maxAgeDays: 90
-        keepMin: 5
-      - tagged: true
-        maxAgeDays: -1     # ei koskaan poisteta
-        keepMin: -1
-      - default:
-        maxAgeDays: 90
-        keepMin: 3
-```
-
-Siivoussripti ajetaan CronJobina (esim. kerran päivässä):
-
-1. Listaa kaikki bucketin objektit
-2. Parsii polusta `repo_slug` ja `commit_short`
-3. Hakee Gitea API:sta commitin metadata (branch, onko tagattu)
-4. Soveltaa ConfigMapin retention-sääntöjä
-5. Poistaa vanhentuneet objektit `mc rm`:llä
-
-## Raporttien pushaus workflow'sta
-
-`push-reports.sh`:
-
-```bash
-#!/bin/bash
-# Käyttö: push-reports.sh <report_type> <source_dir>
-# Esim:   push-reports.sh cucumber target/cucumber-report/
-
-REPORT_TYPE=$1
-SOURCE_DIR=$2
-TARGET="minio/reports/${GITHUB_REPOSITORY}/${GITHUB_SHA::8}/${REPORT_TYPE}/"
-
-mc cp --recursive "$SOURCE_DIR" "$TARGET"
-
-echo "${MINIO_BASE_URL}/${GITHUB_REPOSITORY}/${GITHUB_SHA::8}/${REPORT_TYPE}/index.html"
-```
-
-Skripti palauttaa URL:n, joka syötetään `report-status.sh`:lle commit-statusviestin `url`-kenttään.
-
-## Konfiguraatio Giteassa
-
-| Secret / Variable | Tyyppi | Sisältö |
-|---|---|---|
-| `MINIO_ACCESS_KEY` | Org secret | MinIO access key |
-| `MINIO_SECRET_KEY` | Org secret | MinIO secret key |
-| `MINIO_BASE_URL` | Org variable | `https://reports.smith.keskikuja.site` |
-
-Workflow lukee nämä automaattisesti — projekti ei määrittele niitä `ci-flow-values.yaml`:ssa.
-
-## MinIO-deployment (viitteellinen)
-
-Minimalistinen Kubernetes-deployment samassa klusterissa:
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: minio-reports
-spec:
-  replicas: 1
-  template:
-    spec:
-      containers:
-      - name: minio
-        image: minio/minio:latest
-        args: ["server", "/data", "--console-address", ":9001"]
-        env:
-        - name: MINIO_ROOT_USER
-          valueFrom:
-            secretKeyRef:
-              name: minio-secrets
-              key: access-key
-        - name: MINIO_ROOT_PASSWORD
-          valueFrom:
-            secretKeyRef:
-              name: minio-secrets
-              key: secret-key
-        ports:
-        - containerPort: 9000   # S3 API
-        - containerPort: 9001   # Console UI
-        volumeMounts:
-        - name: data
-          mountPath: /data
-      volumes:
-      - name: data
-        persistentVolumeClaim:
-          claimName: minio-reports-pvc
-```
-
-## Huomioitavaa
-
- **Bucketin luonti ja web-hostingin aktivointi** tehdään kerran deploymentin yhteydessä. Ei per build.
- **URL on deterministinen** — raportin URL voidaan generoida jo ennen kuin raportti on pushattu. Jos raporttihakemistoa ei ole (esim. testit skipattiin), linkki johtaa 404:ään.
- **Indeksitiedoston nimi** riippuu raporttityypistä: Cucumber → `overview-features.html`, JaCoCo → `index.html`, Maven Site → `index.html`. `push-reports.sh`:n vastuulla varmistaa, että indeksitiedosto löytyy.
+Tämä dokumentti on korvattu git-pages-kohtaisella dokumentaatiolla.
@@ -1,8 +1,12 @@
 # Jaetut skriptit

-> Kuuluu arkkitehtuuriin: [architecture.md](architecture.md). Tämä dokumentti määrittelee reusable workflow'sta kutsuttavien bash-skriptien rajapinnat, parametrit ja vastuut.
+> ⚠️ **POC-vaihe.** Osa kuvatuista skripteistä (push-reports.sh, tag-commit.sh)
+> on suunniteltu mutta ei toteutettu. Toteutetut: `publish-git-pages.sh`,
+> `report-status.sh`, `dispatch-workflow.sh` (POC-taso).
+>
+> Uudelleenkirjoitus odottaa: skriptien määrä ja rajapinnat voivat muuttua.

-Skriptit asuvat `gitea-ci-library/scripts/`-hakemistossa. Workflowt lataavat ne checkout-stepin jälkeen.
+Skriptit asuvat `gitea-ci-library/scripts/`-hakemistossa.

 ---

@@ -91,9 +95,9 @@ dispatch-workflow.sh "tests/integration" "test.yml" "main" \

 ---

-## `push-reports.sh`
+## `push-reports.sh` (vanhentunut — korvattu `publish-git-pages.sh`:lla)

-Puskaa raporttihakemiston MinIO:hon ja päivittää indeksisivut.
+Puskaa raporttihakemiston git-pagesiin.

 ### Rajapinta

@@ -1,109 +1,39 @@
 # Tech Stack — Gitea Actions CI -kirjasto

-> Absoluuttinen lähde sille, mitä teknologioita kirjasto käyttää ja tukee. Tämä dokumentti laaditaan `design-rationale.md`:n pohjalta. Mitään tässä listaamatonta teknologiaa ei oleteta olevan käytössä.
+> ⚠️ POC-vaihe. Osa teknologiavalinnoista voi muuttua uudelleenkirjoituksen
+> myötä. Katso myös `git-pages/docs/tech-stack.md`.

 ---

 ## Kirjaston oma runtime

-Kirjasto itsessään on kokoelma **Gitea Actions reusable workflow** -tiedostoja (`.gitea/workflows/*.yml`). Ajonaikaiset stepit käyttävät:
-
 | Teknologia | Versio / minimi | Käyttötarkoitus |
 |---|---|---|
 | **Gitea Actions** | 1.21+ | CI-alusta, workflow-moottori |
 | **Gitea act runner** | 0.2+ | Workflow'n suoritus |
 | **Bash** | 4.0+ | Integraatioskriptit workflow-stepeissä |
-| **curl** | 7.0+ | Gitea REST API -kutsut (statusraportointi, dispatch, pollaus) |
-| **jq** | 1.6+ | JSON-vastausten jäsennys REST API -kutsuista |
-| **git** | 2.30+ | SCM-operaatiot (checkout, tag, push) |
-| **MinIO client (mc)** | latest | Raporttien pushaus MinIO:hon ja URL-generointi |
+| **curl** | 7.0+ | Gitea REST API, git-pages PATCH |
+| **jq** | 1.6+ | JSON-vastausten jäsennys |

---
+## Raporttien hostaus

-## Konfiguraatio
-
-| Teknologia | Käyttötarkoitus |
-|---|---|
-| **YAML** | Projektikohtainen konfiguraatio (`ci-flow-values.yaml`) |
-| **Gitea organization secrets** | Tokenit ja salasanat (Gitea API -token, MinIO credentials) |
-| **Gitea organization variables** | Infra-tason asetukset (MinIO base URL, SonarQube URL) |
-
---
+Raportit hostataan git-pages-palvelulla (`git-pages/`-Helm-chartti).
+Julkaisu: `scripts/publish-git-pages.sh` → PATCH tar. Tarkemmat
+teknologiavalinnat: `git-pages/docs/tech-stack.md`.

 ## Tuetut ulkoiset palvelut

-Kirjasto integroituu näihin ulkoisiin palveluihin workflow-stepeistä käsin. Palvelut eivät ole osa kirjastoa.
-
 | Palvelu | Rajapinta | Käyttötarkoitus |
 |---|---|---|
-| **Gitea REST API** | `/api/v1/` | Commit-statusraportointi, workflow-dispatch, run-status-pollaus, taggaus |
-| **MinIO** | S3 API + staattinen web-hosting | Testiraporttien tallennus ja selailu |
-| **SonarQube** | REST API (`/api/`) | Quality gate -pollaus, dashboard-linkitys |
-| **Gitea Packages** | Container registry API | Docker-imagen push ja taggaus |
-
---
-
-## Tuetut build-ekosysteemit
-
-Kirjasto tukee näitä käyttäjäprojektien build-työkaluja. Työkalut asennetaan workflow'n ajonaikaiseen konttiin (projektin itse määrittelemään).
-
-| Ekosysteemi | Työkalut | Artifact-tyypit |
-|---|---|---|
-| **Java / Maven** | `mvn`, `java` | JAR, Docker |
-| **Java / Gradle** | `gradle`, `java` | JAR, Docker |
-| **Node.js / npm** | `npm`, `node` | npm-paketti, Docker |
-| **Docker** | `docker`, `docker buildx` | Docker-image |
-
---
-
-## Tuetut testikehykset
-
-Kirjasto generoi ja julkaisee raportit näistä testikehyksistä. Itse testikehysten ajurit ovat käyttäjäprojektissa.
-
-| Testikehys | Raporttiformaatti | MinIO-kohde |
-|---|---|---|
-| **Cucumber** | HTML (Cucumber Reports) | `/{commit_short}/cucumber/` |
-| **JUnit** | XML | `/{commit_short}/junit/` |
-| **JaCoCo** | HTML | `/{commit_short}/jacoco/` |
-| **Maven Site** | HTML | `/{commit_short}/site/` |
-| **Mukautettu HTML** | HTML | `/{commit_short}/{report_name}/` |
-
---
-
-## Tuetut deployment-työkalut
-
-| Työkalu | Käyttötarkoitus |
-|---|---|
-| **Helm v3** | Kubernetes-deployment (arvot `values-{environment}.yaml`) |
-| **Kubernetes** | Ajonaikainen ympäristö (testiympäristöt, tuotanto) |
-
---
+| **Gitea REST API** | `/api/v1/` | Commit-status, workflow-dispatch, branch-listaus (retention) |
+| **git-pages** | HTTP | Raporttien hostaus |
+| **Gitea Packages** | Container registry API | Docker-imagen push |

 ## Mitä EI tueta (verrattuna Jenkins-versioon)

-Nämä olivat Jenkins-kirjastossa, mutta on tietoisesti jätetty pois Gitea Actions -versiosta:
-
 | Teknologia | Syy |
 |---|---|
-| **GitLab REST API** | Ei multi-platform-tukea (periaate 6) |
-| **BitBucket Server REST API** | Ei multi-platform-tukea |
-| **BitBucket Cloud REST API** | Ei multi-platform-tukea |
-| **Jenkins** (shared library, cucumber plugin, publishHTML, jacoco plugin, buildJob) | Ei Jenkins-riippuvuutta — Gitea Actions korvaa |
-| **Artifactory** (Docker registry) | MVP:ssä ei. Factory/adapter-patternilla lisättävissä myöhemmin |
-| **Nexus** (Docker registry) | MVP:ssä ei. Factory/adapter-patternilla lisättävissä myöhemmin |
-| **Artifactory** (npm registry) | MVP:ssä ei. Factory/adapter-patternilla lisättävissä myöhemmin |
-| **Groovy** | Jenkins-spesifi. Korvautuu Bashilla ja YAML:lla |
-
---
-
-## Huomautus: Docker-rekisterit
-
-MVP:ssä tuetaan vain **Gitea Packages** (Container registry). Arkkitehtuuriin suunnitellaan factory/adapter-pattern, jolla Artifactory ja Nexus voidaan lisätä myöhemmin ilman workflow-muutoksia. Rekisteri konfiguroidaan `ci-flow-values.yaml`:n `docker`-osiossa `type`-kentällä (vrt. Jenkins `ArtifactRepoType`-enum).
-
-## Huomautus: SonarQube-integraatio
-
-Jenkins-versio pollasi quality gatea: `GET /api/project_analyses/search` → etsi uusin analyysi → `GET /api/qualitygates/project_status?analysisId=X`. SonarQubessa on tätä parempi rajapinta. Tutkitaan arkkitehtuurivaiheessa.
-
-## Huomautus: Docker-in-Docker
-
-Gitea Actions tukee Docker-in-Dockeria natiivisti `services:`-määrittelyllä workflow-tiedostossa. Tämä vastaa Jenkinsin `podTemplate`-konttia `docker:19.03.1-dind` + `docker:19.03.1` sidecar-mallia. Projektin workflow määrittelee tarvittavat kontit itse — reusable workflow ei pakota tiettyä konttivalikoimaa.
+| **MinIO** | Korvattu git-pagesilla |
+| **Multi-Git-platform** | Vain Gitea |
+| **Jenkins** (shared library, plugins) | Gitea Actions korvaa |
+| **Artifactory/Nexus** | MVP:ssä ei, factory/adapter-pattern valmiina |
@@ -1,8 +1,8 @@
-# Ticket 0006: `ci-feature.yml` (reusable workflow)
+# Ticket 0006: Pipeline as conf

 **Vaihe:** 6/12
 **Status:** pending
-**Feature branch:** `feature/0006-ci-feature-yml`
+**Feature branch:** `feature/0006-pipeline-as-conf`
 **TDD required:** Yes
 **Feature file required:** Yes

@@ -11,6 +11,9 @@
 - `tests/features/0006-ci-feature.feature`
 - Skills: `tdd`, `implementation`, `clean-code`

+**Pre-requisite (estotiketti):**
+- Pipeline-as-conf -suunnitelma (`docs/tickets/0006-plan.md` tai vastaava) on valmis ja hyväksytty. Toteutusta ei aloiteta ennen kuin `ci-flow-values.yaml`-skeema ja `ci-feature.yml`-jobirakenne on suunniteltu.
+
 ---

 ## TDD — Red-Green-Refactor + Dogfood
@@ -27,7 +30,7 @@ bats tests/workflows.bats
 ```

 ### Green
-Toteuta `gitea/workflows/ci-feature.yml`.
+Toteuta `.gitea/workflows/ci-feature.yml`.

 ```bash
 bats tests/workflows.bats
@@ -35,12 +38,12 @@ bats tests/workflows.bats
 ```

 ### Dogfood
-Lisää kutsu `gitea/workflows/ci.yml`:stä:
+Lisää kutsu `.gitea/workflows/ci.yml`:stä:

 ```yaml
 feature:
  if: github.ref != 'refs/heads/master'
-  uses: ./gitea/workflows/ci-feature.yml@main
+  uses: ./.gitea/workflows/ci-feature.yml
 ```

 Jokainen push feature-branchiin ajaa `ci-feature.yml`:n.
@@ -48,16 +51,19 @@ Jokainen push feature-branchiin ajaa `ci-feature.yml`:n.
 ## DoD
 - [ ] Cucumber: `@ticket-0006 and @mock` → kaikki skenaariot GREEN
 - [ ] `tests/workflows.bats` — YAML-validointi läpi
- [ ] Kaikki stepit määritelty: start → unit-test → code-coverage → publish-html → end
+- [ ] 4 jobia: `start` → `unit-test` → `code-coverage` → `end`
 - [ ] `concurrency` estää rinnakkaiset ajot samalle branchille
 - [ ] Dogfood: kirjaston oma CI käyttää tätä workflow'ta
- [ ] Statusviestit raportoivat jokaisen stepin tilan
+- [ ] Jokainen job postaa oman commit-statuksen `report-status.sh`:lla (eri `context`-avain per job)
+- [ ] Branch protection: `ci/unit-test` ja `ci/code-coverage` näkyvät erillisinä checkeinä

 ---

 ## Toiminto

-Feature-branchin CI-workflow. Kutsuu `report-status.sh` ja `push-reports.sh` (Ticket 0001 ja 0003).
+Feature-branchin CI-workflow. Kutsuu vain `report-status.sh`:ta (Ticket 0001). Ei raporttien julkaisua MinIO:hon.
+
+**Huom:** Raporttien julkaisu (`push-reports.sh`) lisätään erillisessä tiketissä (0013).

 ## Trigger

@@ -71,20 +77,18 @@ Feature-branchin CI-workflow. Kutsuu `report-status.sh` ja `push-reports.sh` (Ti
 | `maven-image` | Ei | Maven-kontti (esim. `maven:3.9-eclipse-temurin-21`) |
 | `node-image` | Ei | Node-kontti (npm-projektit) |

-## Steppit
+## Steppit (4 jobia, jokainen oma check)

 ```
-start → unit-test → code-coverage → publish-html → end
+start → unit-test → code-coverage → end
 ```

-| Steppi | Skripti | Status |
-|--------|---------|--------|
-| `start` | `report-status.sh pending "Building..."` | INPROGRESS |
-| `unit-test` | Projektin oma testiajo | — |
-| `code-coverage` | JaCoCo / vastaava | — |
-| `publish-html` | `push-reports.sh cucumber; push-reports.sh jacoco` | — |
-| `end` | `report-status.sh success/failure` | Lopullinen status |
-| `fail` (catch) | `report-status.sh failure` | FAILURE |
+| Job | `context` | Toiminto |
+|-----|-----------|----------|
+| `start` | `ci/start` | `report-status.sh pending "Build started"` |
+| `unit-test` | `ci/unit-test` | Projektin oma testiajo → `report-status.sh success/failure` |
+| `code-coverage` | `ci/code-coverage` | JaCoCo / vastaava → `report-status.sh success/failure` |
+| `end` | `ci/end` | `report-status.sh success/failure` (kokonaistulos) |

 ## Concurrency

@@ -97,10 +101,10 @@ concurrency:
 ## Verifiointi

 Simuloi paikallisesti (act-runner tai manuaalinen steppien ajo):
-1. `report-status.sh pending` → commitin status = pending
-2. Testit ajetaan
-3. `push-reports.sh` → raportit MinIO:ssa
-4. `report-status.sh success` → statusviesti + URL
+1. `report-status.sh pending` → commitin status = pending (`ci/start`)
+2. Testit ajetaan → `ci/unit-test` = success/failure
+3. Coverage ajetaan → `ci/code-coverage` = success/failure
+4. `report-status.sh success/failure` → `ci/end` = lopullinen status

 ## Viitteet

@@ -0,0 +1,102 @@
+# Ticket 0013: Raporttien julkaisu `ci-feature.yml`:ään
+
+**Vaihe:** 13 (riippuu 0003 ja 0005)
+**Status:** pending
+**Feature branch:** `feature/0013-ci-feature-report-publish`
+**TDD required:** Yes
+**Feature file required:** Yes
+
+**Required context:**
+- `docs/test-plan/tdd-guide.md`
+- `tests/features/0013-ci-feature-report-publish.feature`
+- Skills: `tdd`, `implementation`, `clean-code`
+
+**Pre-requisite (estotiketti):**
+- Tiketti 0003 (`push-reports.sh`) — valmis
+- Tiketti 0005 (`report-service/generate-index.sh`) — valmis
+- Tiketti 0006 (`ci-feature.yml`) — valmis (perusstepit ilman raportteja)
+
+---
+
+## TDD — Red-Green-Refactor
+
+### Red
+Ennen muutoksia, kirjoita validointitestit (`tests/workflows.bats`):
+- `publish-html`-job lisätty `ci-feature.yml`:ään
+- `push-reports.sh`-kutsut oikeilla parametreilla
+- `end`-jobin URL-parametri sisältää raportti-URL:n
+
+```bash
+bats tests/workflows.bats
+# FAIL: publish-html -steppiä ei ole
+```
+
+### Green
+Lisää `publish-html`-job `ci-feature.yml`:ään.
+
+```bash
+bats tests/workflows.bats
+# PASS
+```
+
+## DoD
+- [ ] Cucumber: `@ticket-0013 and @mock` → kaikki skenaariot GREEN
+- [ ] `tests/workflows.bats` — YAML-validointi läpi
+- [ ] `publish-html`-job puskaa raportit MinIO:hon
+- [ ] `end`-jobin statusviesti sisältää raportti-URL:n
+- [ ] `ci-flow-values.yaml`-skeema tukee raporttityyppejä (`cucumber`, `jacoco`, `site`)
+
+---
+
+## Toiminto
+
+Lisää `ci-feature.yml`:ään `publish-html`-job, joka kutsuu `push-reports.sh`:ta (Ticket 0003) jokaiselle raporttityypille. Raporttityypit konfiguroidaan `ci-flow-values.yaml`:ssa.
+
+## Muutokset `ci-feature.yml`:ään
+
+Uusi steppijärjestys:
+
+```
+start → unit-test → code-coverage → publish-html → end
+```
+
+| Job | `context` | Toiminto |
+|-----|-----------|----------|
+| `start` | `ci/start` | `report-status.sh pending` |
+| `unit-test` | `ci/unit-test` | Projektin oma testiajo |
+| `code-coverage` | `ci/code-coverage` | JaCoCo / vastaava |
+| `publish-html` | `ci/publish-html` | `push-reports.sh` jokaiselle raporttityypille |
+| `end` | `ci/end` | `report-status.sh success/failure` + raportti-URL |
+
+## `ci-flow-values.yaml`-laajennus
+
+```yaml
+build:
+  ecosystem: maven
+  java-version: "21"
+
+test:
+  unit: "mvn test"
+  coverage: "mvn jacoco:report"
+
+reports:
+  - type: cucumber
+    source: target/cucumber-report
+  - type: jacoco
+    source: target/site/jacoco
+  - type: site
+    source: target/site
+```
+
+## Verifiointi
+
+1. `push-reports.sh cucumber target/cucumber-report` → onnistuu
+2. `push-reports.sh jacoco target/site/jacoco` → onnistuu
+3. `end`-jobin statusviestin URL osoittaa raporttiin
+
+## Viitteet
+
+- `docs/tickets/0003-push-reports-sh.md` — `push-reports.sh`
+- `docs/tickets/0005-report-service-index-generation.md` — `generate-index.sh`
+- `docs/tickets/0006-pipeline-as-conf.md` — Pipeline as conf (perusstepit)
+- `docs/report-hosting.md` — Raporttien URL-rakenne
@@ -1,6 +1,8 @@
 # Reusable workflowt

-> Kuuluu arkkitehtuuriin: [architecture.md](architecture.md). Tämä dokumentti määrittelee jokaisen reusable workflow'n elinkaaren ja rajapinnan.
+> ⚠️ **POC-vaihe.** Tämä dokumentti kuvaa suunniteltuja workflow'ta
+> (ci-feature, ci-master, deploy, test). POCissa on toteutettu vain
+> `ci-engine.yml`. Uudelleenkirjoitus odottaa.

 ---

@@ -29,8 +31,7 @@ start → unit-test → code-coverage → html-reports → end
 | Parametri | Pakollinen | Kuvaus |
 |-----------|------------|--------|
 | `config-file` | Kyllä | Polku `ci-flow-values.yaml`:aan (yleensä `ci-flow-values.yaml`) |
-| `maven-image` | Ei | Maven-kontin image (esim. `maven:3.9-eclipse-temurin-21`) |
-| `node-image` | Ei | Node-kontin image (jos npm-projekti) |
+| `containers` | Ei | Kuvaus konteista: avain = nimi, arvo = image. Steppi valitsee missä kontissa ajaa. |

 ### Steppi-kaavio

@@ -42,9 +43,8 @@ flowchart TD
    aja testit, generoi raportit"]
    UNIT --> COV["code-coverage
    jacoco / vastaava"]
-    COV --> HTML["publish-html
-    pushaa raportit MinIO:hon
-    generoi index.html"]
+    COV --> HTML["publish-reports
+    vie raportit git-pagesiin"]
    HTML --> END(["end
    POST lopullinen status"])

@@ -84,8 +84,7 @@ unit-test → quality-gate → build-jar → build-docker → push-docker → ta
 | Parametri | Pakollinen | Kuvaus |
 |-----------|------------|--------|
 | `config-file` | Kyllä | Polku `ci-flow-values.yaml`:aan |
-| `maven-image` | Ei | Maven-kontti |
-| `docker-image` | Ei | Docker-in-Docker -image (esim. `docker:26-dind`) |
+| `containers` | Ei | Kuvaus konteista: avain = nimi, arvo = image |

 ### isContainerBuilt-check

@@ -125,9 +124,8 @@ flowchart TD
    
    CHECK -- "kyllä" --> CTF["continueToTestFlow"]
    TAG --> CTF
-    CTF --> HTML["publish-html
-    pushaa Maven Site
-    MinIO:hon"]
+    CTF --> HTML["publish-reports
+    vie raportit git-pagesiin"]
    HTML --> END(["end
    lopullinen status"])