refaktorointia

.gitea/workflows/check-version.yml

@@ -15,7 +15,6 @@ on:
         value: ${{ jobs.check.outputs.version }}
 
 env:
-  GITEA_API_URL: ${{ fromJson(inputs.env_json).GITEA_API_URL }}
   GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
 
 jobs:
@@ -26,15 +25,6 @@ jobs:
       version: ${{ steps.set-outputs.outputs.version }}
     steps:
       - uses: actions/checkout@v4
-      - uses: actions/checkout@v4
-        with:
-          repository: niko/gitea-ci-library
-          path: .ci
-
-      - name: Set Gitea status to PENDING
-        run: |
-          echo "===== gitea-ci-library - Check existing artifact | begin ====="
-          bash .ci/scripts/report-status.sh pending "Checking version..." ci-check
 
       - name: Check existing artifact and calculate version
         run: |
@@ -72,17 +62,3 @@ jobs:
           source /tmp/build-ctx/build.env
           echo "artifact_exists=$ARTIFACT_EXISTS" >> "$GITHUB_OUTPUT"
           echo "version=$NEXT_VERSION" >> "$GITHUB_OUTPUT"
-
-      - name: Set Gitea status to SUCCESS
-        if: success()
-        run: |
-          source /tmp/build-ctx/build.env
-          if [ "${ARTIFACT_EXISTS}" = "true" ]; then
-            bash .ci/scripts/report-status.sh success "Skip build: version $NEXT_VERSION exists" ci-check
-          else
-            bash .ci/scripts/report-status.sh success "Build version $NEXT_VERSION required" ci-check
-          fi
-
-      - name: Set Gitea status to FAILURE
-        if: failure()
-        run: bash .ci/scripts/report-status.sh failure "Check version FAILED" ci-check

.gitea/workflows/ci-validate.yml

@@ -26,17 +26,5 @@ jobs:
           repository: niko/gitea-ci-library
           path: .ci
 
-      - name: Pending
-        run: bash .ci/scripts/report-status.sh pending "Validating CI config..." ci-validate
-
       - name: Validate CI config
-        id: validate
         run: bash .ci/scripts/ci-validate.sh
-
-      - name: Report status SUCCESS
-        if: success()
-        run: bash .ci/scripts/report-status.sh success "CI config valid" ci-validate
-
-      - name: Report status FAILURE
-        if: failure()
-        run: bash .ci/scripts/report-status.sh failure "CI validation FAILED" ci-validate

.gitea/workflows/docker-build-push.yml

@@ -85,15 +85,6 @@ jobs:
     needs: [build-push]
     steps:
       - uses: actions/checkout@v4
-      - uses: actions/checkout@v4
-        with:
-          repository: niko/gitea-ci-library
-          path: .ci
-
-      - name: Set Gitea status to PENDING
-        run: |
-          echo "===== gitea-ci-library - Create Tag | begin ====="
-          bash .ci/scripts/report-status.sh pending "Creating tag..." ci-docker-tag
 
       - name: Create git tag
         env:
@@ -113,11 +104,3 @@ jobs:
           else
             exit 1
           fi
-
-      - name: Report status SUCCESS
-        if: success()
-        run: bash .ci/scripts/report-status.sh success "Tag ${VERSION} OK" ci-docker-tag
-
-      - name: Report status FAILURE
-        if: failure()
-        run: bash .ci/scripts/report-status.sh failure "Tag ${VERSION} FAILED" ci-docker-tag

.gitea/workflows/example-feature.yml

@@ -7,10 +7,10 @@ on:
 
 jobs:
   load-config:
-    name: Load gitea-env.conf to pipeline env
+    name: Load example-gitea-env.conf to pipeline env
     uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@main
     with:
-      config_path: .gitea/workflows/gitea-env.conf
+      config_path: .gitea/workflows/example-gitea-env.conf
 
   validate:
     name: Validate CI config
@@ -45,3 +45,4 @@ jobs:
     uses: niko/gitea-ci-library/.gitea/workflows/example-report-summary.yml@feature/docker-kuntoon
     with:
       env_json: ${{ needs.load-config.outputs.env_json }}
+      suites: bats cucumber

.gitea/workflows/example-main.yml

@@ -7,10 +7,10 @@ on:
 
 jobs:
   load-config:
