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
@@ -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

 ---