-    name: Load gitea-env.conf to pipeline env
+    name: Load example-gitea-env.conf to pipeline env
     uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@main
     with:
-      config_path: .gitea/workflows/gitea-env.conf
+      config_path: .gitea/workflows/example-gitea-env.conf
 
   check-version:
     name: Check existing artifact
@@ -56,6 +56,7 @@ jobs:
     uses: niko/gitea-ci-library/.gitea/workflows/example-report-summary.yml@feature/docker-kuntoon
     with:
       env_json: ${{ needs.load-config.outputs.env_json }}
+      suites: bats cucumber
 
   build-push:
     name: Build & Push Docker

.gitea/workflows/example-report-summary.yml

@@ -5,6 +5,10 @@ on:
       env_json:
         required: true
         type: string
+      suites:
+        required: true
+        type: string
+        description: Space-separated suite names published to git-pages
 
 env:
   GIT_PAGES_URL: ${{ fromJson(inputs.env_json).GIT_PAGES_URL }}
@@ -24,6 +28,7 @@ jobs:
             echo ""
             echo "| Suite | Report |"
             echo "|-------|--------|"
-            echo "| Bats (unit) | [View report](${BASE}/bats/) |"
+            for suite in ${{ inputs.suites }}; do
-            echo "| Cucumber | [View report](${BASE}/cucumber/) |"
+              echo "| ${suite} | [View report](${BASE}/${suite}/) |"
+            done
           } >> "${GITHUB_STEP_SUMMARY}"

docs/adr/0007-status-reporting-pattern.md

@@ -2,40 +2,32 @@
 
 ## Päätös
 
-Jokaisen jobin on raportoitava lopputulos commit-statukseen. Käytössä on kaksi
+Gitea Actionsin natiivi job-status on ensisijainen. Commit-status API:a
-patternia, jotka eroavat toisistaan vain raporttien julkaisun osalta.
+(`report-status.sh`) käytetään **vain** kun työvaihe tuottaa ulkoisen linkin
+(testiraportti, Docker registry), jota natiivistaatus ei tue.
 
-### Tool-jobit (validate, build, push, tag, check-version, report-index)
+### Tool-jobit (validate, check-version, tag-commit)
 
-```
+Ei API-kutsuja. Luotetaan Gitean omaan job-statukseen.
-PENDING → työvaihe → SUCCESS (if: success) / FAILURE (if: failure)
-```
 
 ```yaml
-- name: Set Gitea status to PENDING
+- uses: actions/checkout@v4
-  run: bash .ci/scripts/report-status.sh pending "Validating..." ci-validate
 
 - name: Do work
-  run: some-command
+  run: do-something
-
-- name: Report status SUCCESS
-  if: success()
-  run: bash .ci/scripts/report-status.sh success "OK" ci-validate
-
-- name: Report status FAILURE
-  if: failure()
-  run: bash .ci/scripts/report-status.sh failure "FAILED" ci-validate
 ```
 
 ### Test-jobit (bats, cucumber)
 
+API:a käytetään raporttilinkin upottamiseksi commit-näkymään.
+
 ```
 PENDING → testit → publish (always) → status (always, exit-koodin mukaan)
 ```
 
 ```yaml
 - name: Set Gitea status to PENDING
-  run: bash .ci/scripts/report-status.sh pending "Running tests..." ci-tests
+  run: bash .ci/scripts/report-status.sh pending "Running tests..." ci-bats
 
 - name: Run tests
   shell: bash
@@ -47,51 +39,50 @@ PENDING → testit → publish (always) → status (always, exit-koodin mukaan)
 
 - name: Publish reports
   if: always()
-  run: bash .ci/scripts/publish-git-pages.sh suite
+  run: bash .ci/scripts/publish-git-pages.sh bats
 
 - name: Report status
   if: always()
   shell: bash
   run: |
     if [ "${EXIT}" = "0" ]; then
-      bash .ci/scripts/report-status.sh success "Tests OK" ci-tests suite
+      bash .ci/scripts/report-status.sh success "Bats tests OK" ci-bats bats
     else
-      bash .ci/scripts/report-status.sh failure "Tests FAILED" ci-tests suite
+      bash .ci/scripts/report-status.sh failure "Bats tests FAILED" ci-bats bats
     fi
 ```
 
+### Build & push -jobit (docker-build-push)
+
+API:a käytetään Docker registry -linkin upottamiseksi.
+
+```
+PENDING → build → push → SUCCESS (registry-linkillä) / FAILURE
+```
+
 ## Periaatteet
 
-1. Ennen varsinaista työvaihetta asetetaan status `pending` — näin commit-näkymässä
+1. Gitea Actionsin natiivi job-status on ensisijainen. API:a käytetään vain
-   näkyy heti, että jobi on käynnissä.
+   custom-linkin tarpeeseen (ADR 0004).
-2. `run`-komennon on nostettava virhe ylös — oli kyse tool-callista (docker,
+2. `run`-komennon on nostettava virhe ylös — oli kyse tool-callista tai
-   curl, bash) tai testien ajamisessa tapahtuneesta testivirheestä.
+   testivirheestä (ADR 0008).
-3. Tool-jobit käyttävät `if: success()` ja `if: failure()` — jobin sisäinen
+3. Test-jobit käyttävät `if: always()` publish- ja status-stepeissä — raportti
-   tila ratkaisee suoraan kumman steppi ajetaan.
-4. Test-jobit käyttävät `if: always()` publish- ja status-stepeissä — raportti
    julkaistaan ja status asetetaan aina, riippumatta testin lopputuloksesta.
-5. Testiraportit julkaistaan myös virhetilanteessa, mikäli ne ovat syntyneet.
+4. Testiraportit julkaistaan myös virhetilanteessa, mikäli ne ovat syntyneet.
-6. Status-linkki ohjaa testiraporttiin (suite-parametri) jos raportti on
+5. Commit-statuksen duplikaatio natiivijob-statuksen kanssa hyväksytään
-   olemassa, muuten Gitea Actions -logiin.
+   testijobeille — se on ainoa mekanismi upottaa raporttilinkki commit-näkymään.
+6. Tool-jobit eivät käytä API:a lainkaan — ne luottavat Gitean natiiviin
+   job-statukseen.
 
 ## Tausta
 
-Aiemmassa `quality-gate.yml`:ssä käytettiin `if: always()` + sisäistä if/elseä
+Aiemmin commit-status API:a käytettiin jokaisessa työvaiheessa, myös niissä
-myös tool-jobeissa (`steps.<id>.outcome`-tarkistus). Tämä on tarpeetonta
+joilla ei ollut raporttia linkitettäväksi (validate, check-version, tag-commit).
-kompleksisuutta työvaiheille, jotka eivät tuota erillistä raporttia — jobin oma
+Tämä tuotti duplikaatiota: Gitea näytti sekä natiivin `CI Main / Validate CI config
-tila (`success`/`failure`) on riittävä ehto.
+Successful` että API-statuksen `ci-validate CI config valid`. Kehittäjälle
+molemmat kertoivat saman asian.
 
-Test-jobit tarvitsevat `if: always()`:n koska raportti on julkaistava ja status
+Käytännön pakko kuitenkin pakottaa API:n käyttöön testijobeissa: ilman
-asetettava silloinkin kun testit epäonnistuvat. Status-viestin URL osoittaa
+raporttilinkkiä kukaan ei löydä testituloksia. Gitean natiivi job-status
-suoraan raporttiin git-pagesissa, mikä on kriittinen feature virheenjäljityksessä.
+linkittää aina jobin lokiin — ei ulkoiseen raporttiin. Tämä on paras
-
+saatavilla oleva kompromissi.
-Pipeline-status jokaiselle vaiheelle on välttämätön, koska Gitean branch
-protection -säännöt käyttävät commit-statusta merge-estona. Jokainen
-`ci-*`-konteksti voi toimia vaadittuna statuksena PR:n sulkemiselle — jos
-yksikin status on `failure`, merge estyy. Tämä korvaa Jenkinsin
-`disableConcurrentBuilds()`- ja build gate -logiikan Gitea-natiivilla
-mekanismilla.
-
-Status-näkymä toimii myös master-haaran terveyden monitorina: Git UI:sta
-näkee suoraan yhdellä silmäyksellä onko uusin commit vihreä. Ei tarvitse
-avata CI-järjestelmän dashboardia.