Fix/uusi consumer kontti taktiikka (#23 )

Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #23
Feature/yksinkertaistetaan raportointi logiikkaa (#22 )
2026-06-18 13:54:38 +03:00 · 2026-06-18 12:55:02 +03:00 · 2026-06-17 17:02:44 +03:00 · 2026-06-17 14:19:05 +03:00 · 2026-06-17 07:41:01 +03:00 · 2026-06-17 07:40:24 +03:00
36 changed files with 1699 additions and 733 deletions
@@ -1,37 +1,29 @@
 #!/usr/bin/env bash
 set -euo pipefail
-WORKSPACE_VOLUME="${1:-}"
+REPORT_DIR="${1:-}"
-REPORT_DIR="${2:-}"
+COVERAGE_DIR="${REPORT_DIR}/coverage"
 [ -n "$WORKSPACE_VOLUME" ] || { echo "ERROR: workspace volume name required" >&2; exit 1; }
 [ -n "$REPORT_DIR" ] || { echo "ERROR: report directory required" >&2; exit 1; }
-HAS_COVERAGE=false
+if [ -d coverage ]; then
-COVERAGE_SRC=""
+  mkdir -p "$COVERAGE_DIR"
-if docker run --rm -v "$WORKSPACE_VOLUME":/data alpine sh -c '[ -d /data/coverage ] && ls -A /data/coverage | grep -q .' 2>/dev/null; then
+  cp -a coverage/. "$COVERAGE_DIR/"
  COVERAGE_SRC="/data/coverage"
 fi
-if [ -n "$COVERAGE_SRC" ]; then
+if [ -d "$COVERAGE_DIR" ] && [ ! -f "$COVERAGE_DIR/index.html" ]; then
-  mkdir -p "$REPORT_DIR/coverage"
+  SHA8="${GITHUB_SHA:0:8}"
-  docker run --rm -v "$WORKSPACE_VOLUME":/data alpine tar c -C "$COVERAGE_SRC" . | tar x -C "$REPORT_DIR/coverage"
+  {
-  HAS_COVERAGE=true
+    echo '<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">'
    echo "<title>Coverage report ${SHA8}</title>"
    echo '<style>body{font-family:sans-serif;margin:2em}h1{color:#1e293b}ul{list-style:none;padding:0}li{margin:.5em 0}a{color:#2563eb}</style>'
    echo "</head><body><h1>Coverage report <code>${SHA8}</code></h1><ul>"
    while IFS= read -r -d '' f; do
      base=$(basename "$f")
      name="${base%.*}"
      name="${name//-/ }"
      echo "<li><a href=\"${base}\">${name^}</a></li>"
    done < <(find "$COVERAGE_DIR" -maxdepth 1 -type f \( -name '*.html' -o -name '*.txt' \) ! -name index.html -print0 2>/dev/null || true)
    echo '</ul></body></html>'
  } > "$COVERAGE_DIR/index.html"
 fi
 cat > "$REPORT_DIR/index.html" << EOF
 <!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
 <title>Bats report ${GITHUB_SHA:0:8}</title>
 <style>body{font-family:sans-serif;margin:2em;max-width:960px}
 h1{color:#1e293b}a{color:#2563eb;text-decoration:none}a:hover{text-decoration:underline}
 </style></head><body>
 <h1>Bats report <code>${GITHUB_SHA:0:8}</code></h1>
 <ul>
 <li><a href="test-report.html">Test results</a></li>
 EOF
 if [ "$HAS_COVERAGE" = true ]; then
  echo '<li><a href="coverage/index.html">Coverage report</a></li>' >> "$REPORT_DIR/index.html"
 fi
 echo '</ul></body></html>' >> "$REPORT_DIR/index.html"
@@ -16,6 +16,8 @@ on:
 env:
  GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
  GIT_TAG_PREFIX: ${{ fromJson(inputs.env_json).GIT_TAG_PREFIX || '' }}
  VERSION_FILE: ${{ fromJson(inputs.env_json).VERSION_FILE || '' }}
 jobs:
  check:
@@ -28,14 +30,32 @@ jobs:
      - name: Check existing artifact and calculate version
        run: |
          if [ -n "${VERSION_FILE}" ]; then
            if echo "${VERSION_FILE}" | grep -q '\.json$'; then
              RAW_VERSION=$(jq -r '.version' "${VERSION_FILE}")
            else
              RAW_VERSION=$(cat "${VERSION_FILE}" | tr -d '[:space:]')
            fi
          elif [ -f VERSION ]; then
            RAW_VERSION=$(cat VERSION | tr -d '[:space:]')
          elif [ -f package.json ]; then
            RAW_VERSION=$(jq -r '.version' package.json)
          elif [ -f pom.xml ]; then
            RAW_VERSION=$(grep -oP '<version>\K[^<]+' pom.xml | head -1)
          else
            echo "ERROR: No VERSION file, package.json, or pom.xml found" >&2
            exit 1
          fi
          BASE_VERSION=$(echo "$RAW_VERSION" | cut -d'.' -f1-2)
          echo "gitea-ci-library - Tunnistettu Major.Minor versio: $BASE_VERSION"
          TAGS_JSON=$(curl -s -f -H "Authorization: token $GITEA_TOKEN" \
            "${{ gitea.server_url }}/api/v1/repos/${{ gitea.repository }}/tags")
-          TAG=$(echo "$TAGS_JSON" | jq -r 'if type == "array" then .[] | select(.commit.sha == "${{ github.sha }}") | .name else empty end' | head -1)
+          TAG=$(echo "$TAGS_JSON" | jq -r --arg prefix "${GIT_TAG_PREFIX}" '
            if type == "array" then
              .[] | select(.commit.sha == "${{ github.sha }}" and (.name | startswith($prefix))) | .name
            else empty end' | head -1)
          mkdir -p /tmp/build-ctx
@@ -46,7 +66,7 @@ jobs:
          else
            echo "ARTIFACT_EXISTS=false" > /tmp/build-ctx/build.env
-            HIGHEST_PATCH=$(echo "$TAGS_JSON" | jq -r --arg bv "$BASE_VERSION." '
+            HIGHEST_PATCH=$(echo "$TAGS_JSON" | jq -r --arg prefix "${GIT_TAG_PREFIX}" --arg bv "${GIT_TAG_PREFIX}${BASE_VERSION}." '
              if type == "array" then .[] | .name | select(startswith($bv)) | sub($bv; "") | tonumber else empty end' | sort -rn | head -1)
            if [ -z "$HIGHEST_PATCH" ]; then NEXT_PATCH=0; else NEXT_PATCH=$((HIGHEST_PATCH + 1)); fi
@@ -0,0 +1,57 @@
 name: CI Container Build & Push
 on:
  workflow_call:
    inputs:
      env_json:
        required: true
        type: string
      dockerfile_path:
        required: true
        type: string
      image_name:
        required: true
        type: string
      tag:
        required: false
        type: string
        default: 'latest'
    secrets:
      DOCKER_USERNAME:
        required: false
      DOCKER_PASSWORD:
        required: true
 jobs:
  build-push:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and push container
        env:
          DOCKER_REGISTRY: ${{ fromJson(inputs.env_json).DOCKER_REGISTRY || '' }}
          DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME || github.actor }}
          DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
        run: |
          REGISTRY="${DOCKER_REGISTRY:?DOCKER_REGISTRY not set in conf}"
          DOCKERFILE="${{ inputs.dockerfile_path }}"
          IMAGE_NAME="${{ inputs.image_name }}"
          TAG="${{ inputs.tag }}"
          NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
          docker build \
            --label "git.commit=${{ github.sha }}" \
            --label "git.commitBy=${{ github.actor }}" \
            --label "build.date=${NOW}" \
            -f "${DOCKERFILE}" \
            -t "${IMAGE_NAME}:${TAG}" .
          REGISTRY_HOST="${REGISTRY%%/*}"
          FULL_IMAGE="${REGISTRY}/${IMAGE_NAME}:${TAG}"
          echo "Pushing ${FULL_IMAGE} ..."
          docker tag "${IMAGE_NAME}:${TAG}" "$FULL_IMAGE"
          echo "$DOCKER_PASSWORD" | docker login "$REGISTRY_HOST" -u "$DOCKER_USERNAME" --password-stdin
          docker push "$FULL_IMAGE"
          docker logout "$REGISTRY_HOST"
@@ -22,6 +22,8 @@ env:
  DOCKER_REGISTRY: ${{ fromJson(inputs.env_json).DOCKER_REGISTRY || '' }}
  DOCKER_IMAGE_NAME: ${{ fromJson(inputs.env_json).DOCKER_IMAGE_NAME || '' }}
  DOCKER_UI_URL: ${{ fromJson(inputs.env_json).DOCKER_UI_URL || '' }}
  DOCKERFILE: ${{ fromJson(inputs.env_json).DOCKERFILE || 'Dockerfile' }}
  GIT_TAG_PREFIX: ${{ fromJson(inputs.env_json).GIT_TAG_PREFIX || '' }}
  VERSION: ${{ inputs.version }}
 concurrency:
@@ -48,7 +50,9 @@ jobs:
            --label "git.commit=${{ github.sha }}" \
            --label "git.commitBy=${{ github.actor }}" \
            --label "build.date=${NOW}" \
-            -t "${DOCKER_IMAGE_NAME}:${VERSION}" .
+            -f "${DOCKERFILE}" \
            -t "${DOCKER_IMAGE_NAME}:${VERSION}" \
            -t "${DOCKER_IMAGE_NAME}:latest" .
          REGISTRY="${DOCKER_REGISTRY:?DOCKER_REGISTRY not set in env.conf}"
          IMAGE="${DOCKER_IMAGE_NAME:?DOCKER_IMAGE_NAME not set in env.conf}"
@@ -60,6 +64,12 @@ jobs:
          docker tag "${DOCKER_IMAGE_NAME}:${VERSION}" "$FULL_IMAGE"
          echo "$DOCKER_PASSWORD" | docker login "$REGISTRY_HOST" -u "$DOCKER_USERNAME" --password-stdin
          docker push "$FULL_IMAGE"
          FULL_LATEST="${REGISTRY}/${IMAGE}:latest"
          echo "Pushing ${FULL_LATEST} ..."
          docker tag "${DOCKER_IMAGE_NAME}:latest" "$FULL_LATEST"
          docker push "$FULL_LATEST"
          docker logout "$REGISTRY_HOST"
      - name: Report status SUCCESS
@@ -67,7 +77,7 @@ jobs:
        run: |
          CONTAINER_URL=""
          if [ -n "${DOCKER_UI_URL:-}" ] && [ -n "${VERSION:-}" ]; then
-            CONTAINER_URL="${DOCKER_UI_URL}/${VERSION}"
+            CONTAINER_URL="${DOCKER_UI_URL}/${DOCKER_IMAGE_NAME}/${VERSION}"
          fi
          bash .ci/scripts/report-status.sh success "Docker build & push ${VERSION} OK" ci-docker-build-push "" "$CONTAINER_URL"
@@ -92,7 +102,7 @@ jobs:
            "$SERVER_URL/api/v1/repos/${{ github.repository }}/tags" \
            -H "Authorization: token $GITEA_TOKEN" \
            -H "Content-Type: application/json" \
-            -d "{\"tag_name\": \"${VERSION}\", \"message\": \"Build #$RUN_NUMBER\", \"target\": \"$SHA\"}")
+            -d "{\"tag_name\": \"${GIT_TAG_PREFIX}${VERSION}\", \"message\": \"Build #$RUN_NUMBER\", \"target\": \"$SHA\"}")
          if [ "$HTTP_CODE" = "201" ] || [ "$HTTP_CODE" = "409" ]; then
            exit 0
@@ -6,8 +6,9 @@ on:
        required: true
        type: string
      bats-image:
-        required: true
+        required: false
        type: string
        default: gitea.app.keskikuja.site/niko/ci-bats:latest
    secrets:
      GITEA_TOKEN:
        required: true
@@ -23,6 +24,8 @@ env:
 jobs:
  bats:
    runs-on: ubuntu-latest
    container:
      image: ${{ inputs.bats-image }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
@@ -31,34 +34,18 @@ jobs:
          path: .ci
      - name: Run bats tests
        id: bats-tests
        shell: bash
        run: |
-          docker volume create bats-workspace
+          mkdir -p reports/bats
-          tar c . | docker run --rm -i -v bats-workspace:/data alpine tar x -C /data
+          bashcov -- bats tests/ > reports/bats/results.txt 2>&1
          mkdir -p "reports/${GITHUB_SHA:0:8}/bats"
          set +e
          docker run --rm \
            -v bats-workspace:/data \
            --entrypoint bash ${{ inputs.bats-image }} \
            -c 'apk add -q lsof python3 jq curl ruby && cd /data && gem install bashcov -v 3.3.0 2>&1 | tail -1 && bashcov -- bats tests/' \
            > "reports/${GITHUB_SHA:0:8}/bats/results.txt" 2>&1
          BATS_EXIT=$?
          bash .ci/.gitea/scripts/bats-coverage.sh bats-workspace "reports/${GITHUB_SHA:0:8}/bats"
          docker volume rm bats-workspace > /dev/null 2>&1
          bash .ci/.gitea/scripts/bats-report.sh "reports/${GITHUB_SHA:0:8}/bats"
          echo "BATS_EXIT=${BATS_EXIT}" >> "${GITHUB_ENV}"
          exit ${BATS_EXIT}
-      - name: Publish bats reports
+      - name: Post-process coverage
        if: always()
-        run: bash .ci/scripts/publish-git-pages.sh bats
+        run: bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
-      - name: Report status
+      - name: Post-process test report
        if: always()
-        run: |
+        run: bash .ci/.gitea/scripts/bats-report.sh reports/bats
-          if [ "${BATS_EXIT}" = "0" ]; then
+
-            bash .ci/scripts/report-status.sh success "Link to Bats reports" unit-tests bats
+      - name: Report
-          else
+        if: always()
-            bash .ci/scripts/report-status.sh failure "Link to Bats reports" unit-tests bats
+        run: bash .ci/scripts/ci-report.sh "Bats test report" unit-tests bats
          fi
@@ -0,0 +1,21 @@
 name: Build CI Bats Container (Manual)
 on: workflow_dispatch
 jobs:
  load-config:
    name: Load config
    uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@main
    secrets: inherit
    with:
      config_path: .gitea/workflows/example-gitea-env.conf
  build-push:
    name: Build & Push
    needs: [load-config]
    uses: niko/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@main
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      dockerfile_path: Dockerfile.ci-bats
      image_name: ci-bats
      tag: latest
@@ -0,0 +1,41 @@
 name: CI Container Build Cucumber
 on:
  workflow_dispatch:
    inputs:
      config_path:
        required: true
        type: string
        default: '.gitea/workflows/example-gitea-env.conf'
        description: 'Polku .gitea-env.conf-tiedostoon'
      dockerfile_path:
        required: true
        type: string
        default: 'Dockerfile.ci-cucumber'
        description: 'Polku Dockerfileen'
      image_name:
        required: true
        type: string
        default: 'ci-cucumber'
        description: 'Kontin nimi ilman registry-polkua'
      tag:
        required: true
        type: string
        default: 'latest'
        description: 'Image-tägi'
 jobs:
  load-config:
    uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@main
    secrets: inherit
    with:
      config_path: ${{ inputs.config_path }}
  build-push:
    needs: [load-config]
    uses: niko/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@main
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      dockerfile_path: ${{ inputs.dockerfile_path }}
      image_name: ${{ inputs.image_name }}
      tag: ${{ inputs.tag }}
@@ -6,8 +6,9 @@ on:
        required: true
        type: string
      cucumber-node-image:
-        required: true
+        required: false
        type: string
        default: gitea.app.keskikuja.site/niko/ci-cucumber:latest
    secrets:
      GITEA_TOKEN:
        required: true
@@ -33,38 +34,14 @@ jobs:
          path: .ci
      - name: Run cucumber tests
        id: cucumber-tests
        shell: bash
        run: |
-          apt-get update -qq && apt-get install -y -qq --no-install-recommends lsof jq
+          mkdir -p reports/cucumber
          npm install @cucumber/cucumber > /dev/null 2>&1
          mkdir -p "reports/${GITHUB_SHA:0:8}/cucumber"
          set +e
          npx cucumber-js \
-            --format json:"reports/${GITHUB_SHA:0:8}/cucumber/report.json" \
+            --format json:reports/cucumber/results.json \
-            --format html:"reports/${GITHUB_SHA:0:8}/cucumber/index.html" 2>&1
+            --format html:reports/cucumber/test-report.html 2>&1
          CUCUMBER_EXIT=$?
          echo "CUCUMBER_EXIT=${CUCUMBER_EXIT}" >> "${GITHUB_ENV}"
          exit ${CUCUMBER_EXIT}
-      - name: Publish cucumber reports
+      - name: Report
        if: always()
        run: bash .ci/scripts/publish-git-pages.sh cucumber
      - name: Report status
        if: always()
        shell: bash
-        run: |
+        run: bash .ci/scripts/ci-report.sh "Cucumber test report" acc-tests cucumber
          if [ "${CUCUMBER_EXIT}" = "0" ]; then
            if [ -f "reports/${GITHUB_SHA:0:8}/cucumber/index.html" ]; then
              bash .ci/scripts/report-status.sh success "Link to Cucumber reports" acc-tests cucumber
            else
              bash .ci/scripts/report-status.sh success "Link to Cucumber reports" acc-tests
            fi
          else
            if [ -f "reports/${GITHUB_SHA:0:8}/cucumber/index.html" ]; then
              bash .ci/scripts/report-status.sh failure "Link to Cucumber reports" acc-tests cucumber
            else
              bash .ci/scripts/report-status.sh failure "Link to Cucumber reports" acc-tests
            fi
          fi
@@ -20,7 +20,6 @@ jobs:
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      bats-image: bats/bats:latest
  cucumber:
    name: Cucumber tests
@@ -29,13 +28,12 @@ jobs:
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      cucumber-node-image: node:22
  report-summary:
    name: Report Summary
    needs: [load-config, bats, cucumber]
    if: always()
-    uses: niko/gitea-ci-library/.gitea/workflows/example-report-summary.yml@main
+    uses: niko/gitea-ci-library/.gitea/workflows/report-summary.yml@main
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      suites: bats cucumber
@@ -2,4 +2,5 @@ GITEA_API_URL=https://gitea.app.keskikuja.site
 GIT_PAGES_URL=https://ci-reports.helm-dev.keskikuja.site
 DOCKER_REGISTRY=gitea.app.keskikuja.site/niko
 DOCKER_IMAGE_NAME=gitea-ci-library-test-image
-DOCKER_UI_URL=https://gitea.app.keskikuja.site/niko/-/packages/container/gitea-ci-library-test-image
+DOCKER_UI_URL=https://gitea.app.keskikuja.site/niko/-/packages/container
 #DOCKERFILE=Dockerfile.platform
@@ -29,7 +29,6 @@ jobs:
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      bats-image: bats/bats:latest
  cucumber:
    name: Cucumber tests
@@ -39,7 +38,6 @@ jobs:
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      cucumber-node-image: node:22
  build-push:
    name: Build & Push Docker
@@ -53,9 +51,16 @@ jobs:
  report-summary:
    name: Report Summary
-    needs: [load-config, bats, cucumber]
+    needs: [load-config, build-push]
    if: always()
-    uses: niko/gitea-ci-library/.gitea/workflows/example-report-summary.yml@main
+    uses: niko/gitea-ci-library/.gitea/workflows/report-summary.yml@main
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      suites: bats cucumber
  tag-maintenance:
    name: Move provider version tag
    needs: [build-push]
    if: success()
    uses: niko/gitea-ci-library/.gitea/workflows/tag-maintenance.yml@main
    secrets: inherit
@@ -0,0 +1,11 @@
 name: Hello World (Manual)
 on:
  workflow_dispatch:
  push:
    # branches: [ main ] # Tai [ feature/ci-container ]
    branches: [feature/ci-container]
 jobs:
  greet:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello"
@@ -0,0 +1,38 @@
 name: Tag Maintenance
 on:
  workflow_call:
    secrets:
      GITEA_TOKEN:
        required: true
 jobs:
  move-tag:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Read current provider version
        id: version
        run: echo "TAG=$(cat CURRENT_PROVIDER_VERSION | tr -d '[:space:]')" >> "$GITHUB_OUTPUT"
      - name: Move tag to commit
        run: |
          TAG="${{ steps.version.outputs.TAG }}"
          SHA="${{ github.sha }}"
          curl -sf -X DELETE \
            -H "Authorization: token ${{ secrets.GITEA_TOKEN }}" \
            "${{ gitea.server_url }}/api/v1/repos/${{ github.repository }}/tags/${TAG}" || true
          HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -X POST \
            -H "Authorization: token ${{ secrets.GITEA_TOKEN }}" \
            -H "Content-Type: application/json" \
            "${{ gitea.server_url }}/api/v1/repos/${{ github.repository }}/tags" \
            -d "{\"tag_name\": \"${TAG}\", \"message\": \"Release ${TAG}\", \"target\": \"${SHA}\"}")
          if [ "$HTTP_CODE" = "201" ]; then
            echo "${TAG} tag moved to ${SHA}"
          else
            echo "ERROR: failed to move ${TAG} tag (HTTP $HTTP_CODE)" >&2
            exit 1
          fi
@@ -7,3 +7,4 @@ tmp/
 coverage/
 .DS_Store
 reports/
 .vscode/
@@ -0,0 +1 @@
 v1
@@ -0,0 +1,3 @@
 FROM bats/bats:1.11.0
 RUN apk add --no-cache lsof python3 jq curl ruby nodejs && \
    gem install bashcov -v 3.3.0
@@ -0,0 +1,7 @@
 FROM node:22
 RUN apt-get update -qq && \
    apt-get install -y -qq --no-install-recommends lsof jq && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* && \
    npm install -g @cucumber/cucumber
 ENV NODE_PATH=/usr/local/lib/node_modules
@@ -2,6 +2,13 @@
 Reusable workflow -kirjasto Gitea Actionsille. Lisätietoja: [docs/](docs/)
 **Consumer-käyttöönotto:** [skills/consumer-pipelines/SKILL.md](skills/consumer-pipelines/SKILL.md) — pipeline-standardit ja säännöt consumer-projekteille
 **Single repo & monorepo:** Kirjasto toimii molemmissa. Monorepo-tuki
 polkusuodatuksella, komponenttikohtaisilla versioilla ja git-tägien
 etuliitteillä — jokainen komponentti julkaistaan itsenäisesti omassa
 tahdissaan. Katso [skills/consumer-pipelines/SKILL.md](skills/consumer-pipelines/SKILL.md).
 ## Provider-binding — miten consumer löytää providerin
 Consumer kutsuu provideria `uses:`-viittauksella. Ei discoveryä — polku kovakoodataan consumerin
@@ -116,8 +123,8 @@ Hae token Giteasta:
 ```bash
 GITEA_URL="https://<gitea-server-url>"
 GITEA_ACTIONS_TOKEN="<registration-token>"
 GITEA_ACTIONS_NAMESPACE="gitea-actions"
 GITEA_ACTIONS_TOKEN="<registration-token>"
 ```
 ### 3. Tee secret vain init install yhteydessä
@@ -151,6 +158,7 @@ helm upgrade --install act-runner gitea/actions \
  --set giteaRootURL="$GITEA_URL" \
  --set existingSecret=act-runner-token \
  --set existingSecretKey=token \
  --set statefulset.replicas=3 \
  --set statefulset.runner.tag=1.0.8 \
  --set statefulset.dind.tag=29.5.2-dind \
  --set-string 'statefulset.runner.config=log:
@@ -0,0 +1,53 @@
 # 9. Breaking changes kielletty
 ## Päätös
 Providerin `v1`-tagin osoittamaa rajapintaa ei koskaan rikota.
 Consumerin `uses:`-kutsut säilyvät yhteensopivina — uusi versiotagi
 (`v2`, `v3`) luodaan VAIN jos taaksepäin yhteensopimaton muutos on
 pakottava. Käytännössä: `v1` on pysyvä, ja sitä ylläpidetään
 eteenpäin.
 ## Rajapinnan määritelmä
 Providerin rajapinta = `config-provider.yml` ja `check-version.yml`
 workflow_call-inputit ja -outputit:
 - Inputtien nimet, tyypit ja required-arvot eivät muutu
 - Outputtien nimet eivät katoa
 - Secret-nimet eivät muutu
 - Workflow-tiedoston nimi ja polku eivät muutu
 Sisäinen toteutus (scriptit, checkout-logiikka, build-vaiheet) voi
 muuttua vapaasti — consumer ei ole niistä riippuvainen.
 ## Versiotagin siirto
 Tagi `v1` siirretään automaattisesti uusimpaan onnistuneeseen
 main-commitin CI-ajoon (`tag-maintenance.yml`). Tagin nimi luetaan
 tiedostosta `CURRENT_PROVIDER_VERSION`.
 Jos breaking change joskus tulee pakottavaksi:
 1. Päivitä `CURRENT_PROVIDER_VERSION` → `v2`
 2. Luo uusi `v2`-tagi manuaalisesti (osoittaa uuteen rajapintaan)
 3. `tag-maintenance.yml` alkaa ylläpitää `v2`:ta eteenpäin
 4. `v1`-tagia **ei poisteta** — se jää osoittamaan viimeistä
   v1-yhteensopivaa committia. `v1`:tä käyttävät consumerit
   jatkavat toimintaansa ilman muutoksia.
 5. Uudet consumerit ottavat käyttöön `@v2`:n.
 Aktiivisesti ylläpidetään vain yhtä tagia (`CURRENT_PROVIDER_VERSION`).
 Vanhat tagit säilyvät paikoillaan taaksepäin yhteensopivuutta varten.
 ## Perustelu
 Yhden aktiivisen tagin ylläpito on yksinkertaisempaa kuin usean
 rinnakkaisen version aktiivinen hallinta. Homelab-ympäristössä
 consumerit ovat saman ylläpitäjän hallinnassa — eri tiimien
 rinnakkaisia aktiiviversioita ei tarvita.
 Breaking changen sattuessa vanha tagi säilyy — vanhat consumerit
 eivät hajoa. Uusi tagi otetaan käyttöön uusissa consumereissa.
 Breaking changen kielto pakottaa suunnittelemaan rajapinnat
 huolellisesti etukäteen.
@@ -0,0 +1,43 @@
 # 10. Pipeline-reititin — ei komentoja
 ## Päätös
 CI-pipelinetiedostot (`ci-main.yml`, `ci-feature.yml`) ovat puhtaita
 **reitittimiä**. Ne eivät saa sisältää `run:`-komentoja, inline-skriptejä
 tai varsinaista build-/test-logiikkaa. Niiden ainoa sallittu sisältö on:
 - `uses:` — viittaus reusable workflow'hun
 - `needs:` — riippuvuus toisen jobin valmistumiseen
 - `if:` — ehdollinen suoritus
 - `secrets: inherit` — salaisuuksien välitys
 ## Mikä ei kuulu reitittimeen
 - `run:`-komennot
 - Inline-skriptit (shell, Python, tms.)
 - `actions/checkout` (paitsi providerin sisäinen infrastruktuuri)
 - Build-työkalut, testikomennot, Docker-komennot
 - Raporttien generointi
 ## Missä logiikka on
 | Kerros | Tiedosto | Sisältö |
 |---|---|---|
 | Reititin | `ci-main.yml`, `ci-feature.yml` | Vain `uses:`-kutsut |
 | Workflow_call | `ci-unit-tests.yml`, `ci-acc-tests.yml`, … | Varsinainen testi-/build-logiikka |
 | Provider | `config-provider.yml`, `check-version.yml`, … | Jaettu infrastruktuuri |
 | Skriptit | `scripts/` | Apufunktiot (status, publish, validointi) |
 ## Perustelu
 Reitittimen ja toteutuksen erottelu:
 - Reititin kertoo **mitä** ajetaan ja **missä järjestyksessä** — luettavissa
  yhdellä silmäyksellä ilman teknistä taustaa
 - Toteutus (workflow_call) kertoo **miten** — tekninen henkilö voi keskittyä
  yhteen tiedostoon kerrallaan
 - Providerin reusable workflow't eivät koskaan sisällä inline-logiikkaa —
  skriptit ovat omissa tiedostoissaan
 Tämä on sama periaate kuin web-sovelluksissa: reititin ei sisällä
 business-logiikkaa, vain HTTP-verbit ja polut.
@@ -26,21 +26,26 @@ kuuluu `git-pages/docs/`-alle, ei juuren `docs/`-kansioon.
 | `.gitea/workflows/config-provider.yml` | Provider: lataa + validoi config-tiedoston, tuottaa `env_json` |
 | `.gitea/workflows/check-version.yml` | Provider: tarkistaa onko commitille jo artifact, laskee version |
 | `.gitea/workflows/docker-build-push.yml` | Provider: buildaa + puskea Docker-imagen, tagittaa commitin |
 | `.gitea/workflows/ci-container-build-push.yml` | Provider: buildaa + puskea CI-työkalukontin |
 | `.gitea/workflows/example-*` | **Consumer-esimerkki**: tämän repon oma CI (dogfood) |
 | `scripts/` | Provider-skriptit: `report-status.sh`, `publish-git-pages.sh`, `ci-validate.sh` |
 | `.gitea/scripts/` | **Consumer-skriptit**: `bats-coverage.sh`, `bats-report.sh` |
 | `docs/` | Arkkitehtuuri, ADRt (0004–0008) |
 | `skills/consumer-pipelines/` | Consumer-pipeline-standardit — AI:n pakottavat säännöt consumer-CI:lle |
 | `skills/ci-container-build/` | CI-kontin build-workflow'n template — `ci-container-build-push.yml` |
 | `docs/adr/` | Architecture Decision Records |
 | `git-pages/` | Raporttien hostaus (Helm-chartti) |
 | `tests/` | Bats-testit skripteille |
-### Provider workflowt (3 kpl)
+### Provider workflowt (5 kpl)
 | Workflow | Input | Output | Kuvaus |
 |---|---|---|---|
 | `config-provider.yml` | `config_path` | `env_json`, `config_path` | Validoi ja jäsentää `.conf` → JSON. Sama kutsu hoitaa validoinnin. |
 | `check-version.yml` | `env_json` | `artifact_exists`, `version` | Tarkistaa git-tagit ja `package.json`:n, laskee seuraavan version. Vain main-haarassa. |
 | `docker-build-push.yml` | `env_json`, `version` | — | Buildaa Docker-imagen, puskea rekisteriin, tagittaa commitin. |
 | `ci-container-build-push.yml` | `env_json`, `dockerfile_path`, `image_name`, `tag` | — | Buildaa CI-työkalukontin, puskea rekisteriin. Ei versiointia eikä git-tägäystä. |
 | `report-summary.yml` | `env_json`, `suites` | — | Generoi `GITHUB_STEP_SUMMARY`-taulukon raporttilinkeillä (Gitea 1.27+) |
 ### Example-tiedostot (consumer-referenssi)
@@ -50,7 +55,6 @@ kuuluu `git-pages/docs/`-alle, ei juuren `docs/`-kansioon.
 | `example-main.yml` | push [main] | load-config → check-version → bats + cucumber → report-summary → docker-build-push |
 | `example-bats-tests.yml` | workflow_call | Unit-testit Batsilla, raportit git-pagesiin, status linkillä |
 | `example-cucumber-tests.yml` | workflow_call | Hyväksymätestit Cucumberilla, raportit git-pagesiin, status linkillä |
 | `example-report-summary.yml` | workflow_call | `GITHUB_STEP_SUMMARY`-taulukko raporttilinkeillä (Gitea 1.27+) |
 | `example-gitea-env.conf` | — | KEY=VALUE config tälle repolle |
 ## Key Technical Decisions
@@ -33,7 +33,7 @@ Tarkemmin: ADR 0005.
 | `example-main.yml` | Consumer | Main-haaran CI: load-config → check-version → bats + cucumber → summary → docker |
 | `example-bats-tests.yml` | Consumer | Unit-testit Batsilla |
 | `example-cucumber-tests.yml` | Consumer | Hyväksymätestit Cucumberilla |
-| `example-report-summary.yml` | Consumer | `GITHUB_STEP_SUMMARY`-taulukko (Gitea 1.27+) |
+| `report-summary.yml` | Provider | `GITHUB_STEP_SUMMARY`-taulukko raporttilinkeillä (Gitea 1.27+) |
 | `publish-git-pages.sh` | Provider-skripti | PATCH tar git-pagesiin |
 | `report-status.sh` | Provider-skripti | POSTaa commit-status (vain custom-linkkiin) |
 | `ci-validate.sh` | Provider-skripti | Validoi `.conf`-tiedoston ja tarkistaa secretit |
@@ -1,269 +1,124 @@
-# Konfiguraatiomalli — `ci-flow-values.yaml`
+# Konfiguraatiomalli — `gitea-env.conf`
-> ⚠️ **POC-vaihe.** Tämä dokumentti on peritty Jenkins-versiosta ja sisältää
+> Consumer määrittelee ympäristökohtaiset arvot KEY=VALUE-muotoisessa
-> Docker-spesifistä legacyä (isContainerBuild, Docker-labelit). POC osoitti,
+> `.conf`-tiedostossa. Providerin `config-provider.yml` validoi tiedoston
-> että provider on agnostinen consumerin build-ekosysteemille.
+> ja muuntaa sen JSON:ksi (`env_json`), jota kaikki downstream-workflowt
->
+> käyttävät.
 > 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.
 ---
-## Miksi redesign
+## Tiedoston sijainti ja nimi
-Jenkins-version `ci-flow-values.yaml` oli rakennettu Jenkinsin ympäristömuuttuja- ja credential-mallin ympärille. Gitea Actionsissa konfiguraatio luetaan suoraan YAML:sta workflow'n sisällä — ei tarvita env-muuttujien kautta kierrättämistä. Lisäksi:
+Consumerin repossa: `.gitea/workflows/gitea-env.conf` (nimi vapaasti
 valittavissa — `config-provider.yml`:n `config_path`-input määrittää polun).
- `creditentials`-viittaukset korvautuvat Gitea org secrets/variables -mekanismilla
+Esimerkki (tämän repon dogfood):
- `test-flow`-syntaksi yksinkertaistuu (ei enää JSON-serialisointia env-muuttujiin)
+```
- Docker/NPM-rekisterit MVP:ssä vain Gitea Packages — factory/adapter-pattern valmiina laajennukselle
+.gitea/workflows/example-gitea-env.conf
- `sonarqube`-konfiguraatio pysyy samankaltaisena
+```
 ---
 ## Skeema
 ```
 KEY=VALUE
 ```
 Yksi `KEY=VALUE` per rivi. Kommentit `#`-merkillä. Tyhjät rivit ohitetaan.
 ### Pakolliset avaimet
 | Avain | Kuvaus | Esimerkki |
 |---|---|---|
 | `GITEA_API_URL` | Gitea-instanssin URL | `https://gitea.example.com` |
 | `GIT_PAGES_URL` | Raporttihostauksen URL | `https://reports.example.com` |
 ### Docker-spesifit avaimet (vain jos käytetään `docker-build-push.yml`)
 | Avain | Pakollinen | Kuvaus |
 |---|---|---|
 | `DOCKER_REGISTRY` | Kyllä | Rekisterin host/path, esim. `gitea.example.com/org` |
 | `DOCKER_IMAGE_NAME` | Kyllä | Kontin nimi ilman registry-prefixiä |
 | `DOCKER_UI_URL` | Ei | Linkki kontin UI-näkymään registryssä |
 | `DOCKERFILE` | Ei | Dockerfile-nimi, oletus `Dockerfile` |
 ### Esimerkki
 ```ini
 GITEA_API_URL=https://gitea.example.com
 GIT_PAGES_URL=https://reports.example.com
 DOCKER_REGISTRY=gitea.example.com/myorg
 DOCKER_IMAGE_NAME=temperature-store
 DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container/temperature-store
 #DOCKERFILE=Dockerfile.platform
 ```
 ---
 ## Salaisuudet
 Salaisuudet eivät ole `.conf`-tiedostossa. Ne määritellään Gitean
 organization/repository secrets -mekanismissa ja välitetään workflowlle
 `secrets: inherit` -direktiivillä.
 | Secret | Pakollinen | Käyttäjä |
 |---|---|---|
 | `GITEA_TOKEN` | Kyllä | `report-status.sh`, `check-version.yml`, `docker-build-push.yml` |
 | `GIT_PAGES_PUBLISH_TOKEN` | Kyllä | `publish-git-pages.sh`, `config-provider.yml` (validointi) |
 | `DOCKER_USERNAME` | Ei | `docker-build-push.yml` (oletus: `github.actor`, ei pakollinen kaikissa registryissä) |
 | `DOCKER_PASSWORD` | Kyllä | `docker-build-push.yml` |
 ---
 ## `config-provider.yml` — lataus ja validointi
 Provider-workflow joka lukee `.conf`-tiedoston, validoi sen ja palauttaa
 JSON-muotoisen `env_json`:n.
 **Input:** `config_path` (polku `.conf`-tiedostoon)
 **Output:** `env_json` (JSON-string), `config_path` (sama polku takaisin)
 **Validointi:**
 - `.conf`-tiedosto on olemassa
 - Jokaisella `KEY=VALUE`-rivillä on arvo (ei tyhjää)
 - URL-tyyppiset avaimet alkavat `http://` tai `https://`
 - Pakolliset secretit (`GITEA_TOKEN`, `GIT_PAGES_PUBLISH_TOKEN`) on asetettu
 Kutsu:
 ```yaml
-# ci-flow-values.yaml — projektin juuressa
+load-config:
-#
+    uses: org/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
 # Pakolliset osiot: docker (jos master-branch buildaa kontin), test-flow (jos ketjutetaan)
 # Vapaaehtoiset: sonarqube, deployment
 docker:
  registry: gitea                    # gitea | artifactory | nexus (MVP: vain gitea)
  imageName: temperature-store       # kontin nimi, pakollinen
 sonarqube:
  url: https://sonar.example.com
  projectKey: temperature-store
 deployment:
  jobName: deploy                    # deploy-workflown nimi (vakio)
  projectFolder: microservices       # polku Helm-repossa
  fileName: values-{.environment}.yaml
  property: container.version
 test-flow:
  - deploy: development              # 1. deploy development-ympäristöön
    wait: true                       # odota deployn valmistumista
  - test:
      name: "integration fast"
      environment: integration
      repo: tests/integration        # testi-repo (owner/repo)
      workflow: test.yml             # workflow-tiedosto testi-repossa
      ref: main                      # branch
      tags: "@temperature and not @slow"
  - deploy: staging
    wait: true
  - test:
      name: e2e
      environment: staging
      repo: tests/e2e
      workflow: test.yml
      ref: main
      tags: "@e2e and not @slow"
 ```
 ### Kenttäkuvaukset
 #### `docker`
 | Kenttä | Pakollinen | Kuvaus |
 |--------|------------|--------|
 | `registry` | Ei (oletus `gitea`) | Rekisterityyppi. MVP: `gitea`. Factory/adapter-pattern avaa `artifactory`, `nexus` myöhemmin |
 | `imageName` | Kyllä | Kontin nimi. Lopullinen tagi: `{gitea_host}/{owner}/{imageName}:{version}.{run_number}` |
 #### `sonarqube`
 | Kenttä | Pakollinen | Kuvaus |
 |--------|------------|--------|
 | `url` | Kyllä | SonarQube-palvelimen URL |
 | `projectKey` | Kyllä | SonarQube-projektin avain |
 SonarQube-token tulee Gitea org secretsista (`SONAR_TOKEN`). Ei `creditentials`-viittausta.
 #### `deployment`
 | Kenttä | Pakollinen | Kuvaus |
 |--------|------------|--------|
 | `jobName` | Ei (oletus `deploy`) | Deploy-workflown tiedostonimi ilman `.yml`-päätettä |
 | `projectFolder` | Kyllä | Polku mikropalvelun kansioon Helm-repossa |
 | `fileName` | Kyllä | YAML-tiedoston nimi. `{.environment}` korvataan ympäristön nimellä |
 | `property` | Kyllä | Päivitettävä avain (piste-eroteltu polku, esim. `container.version`) |
 Deploy-token (kirjoitusoikeus Helm-repoon) tulee Gitea org secretsista (`DEPLOY_TOKEN`).
 #### `test-flow`
 Array testi-steppejä. Jokainen steppi on joko `deploy` tai `test`.
 **`deploy`-steppi:**
 | Kenttä | Pakollinen | Kuvaus |
 |--------|------------|--------|
 | `deploy` | Kyllä | Ympäristön nimi (esim. `development`, `staging`) |
 | `wait` | Ei (oletus `true`) | Odotetaanko deployn valmistumista ennen seuraavaa steppiä |
 **`test`-steppi:**
 | Kenttä | Pakollinen | Kuvaus |
 |--------|------------|--------|
 | `name` | Kyllä | Testivaiheen nimi (näkyy statusviestissä) |
 | `environment` | Kyllä | Ympäristö jota vasten testataan |
 | `repo` | Kyllä | Testi-repo muodossa `owner/repo` |
 | `workflow` | Kyllä | Workflow-tiedosto testi-repossa |
 | `ref` | Kyllä | Branch (esim. `main`) |
 | `tags` | Ei | Cucumber-tagit (esim. `"@smoke and not @slow"`) |
 | `versionApiUrl` | Ei | URL deployed-version tarkistukseen |
 | `versionCheckScript` | Ei | Polku version check -skriptiin (repossa tai kontissa) |
 ---
 ## `isArtifactBuild()`-mekanismi (POC: suunniteltu, ei toteutettu)
 > **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()`.
 **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
 TAG=$(git tag --points-at HEAD | grep -E '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$' | head -1)
 if [ -n "$TAG" ]; then
  echo "container_already_built=true" >> $GITHUB_ENV
  echo "container_version=$TAG" >> $GITHUB_ENV
 else
  echo "container_already_built=false" >> $GITHUB_ENV
 fi
 ```
 Workflow käyttää tätä ehtona:
 ```yaml
 jobs:
  build-container:
    if: env.container_already_built != 'true'
    steps:
      - run: docker build ...
  test-flow:
    if: always()
    needs: [build-container]
    steps:
      - run: dispatch-workflow.sh ...
 ```
 **Mitä `isContainerBuild() == true` tarkoittaa käytännössä:**
 - Kontti on jo buildattu ja pushattu rekisteriin
 - Commit on tagätty versiolla (esim. `1.2.3.42`)
 - Build-steppi skipataan → siirrytään suoraan test flow'hun
 - Sama versio deployataan ja testataan — ei uutta konttia
 **Miksi tämä on välttämätöntä:**
 - Estää versiokonfliktit: `1.2.3.42` ei voi olla kahdesti
 - 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
 ---
 ## Version check (Fibonacci-backoff)
 Ennen kuin testit ajetaan, pitää varmistua että haluttu konttiversio on oikeasti deployattu ympäristöön. Muuten testataan väärää versiota.
 **Malli:** Skripti, joka pollaa deployatun version API:a Fibonacci-backoffilla:
 ```bash
 #!/bin/bash
 # check-version.sh <version_api_url> <expected_version>
 # Palauttaa 0 jos versiot täsmäävät, 1 muuten.
 URL=$1
 EXPECTED=$2
 MAX_RETRIES=10
 # Fibonacci-sekvenssi: 1 2 3 5 8 13 21 34 55 89
 FIB=(1 2 3 5 8 13 21 34 55 89)
 for i in $(seq 1 $MAX_RETRIES); do
  ACTUAL=$(curl -s "$URL" | jq -r '.version // empty')
  if [ "$ACTUAL" = "$EXPECTED" ]; then
    echo "Version match: $ACTUAL"
    exit 0
  fi
  echo "Attempt $i/$MAX_RETRIES: $ACTUAL != $EXPECTED, waiting ${FIB[$i-1]}s..."
  sleep ${FIB[$i-1]}
 done
 echo "Version mismatch after $MAX_RETRIES attempts"
 exit 1
 ```
 **Miksi Fibonacci:** Uusi deploy käynnistyy nopeasti (ensimmäiset pollaukset tiheään). Jos kontin pullaus tai podin käynnistys kestää, pollausväli kasvaa — ei turhaan kuormiteta API:a. Maksimiaika: ~231 sekuntia (summa 1..89).
 Version check -skripti joko:
 - Asuu testi-repossa (projektin oma toteutus) → `versionCheckScript`-kenttä
 - Tai käyttää geneeristä API:a → `versionApiUrl`-kenttä, skripti on osa kirjastoa
 ---
 ## `doNotDowngrade`
 Jenkinsin deploy-jobissa oli `doNotDowngrade`-parametri, joka esti vanhemman version deployaamisen uudemman päälle. Gitea Actions -versiossa:
 - **Ei MVP:ssä.** Deploy tekee sen mitä käsketään. `doNotDowngrade` on lisäturva, joka voidaan lisätä deploy-workflow'hun myöhemmin.
 - **Mekanismi:** Ennen YAML:n muokkausta tarkistetaan nykyinen versio. Jos `new < current`, skipataan ja raportoidaan.
 - **Toteutus:** Yksi `if`-ehto deploy-workflow'n alussa, ei vaadi muutoksia muualle.
 ---
 ## UX-esimerkki: projektin `.gitea/workflows/ci.yml`
 Näin mikropalvelun kehittäjä käyttää kirjastoa:
 ```yaml
 # .gitea/workflows/ci.yml — projektin juuressa
 name: CI
 on:
  push:
    branches: ["**"]
  workflow_dispatch:
 jobs:
  feature:
    if: github.ref != 'refs/heads/master'
    uses: org/gitea-ci-library/.gitea/workflows/ci-feature.yml@v1
    secrets: inherit
    with:
-      config-file: ci-flow-values.yaml
+      config_path: .gitea/workflows/gitea-env.conf
      maven-image: maven:3.9-eclipse-temurin-21
  master:
    if: github.ref == 'refs/heads/master'
    uses: org/gitea-ci-library/.gitea/workflows/ci-master.yml@v1
    secrets: inherit
    with:
      config-file: ci-flow-values.yaml
      maven-image: maven:3.9-eclipse-temurin-21
      docker-image: docker:26-dind
 ```
-Kehittäjä määrittelee:
+---
 - Millä kontilla buildataan (`maven-image` — koska kirjasto ei tiedä projektin Java-versiota)
 - Mistä konfiguraatio luetaan (`config-file`)
 - Millä docker-versiolla kontit rakennetaan (`docker-image`)
-Kaikki Git-, raportointi-, SonarQube- ja deploy-konfiguraatio on `ci-flow-values.yaml`:ssa.
+## `check-version.yml` — version päättely
 Provider-workflow joka etsii version prioriteettijärjestyksessä:
 1. `VERSION`-tiedosto (plain text, esim. `0.2`)
 2. `package.json` → `.version`-kenttä (Node.js)
 3. `pom.xml` → `<version>`-elementti (Maven)
 Hakee git-tagit Gitea API:sta ja laskee seuraavan vapaan patch-version.
 **Output:** `artifact_exists` (true/false), `version` (string)
 **Idempotentti:** Jos commitilla on jo versiotagi, `artifact_exists=true` ja
 build-vaiheet skipataan. Samaa committia ei buildata kahdesti.
 ---
 ## `env_json`-propagointi
 ```
 gitea-env.conf  →  config-provider.yml  →  env_json (JSON-string)
                                              ↓
                        ci.yml with: env_json  →  kaikki downstream-workflowt
 ```
 Jokainen provider-workflow purkaa tarvitsemansa arvot `fromJson(inputs.env_json).KEY`:lla.
 Consumerin ei tarvitse tietää mitä avaimia kukin provider käyttää.
@@ -1,150 +1,195 @@
 # Design Rationale — Gitea Actions CI -kirjasto
-> Miksi kirjasto on rakennettu näin. Arvot, periaatteet ja reunaehdot, joiden varaan arkkitehtuuri nojaa.
+> Miksi kirjasto on rakennettu näin. Arvot, periaatteet ja reunaehdot, joiden
 > varaan arkkitehtuuri nojaa.
 >
-> Tämä dokumentti on **normatiivinen** — arkkitehtuurin on noudatettava näitä periaatteita. Jos ehdotettu muutos on ristiriidassa rationalen kanssa, rationalen on muututtava ensin.
+> Tämä dokumentti on **normatiivinen** — arkkitehtuurin on noudatettava näitä
 > periaatteita. Jos ehdotettu muutos on ristiriidassa rationalen kanssa,
 > rationalen on muututtava ensin.
 ---
 ## Miksi tämä projekti on olemassa
-Organisaatiolla on tuotannossa Jenkins-pohjainen CI-järjestelmä (`ci-jenkins-library`, 53 lähdetiedostoa, 21 Cucumber-featurea), joka on osoittautunut toimivaksi vuosien ajan. Se integroi Git-commitit, testiraportoinnin, Docker-buildit, deploymentin ja test flow'n yhtenäiseksi putkeksi, jossa jokainen vaihe raportoi tilansa suoraan Git-committiin.
+Mikropalveluarkkitehtuurissa jokainen palvelu tarvitsee CI-putken: testit,
 laatutarkistukset, buildin, kontituksen ja julkaisun. Ilman jaettua
 kirjastoa jokainen tiimi kopioi saman YAML-boilerplaten, tekee omat
 virheensä ja ylläpitää omaa versiotaan. Ajan myötä putket ajautuvat erilleen
 — toisessa on `shell: bash`, toisessa ei; toinen käyttää `set -o pipefail`,
 toinen kadottaa exit-koodin `tee`:hen.
-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.
+Tämä kirjasto on se mitä kopioidaan. Se tarjoaa valmiit, testatut,
-
+dokumentoidut rakennuspalikat joista jokainen tiimi kokoaa oman putkensa.
-Kirjasto ei ole Jenkins-migraatiotyökalu. Se on Gitea Actions -natiivi
+Palikat ovat Gitea Actionsin `uses:`-direktiivillä kutsuttavia reusable
-uudelleensuunnittelu, joka säilyttää Jenkins-version todistetut patternit
+workflow'ta — ei asennusta, ei runtime-riippuvuutta, ei versiopäivityksiä
-mutta hylkää ne osat, jotka olivat sidottuja Jenkinsin arkkitehtuuriin.
+projekteihin.
 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. Hyödynnä natiivia
+### 1. Palikka-arkkitehtuuri: pieniä, vaihdettavia, yhden vastuun workflow'ta
-Gitea Actionsin ja Gitean natiiveja ominaisuuksia käytetään aina kun ne
+Jokainen provider-workflow tekee yhden asian:
 riittävät. Uutta kilpailevaa toteutusta ei kirjoiteta, jos toimiva ratkaisu
 on jo olemassa.
-**Miksi:** Oma toteutus on aina ylläpidettävä, testattava ja
+| Workflow | Vastuu |
-dokumentoitava. Natiivi ominaisuus tulee ilmaiseksi, kehittyy alustan
+|---|---|
-mukana ja on käyttäjälle tuttu.
+| `config-provider.yml` | Lataa ja validoi konfiguraatio |
 | `check-version.yml` | Tarkistaa onko commit buildattu, laskee version |
 | `docker-build-push.yml` | Buildaa, puskea ja tagittaa kontin |
-**Esimerkkejä:**
+Mikään workflow ei kutsu toista provider-workflowta. Consumer
- Gitea Actions näyttää jobien statuksen automaattisesti — omaa
+— siis mikropalvelun oma pipeline-tiedosto — on ainoa paikka joka
-  commit-status API -kutsua ei tarvita jokaiselle vaiheelle
+tietää mitä palikoita tarvitaan ja missä järjestyksessä.
 - Gitea organization secrets/variables korvaa erillisen credential-hallinnan
 - Reusable workflow -mekanismi korvaa custom action -runtimen
-### 2. Git-commit on universaali statusnäkymä
+**Miksi:** Tämä on sama periaate kuin Unix-putkissa tai mikropalveluissa:
 pieniä, itsenäisiä komponentteja jotka tekevät yhden asian hyvin.
 Consumer voi vaihtaa yhden palikan toiseen — esimerkiksi Docker-buildin
 tilalle Maven-paketoinnin — ilman että muut palikat muuttuvat.
 Ratkaisu ei ole se että kaikki ajetaan, vaan se että jokainen tiimi
 valitsee mitä tarvitsee. Monoliittinen "kaikki yhdessä" -workflow
 pakottaisi jokaisen tiimin ajamaan tarpeettomia vaiheita.
-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.
+### 2. Gitea ensin — hyödynnä alustaa, älä taistele sitä vastaan
-**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.
+Gitea Actions tarjoaa kolme asiaa ilmaiseksi:
-**Mitä tarkoittaa käytännössä:** Gitea Actions näyttää jobien tilan
+1. **Jobien visuaalinen status** — jokainen jobi näkyy automaattisesti
-(checkmark/risti/spinner) commit-näkymässä automaattisesti. API:a
+   commit-näkymässä checkmarkilla, spinnerillä tai ristillä.
-(`/api/v1/repos/{owner}/{repo}/statuses/{sha}`) käytetään vain
+2. **Cross-job riippuvuudet** — `needs` hoitaa virheiden propagointin:
-custom-raporttilinkin välittämiseen. ADR 0004.
+   jos edeltävä jobi feilaa, riippuvat jobit skipataan.
 3. **Reusable workflow -jakelu** — `uses: org/repo/.gitea/workflows/file.yml@v1`
   on natiivisti versioitu, skopattu ja välimuistitettu.
-### 3. Reusable workflow — ei omaa runtimea
+Kirjasto käyttää näitä kaikkia. Ei omaa tilakonetta, ei custom
 action -runtimea, ei ulkoista orkestraattoria.
-Kirjasto jaetaan Gitea Actionsin reusable workflow -mekanismilla. Ei Docker-pohjaisia custom actioneita, ei erillistä ajonaikaista palvelinta.
+**Esimerkki:** Tool-jobit eivät kutsu commit-status API:a lainkaan.
 Gitean oma job-status riittää — `success`/`failure`/`running` näkyy
 automaattisesti. API:a käytetään vain kun tarvitaan **custom-linkki**
 (testiraporttiin tai Docker registryyn), jota natiivistaatus ei tarjoa.
 Tämä linjaus on dokumentoitu ADR 0004 ja 0007:ssä.
-**Miksi:** Reusable workflow on Gitea Actionsin natiivein tapa jakaa CI-logiikkaa. Se on kevein (ei ylimääräistä runtimea), läpinäkyvin (workflow-tiedosto on luettavissa sellaisenaan) ja teknisesti kestävin (Gitea huolehtii versioinnista ja jakelusta). Custom actionit otetaan käyttöön vain jos reusable workflow'n rajat tulevat vastaan.
+### 3. Status näkyy siellä missä työ tehdään — Git-commitissa
-**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ä.
+Kehittäjä työskentelee Gitissä. `git log`, `git blame`, PR-näkymä —
 nämä ovat päivittäiset työkalut. CI-statuksen kuuluu näkyä siellä,
 ei erillisessä dashboardissa.
-### 4. Konfiguraatio kuuluu repoon
+Gitea Actionsin natiivi job-status tekee tämän automaattisesti:
 jokainen commit näyttää välittömästi mitkä jobit on ajettu ja millä
 tuloksella. Testiraportteihin pääsee yhdellä klikkauksella commitin
 status-kuvakkeesta — koska `report-status.sh` asettaa `target_url`:n
 osoittamaan suoraan HTML-raporttiin git-pagesissa.
-Projektikohtainen konfiguraatio (`ci-flow-values.yaml`-tyyppinen tiedosto) asuu mikropalvelun omassa repossa. Reusable workflow lukee sen, ei toisinpäin.
+Tämä ei ole kosmeettinen yksityiskohta. Se on devops-käytännön
 ydin: palautesilmukka on lyhin mahdollinen. Commit → build → status
 näkyy samassa näkymässä jossa kehittäjä jo on.
-**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.
+### 4. Exit-koodi on ainoa totuus
-**Poikkeus:** Infra-tason asetukset (git-pages host, Gitea-instanssin URL)
+CI-putken jokaisen `run`-stepin onnistuminen määräytyy **vain ja
-ovat organisaatiotasolla Gitean organization secrets/variables
+ainoastaan** exit-koodin perusteella. Ei tiedoston olemassaolon, ei
-mekanismissa. Ne eivät ole repokohtaisia.
+stdout-tulosteen, ei arvauksen. `0` = ok, kaikki muu = ei ok.
-### 5. Deterministinen testigraafi, vaiheittainen suoritus
+Tämä kuulostaa itsestään selvältä, mutta YAML-pipelineissa se rikkoutuu
 helposti. Pipe (`|`) `tee`:hen syö exit-koodin. Tiedoston olemassaolon
 tarkistus (`[ -f results.xml ]`) ei kerro testien läpimenosta.
-Test flow on tunnettu ennen buildin alkua, ja testit ajetaan yksi kerrallaan. Jos steppi epäonnistuu, koko flow pysähtyy.
+**Käytännössä:** Jokainen `run`-steppi ottaa exit-koodin talteen
 `$?`-muuttujaan ennen kuin mikään muu komento ehtii muuttaa sitä,
 ja stepin viimeinen rivi on `exit ${EXIT}`. Pipeä ei käytetä
 työvaiheen viimeisenä komentona. Ks. ADR 0008.
-**Miksi:** Rinnakkainen suoritus aiheuttaa resurssikilpailua (erityisesti suorituskykytestit) ja piilottaa virheitä. Kun integraatiotesti epäonnistuu, e2e-testien ajaminen on turhaa — konttia ei viedä tuotantoon, eikä kukaan lue niitä tuloksia. Vaiheittainen suoritus on deterministinen, debuggattava ja säästää CI-minuutteja.
+### 5. Pienin mahdollinen pinta-ala
-**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.
+Jokainen ylimääräinen riippuvuus on ylimääräinen vikaantumispiste.
 Kirjaston ainoat riippuvuudet:
-### 6. Raporttien hallinta erillisellä palvelulla
+- Gitea Actions (alusta)
 - `bash`, `curl`, `jq` (ubuntu-latest runnerissa valmiina)
 - Docker (runnerissa valmiina)
 - git-pages (raporttien hostaus, erillinen palvelu)
-Raporttien selailtavuudesta ja elinkaaresta vastaa erillinen palvelu, joka
+Ei Pythonia, ei Node.js:ää ajonaikaisesti (testit omissa konteissaan).
-asennetaan git-pages Helm-chartilla. Raportit ovat julkisia URL:lla
+Ei tietokantaa. Ei ulkoista tilanhallintaa. Kirjasto on joukko
-(osoite tunnettava). URL linkitetään Git-committiin.
+YAML-tiedostoja ja shell-skriptejä — samat työkalut jotka jokainen
 devops-ihminen jo osaa.
-**Miksi:** Jenkins-versiossa linkki Cucumber-raporttiin oli kriittinen
+### 6. Konfiguraatio repoon, salaisuudet Giteaan
 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.
-### 7. Yksi CI-alusta, yksi integraatiopiste
+Projektikohtainen konfiguraatio (`.gitea/workflows/gitea-env.conf`)
 asuu mikropalvelun omassa repossa. Kehittäjä omistaa sen — hän tietää
 mikä on Docker-imagen nimi, mihin registryyn puskea, mikä on
 testiympäristön URL.
-Kirjasto tukee vain Giteaa. Ei GitLab-, BitBucket- tai GitHub-abstraktioita.
+Salaisuudet (tokenit, salasanat) elävät Gitean secrets-mekanismissa,
 eivät repon tiedostoissa. `secrets: inherit` välittää ne providerin
 workflow'hun ilman että consumerin tarvitsee tietää mitä salaisuuksia
 mikäkin provider tarvitsee.
-**Miksi:** Jenkins-versio tuki neljää Git-alustaa, koska Jenkins itsessään ei tarjonnut commit-statusraportointia. Gitea Actionsissa tilanne on päinvastainen — Gitea on sekä CI-että Git-alusta. Multi-platform-tuesta tulisi pelkkää ylimääräistä abstraktiota ilman konkreettista tarvetta.
+Poikkeus: infra-tason asetukset (`GIT_PAGES_URL`, `GITEA_API_URL`)
 ovat Gitean organization secrets/variables -mekanismissa. Ne eivät
 ole repokohtaisia.
-**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. Consumer omistaa orkestroinnin, provider tarjoaa palikat
-### 8. Cross-repo commit traceability
+Tämä on kirjaston tärkein arkkitehtuurinen päätös (ADR 0005).
-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.
+Provider (`gitea-ci-library`) ei tiedä mitä testejä ajetaan, missä
 järjestyksessä, tai millä branchilla. Se tarjoaa kolme reusable
 workflow'ta ja joukon skriptejä.
-**Miksi:** Kehittäjän ei pidä arvailla mikä versio on missäkin ympäristössä. Kun mikropalvelun commitista näkee koko ketjun — buildattu, deployattu stagingiin, integraatiotestit ajettu, e2e hyväksytty — virheenjäljitys on suora polku commitista ympäristöön. Vastaavasti Helm-repon commit kertoo mikä konttiversio sinne deployattiin ja kenen mikropalvelu-commitista se tuli. Tämä on Jenkins-version **eniten arvoa tuottanut ominaisuus**.
+Consumer (mikropalvelun `example-feature.yml` / `example-main.yml`)
 päättää:
 - Mitkä palikat kutsutaan
 - Missä järjestyksessä (`needs`)
 - Millä branch-ehdoilla (`if`)
 - Mitkä testikontit käytetään (input-parametrit)
-**Mekanismi:**
+Tämä on tarkoituksellinen vallanjako. Provider ei voi tietää jokaisen
 tiimin tarpeita — eikä sen pidäkään. Consumer ei voi muuttaa providerin
 sisäistä toteutusta — eikä sen pidäkään. Rajapinta on `workflow_call` ja
 se on molemmille osapuolille selvä.
-```mermaid
+### 8. Branch-kohtainen reititys, ei yhtä kaikille
 %%{init: {'theme': 'base'}}%%
 sequenceDiagram
    participant MR as Mikropalvelu-repo
    participant HR as Helm-repo
    participant TR as Testi-repo
    participant GA as Gitea API
-    Note over MR: commit abc123
+Eri brancheilla on eri tavoite:
    Note over MR: build kontti v1.2.3
-    MR->>GA: POST dispatch deploy-workflow
+- **Feature-haara:** Onko koodi laadukasta? → testit, validointi
-    GA->>HR: workflow käyntiin
+- **Main-haara:** Onko tästä versiosta jo artifakti? Jos ei →
-    Note over HR: commit def456
+  testit + build + push + tag. Jos on → ei tehdä mitään (tai
-    Note over HR: container.version = 1.2.3
+  jatketaan klusteritesteihin).
-    HR->>GA: POST status "deployed by abc123"
+Tämä logiikka elää consumerin pipeline-tiedostossa, ei providerissa.
-    GA->>MR: Status: deployed to staging
+Se on puhdasta `if`-ehtoa ja `needs`-ketjutusta — ei skriptausta,
-    Note right of MR: URL → def456
+ei monimutkaisia ehtoja providerin sisällä.
-    HR->>GA: POST status "from abc123"
+### 9. Raportit erillisellä palvelulla, linkit commitissa
    GA->>HR: Status: from abc123
    Note right of HR: URL → abc123
-    MR->>GA: POST dispatch integraatiotestit
+Gitea Actionsin artifact-järjestelmä on binääriarkisto — ZIP-lataus,
-    GA->>TR: workflow käyntiin
+ei HTML-selailtavuutta. Testiraportit (Cucumber HTML, Bats-coverage)
-    Note over TR: commit ghi789
+on voitava avata selaimessa yhdellä klikkauksella.
-    TR->>GA: POST status "integration OK"
+Ratkaisu: git-pages Helm-chartti, joka tarjoaa staattista
-    GA->>MR: Status: integration OK
+tiedostohostingia HTTP:llä. `publish-git-pages.sh` vie raportit
-    Note right of MR: URL → ghi789
+sinne; `report-status.sh` linkittää commit-statuksen suoraan
 raporttiin. Retention hoitaa git-pagesin sidecar automaattisesti.
-    TR->>GA: POST status "tested v1.2.3"
+Tulevaisuudessa `GITHUB_STEP_SUMMARY` (Gitea 1.27+) tarjoaa
-    GA->>HR: Status: tested v1.2.3
+vaihtoehtoisen kanavan: jobin Summary-välilehdelle renderöityvä
-    Note right of HR: URL → def456
+Markdown-taulukko kaikista raporttilinkeistä.
-    TR->>GA: POST status "tested abc123"
+### 10. Vain Gitea — ei monialustatukea ilman tarvetta
    GA->>MR: Status: tested abc123 (root)
    Note right of MR: URL → abc123
 ```
-**Mitä tarkoittaa käytännössä:** Jokaisella workflow'lla on kaksi build-referenssiä: `current` (oma commit) ja `root` (mikropalvelun commit, josta ketju alkoi). Molempiin POSTataan statusviestit. Root-build kulkee workflow-dispatchin `inputs`-parametrina koko ketjun läpi. Deployment-job raportoi sekä Helm-repon committiin ("from abc123") että mikropalvelun committiin ("deployed to staging → def456"). Testi-job raportoi omaan committiinsa, mikropalvelun committiin ja Helm-repon committiin.
+Yhden alustan tukeminen kunnolla on vaikeampaa kuin kolmen tukeminen
 huonosti. Gitea Actionsin `uses:`-mekanismi, `needs`-semantiikka,
 `secrets: inherit`, `gitea`-konteksti — nämä ovat alustakohtaisia
 ominaisuuksia joita abstraktiokerros vain haittaisi.
 Jos toinen alusta tulee ajankohtaiseksi, sille kirjoitetaan oma
 toteutus. Siihen asti yksi alusta riittää. Ennenaikainen yleistys
 on devopsissa yhtä haitallista kuin ohjelmistosuunnittelussa.
 ---
@@ -152,23 +197,31 @@ sequenceDiagram
 ### Mitä kirjasto EI tee
- **Ei ulkoista orkestraattoria.** Test flow -ketjutus perustuu Gitean REST APIin ja workflowhin itseensä. Ei erillistä palvelinta, joka hallinnoi tilaa.
+- **Ei ulkoista orkestraattoria.** Pipeline-ohjaus on Gitea Actionsin
- **Ei Jenkins-migraatiota.** Vanhaa Jenkinsfileä ei voi ajaa Gitea Actionsissa. Tämä on uusi kirjasto uudella konfiguraatioformaatilla.
+  `needs`-ketjuissa ja consumerin `if`-ehdoissa.
- **Ei reaaliaikaista build-seurantaa.** Commit-statusviestit ovat pollattavia, eivät push-pohjaisia. Gitean UI hoitaa reaaliaikaisuuden.
+- **Ei custom actioneita.** Reusable workflow on kevyempi, versioitu
- **Ei multi-repo-monorepo-konfiguraatiota.** Jokainen mikropalvelu omistaa oman `ci-flow-values.yaml`:nsa. Jaettua konfiguraatiota ei ole projektitasolla.
+  ja jaeltu Gitean oman mekanismin kautta.
 - **Ei asennusta projekteihin.** Consumer viittaa `uses:`-direktiivillä
  suoraan tämän repon workflow-tiedostoihin. Ei npm-pakettia, ei
  git-submodulea, ei kopioitavia tiedostoja.
 - **Ei runtime-riippuvuuksia.** Provider-skriptit käyttävät vain
  työkaluja jotka ovat Gitea Actionsin `ubuntu-latest` runnerissa
  valmiina: `bash`, `curl`, `jq`.
 - **Ei monorepo-konfiguraatiota.** Jokainen mikropalvelu omistaa
  oman pipeline-tiedostonsa ja konfiguraationsa.
 ---
 ## Mitä tietoisesti hylättiin
 ## Mitä tietoisesti hylättiin
 | Hylätty | Syy |
-|---------|-----|
+|---|---|
-| Multi-Git-platform-tuki (GitLab, BitBucket) | Vain Gitea on relevantti. Abstraktointi ilman tarvetta on turhaa kompleksisuutta |
+| Monoliittinen "kaikki yhdessä" -workflow | Pakottaa kaikille samat vaiheet. Palikka-arkkitehtuuri antaa jokaiselle tiimille vain mitä se tarvitsee |
-| Gitea Packages raporttien hostingiin | Ei tue HTML-selailtavuutta — vain binääriartefaktien lataus |
+| Oma orkestraattoripalvelin | Ylimääräinen ylläpidettävä. Gitean `needs` ja `if` riittävät |
-| Gitea Releases raporttien hostingiin | Saastuttaa release-historian. Satoja CI-raportteja oikeiden julkaisujen seassa |
+| Docker-pohjaiset custom actionit | Tuovat riippuvuuden Docker-rekisteriin. Reusable workflow on natiivimpi |
-| Gitea Pages + reports-branch | Race condition rinnakkaisten buildien pushissa samaan branchiin |
+| Commit-status API jokaiselle vaiheelle | Duplikointia — Gitea näyttää job-statuksen automaattisesti. API vain custom-linkeille |
-| Ulkoinen orkestraattoripalvelin | Ylimääräinen ylläpidettävä. Gitean oma API riittää |
+| `tee`-putki debug-näkyvyyteen | Syö exit-koodin. stdout ohjataan tiedostoon `>` ilman pipeä |
-| Docker-pohjaiset custom actionit | Tuovat riippuvuuden Docker-rekisteriin ja monimutkaistavat jakelua. Otetaan käyttöön vain pakon edessä |
+| Multi-Git-platform-tuki | Ennenaikaista optimointia ilman tarvetta |
-| `repository_dispatch` (webhook) test flow -ketjutukseen | Lisää konfiguraatiota vastaanottaviin repoihin. Suora REST API -kutsu on eksplisiittisempi ja debuggattavampi |
+| Gitea Packages raporttien hostingiin | Ei HTML-selailtavuutta — vain binäärilataus |
 | Gitea Pages + reports-branch | Race condition rinnakkaisten pushien kanssa |
 | `repository_dispatch` ketjutukseen | Lisää konfiguraatiota vastaanottaviin repoihin. Suora API-kutsu eksplisiittisempi |
@@ -1,8 +1,6 @@
 # Vaatimukset — Gitea Actions CI -kirjasto
 > Funktionaaliset vaatimukset käyttäjän näkökulmasta. Muoto: käyttötapaukset (use cases).
 >
 > Linkittyy: [design-rationale.md](design-rationale.md), [architecture.md](architecture.md), [report-hosting.md](report-hosting.md)
 ---
@@ -13,130 +11,89 @@
 **Main success:**
 - Kehittäjä avaa commitin Giteassa
- Näkee statusviestit: "Building...", "Unit tests OK", "Docker build OK", "Docker pushed"
+- Näkee job-statukset automaattisesti: spinner (käynnissä), checkmark (ok), risti (feilasi)
- Jokainen statusviesti on klikattavissa → vie buildin sivuun tai raporttiin
+- Testijobit näyttävät statuksen linkillä: "unit-tests Link to Bats reports", "acc-tests Link to Cucumber reports"
- Epäonnistunut steppi näkyy punaisella — kehittäjä klikkaa ja näkee mikä meni vikaan
+- Klikkaamalla testistatusta kehittäjä pääsee suoraan HTML-raporttiin git-pagesissa
 - Docker-build näyttää linkin konttirekisteriin
 **Poikkeukset:**
 - Statusviesti puuttuu (workflow kaatui ennen raportointia) → commitissa näkyy timeout/error
- Useampi workflow samalle commitille → statukset erottuvat `key`-arvolla
+- Useampi workflow samalle commitille → statukset erottuvat `context`-avaimella
 ---
 ## UC2: Kehittäjä lukee testiraportteja selaimessa
 **Actor:** Kehittäjä
-**Precondition:** Build on valmistunut, raportit pushattu Minioon
+**Precondition:** Build on valmistunut, raportit julkaistu git-pagesiin
 **Main success:**
- Kehittäjä klikkaa commitin statusviestin URL:ää ("Unit tests OK" → URL)
+- Kehittäjä klikkaa commitin status-kuvaketta (esim. "unit-tests")
- Selain avautuu, OIDC-kirjautuminen (Gitea-tunnuksilla)
+- Selain avautuu suoraan HTML-raporttiin git-pagesissa
- Cucumber-raportti renderöityy HTML:nä selaimessa
+- Bats-raportissa näkyy: testitulokset, code coverage
- Raportissa näkyy: mitkä testit menivät läpi, mitkä epäonnistuivat, stack tracet
+- Cucumber-raportissa näkyy: mitkä testit menivät läpi, mitkä epäonnistuivat, stack tracet
 - Yläreunassa linkki "← Back to build" → palaa buildin raportti-indeksiin
 **Poikkeukset:**
- Raporttia ei ole (testit skipattiin, workflow kaatui ennen pushausta) → 404
+- Raporttia ei ole (testit skipattiin, workflow kaatui ennen julkaisua) → 404
 - OIDC-sessio vanhentunut → uudelleenohjaus kirjautumiseen
 ---
-## UC3: Kehittäjä selaa projektin build-historiaa
+## UC3: Kehittäjä vertailee kahden buildin raportteja
 **Actor:** Kehittäjä
 **Precondition:** Projektilla on vähintään yksi build
 **Main success:**
 - Kehittäjä menee `{MINIO_BASE}/{repo_slug}/index.html`
 - Näkee listan kaikista buildeista aikajärjestyksessä (uusin ensin)
 - Jokaisella buildilla: commitin 8-merkkinen hash, päivämäärä, branch, status (✅/❌)
 - Klikkaa buildia → siirtyy `{commit_short}/index.html` — buildin raporttilistaukseen
 - Buildin sivulla: lista kaikista raporteista (Cucumber, JaCoCo, Maven Site) linkkeinä
 - "← Back to builds" → palaa projektin build-indeksiin
 **Poikkeukset:**
 - Projekti poistettu / siivottu retention policyn mukaan → 404
 - Indeksitiedosto puuttuu (ensimmäinen build kesken) → 404, generoituu seuraavalla pushauksella
 ---
 ## UC4: Kehittäjä jäljittää kontin koko ketjun commitista
 **Actor:** Kehittäjä
 **Precondition:** Mikropalvelun commitista on ajettu vähintään deployment
 **Main success:**
 - Kehittäjä avaa mikropalvelun commitin abc123
 - Näkee statusviestit: "Build OK", "Deployed to staging → def456", "Integration tests OK → ghi789"
 - Klikkaa "Deployed to staging → def456" → siirtyy Helm-repon committiin def456
 - Helm-repon commitissa näkyy: "from abc123", "tested v1.2.3", "tested abc123"
 - Klikkaa "tested abc123" → palaa mikropalvelun committiin
 - Koko ketju on navigoitavissa edestakaisin commit-statuslinkkien kautta
 **Poikkeukset:**
 - Välivaiheen commit siivottu → statusviesti jää, mutta linkki vie 404:ään
 - Deploytty versio ei vastaa odotettua → statusviestissä näkyy ristiriita
 ---
 ## UC5: Kehittäjä näkee deployatun version ympäristössä
 **Actor:** Kehittäjä
 **Precondition:** Deployment on suoritettu, Helm-repon commit tehty
 **Main success:**
 - Kehittäjä avaa Helm-repon commitin def456
 - Näkee: "container.version = 1.2.3", "Deployed by abc123"
 - Tietää heti mikä konttiversio on missäkin ympäristössä
 - Voi verrata mikropalvelun uusimpaan commitin — onko ympäristö ajan tasalla?
 **Poikkeukset:**
 - `doNotDowngrade` esti deploymentin → statusviesti "Skipped: newer version already deployed"
 ---
 ## UC6: Testi-insinööri näkee mitä konttia testattiin
 **Actor:** Testi-insinööri
 **Precondition:** Integraatio- tai e2e-testit on ajettu
 **Main success:**
 - Avaa testi-repon commitin ghi789
 - Näkee: "Tested v1.2.3" (mikä kontti), "Tested abc123" (mikä mikropalvelun commit)
 - Klikkaa testiraporttiin → näkee tulokset
 - Näkee myös mitkä tagit olivat käytössä (`@smoke and not @slow`)
 - Voi todentaa että testattiin oikeaa versiota
 **Poikkeukset:**
 - Version check epäonnistui (haluttu versio ei ollut ympäristössä) → status: "Version mismatch"
 - Testit keskeytyivät timeoutiin → status: timeout, osittaiset tulokset raportissa
 ---
 ## UC7: Kehittäjä vertailee kahden buildin raportteja
 **Actor:** Kehittäjä
 **Precondition:** Projektilla on vähintään kaksi buildia
 **Main success:**
- Kehittäjä avaa projektin build-indeksin `{MINIO_BASE}/{repo}/index.html`
+- Kehittäjä avaa kaksi buildia Gitean Actions-näkymässä eri välilehtiin
 - Näkee viimeisimmät buildit vierekkäin
 - Avaa kaksi buildia eri välilehtiin
 - Voi verrata Cucumber-tuloksia: "build #42 vs #41 — mikä testi meni rikki?"
-**Poikkeukset:**
+---
- Vanha build siivottu → ei näy indeksissä
+
 ## UC4: Kehittäjä jäljittää kontin koko ketjun commitista (tuleva)
 **Actor:** Kehittäjä
 **Precondition:** Mikropalvelun commitista on ajettu deployment ja klusteritestit
 **Main success:**
 - Kehittäjä avaa mikropalvelun commitin
 - Näkee statusviestit: "Build OK", "Deployed to staging", "Integration tests OK"
 - Klikkaamalla statusta siirtyy toisen repon committiin
 - Koko ketju on navigoitavissa edestakaisin commit-statuslinkkien kautta
 ---
 ## UC5: Kehittäjä näkee deployatun version ympäristössä (tuleva)
 **Actor:** Kehittäjä
 **Precondition:** Deployment on suoritettu
 **Main success:**
 - Avaa Helm-repon commitin
 - Näkee suoraan mikä konttiversio on deployattu
 - Voi verrata mikropalvelun uusimpaan commitiin — onko ympäristö ajan tasalla?
 ---
 ## UC6: Kehittäjä saa Gitea 1.27+ Summary-näkymän raporttilinkeistä (tuleva)
 **Actor:** Kehittäjä
 **Precondition:** Gitea 1.27+ ja päivitetty runner
 **Main success:**
 - Avaa workflow'n Gitea Actionsissa
 - "Report Summary" -jobin Summary-välilehdellä näkyy taulukko linkeillä kaikkiin raportteihin
 - Yhdellä silmäyksellä näkee mitä testejä ajettiin ja pääsee klikkaamalla raportteihin
 ---
 ## Ei-toiminnalliset vaatimukset
 | Vaatimus | Toteutus |
-|----------|----------|
+|---|---|
-| Raportit selailtavissa HTML:nä | MinIO static web hosting |
+| Raportit selailtavissa HTML:nä | git-pages static hosting |
-| Linkki commitista suoraan raporttiin | Statusviestin `url`-kenttä |
+| Linkki commitista suoraan raporttiin | Commit-status API:n `target_url` |
-| Build-indeksi per projekti | Generoitu `index.html` Minioon |
+| Raporttien pysyvyys | git-pages retention sidecar |
-| Navigaatio raporttien välillä | "Back to build" / "Back to builds" — linkit indeksisivuilla |
+| Virheiden propagointi | Gitea Actions `needs`-ketju |
-| Cross-repo-navigaatio | Statusviestit linkittävät repoja ristiin |
+| Pipeline-pysäytys virhetilanteessa | `needs` automaattinen skip |
-| Raporttien pysyvyys | ConfigMap-pohjainen retention policy |
+| Exit-koodi ainoa totuus | ADR 0008 |
-| Autentikointi | OIDC (Traefik middleware, Gitea OAuth2) |
+| Statusraportointi vain raporttilinkeille | ADR 0007 |
@@ -18,7 +18,7 @@ Runnerilla on yksi vastuu: **suorittaa workflow-steppejä**. Kaikki runtime-ymp
 ## Kontit ja palvelut
-Jokainen job voi määritellä käyttämänsä kontit. Tämä vastaa Jenkinsin pod template -konseptia, mutta on yksinkertaisempi:
+Jokainen job voi määritellä käyttämänsä kontit. Eri jobeilla voi olla eri kontti:
 ### `container:` — ajonaikainen ympäristö
@@ -99,13 +99,3 @@ Eri labelit mahdollistavat erikoistuneet runnerit (ARM, GPU, Windows), mutta MVP
 |------|-------|-------|--------------|
 | **Global** | Kaikki organisaatiot ja repot | Token-vuoto → hyökkääjä voi ajaa koodia missä tahansa | Jaettu infra, keskitetty hallinta |
 | **Organization** | Yhden organisaation repot | Rajoittuu yhteen orgiin | Per organisaatio, eristetty — **suositeltu** |
 ## Jenkins-vertailu
 | Jenkins | Gitea Actions |
 |---------|--------------|
 | Pod template (YAML) määrittelee kontit | `container:` + `services:` per job |
 | Jokaiselle jobille oma pod | Jokaiselle jobille omat konttimääritykset |
 | DinD sidecar-podissa | `services: docker:dind` samassa jobissa |
 | Agentti = erillinen JVM-prosessi | Runner = kevyt Go-binääri tai K8s-pod |
 | Labelit Jenkins-nodessa | Labelit runner-rekisteröinnissä |
@@ -1,197 +1,141 @@
 # Jaetut skriptit
-> ⚠️ **POC-vaihe.** Osa kuvatuista skripteistä (push-reports.sh, tag-commit.sh)
+> Provider-skriptit asuvat `scripts/`-hakemistossa. Consumer-skriptit
-> on suunniteltu mutta ei toteutettu. Toteutetut: `publish-git-pages.sh`,
+> asuvat `.gitea/scripts/`-hakemistossa. ADR 0006.
 > `report-status.sh`, `dispatch-workflow.sh` (POC-taso).
 >
 > Uudelleenkirjoitus odottaa: skriptien määrä ja rajapinnat voivat muuttua.
 Skriptit asuvat `gitea-ci-library/scripts/`-hakemistossa.
 ---
 ## `report-status.sh`
-POSTaa build-statuksen Gitea-commitin REST APIin.
+POSTaa commit-statuksen Gitea REST APIin. Käytetään **vain** kun tarvitaan
 custom-linkki (testiraportti, Docker registry). Tool-jobit luottavat
 Gitean natiiviin job-statukseen. ADR 0007.
 ### Rajapinta
 ```bash
-report-status.sh <state> <description> <url> [key] [root_commit] [root_repo]
+report-status.sh <state> <description> <context> [suite] [custom_url]
 ```
 | Parametri | Pakollinen | Kuvaus |
-|-----------|------------|--------|
+|---|---|---|
-| `state` | Kyllä | `pending`, `success`, `failure`, `error` |
+| `state` | Kyllä | `pending`, `success`, `failure` |
-| `description` | Kyllä | Ihmisluettava kuvaus (esim. "Unit tests passed") |
+| `description` | Kyllä | Ihmisluettava kuvaus |
-| `url` | Kyllä | Linkki buildiin tai raporttiin |
+| `context` | Kyllä | Uniikki avain (`unit-tests`, `acc-tests`, `ci-docker-build-push`) |
-| `key` | Ei | Uniikki avain. Oletus: `commit-{sha_short}` |
+| `suite` | Ei | Julkaistun raportin suite-nimi → linkki git-pagesiin |
-| `root_commit` | Ei | Root-buildin commit-hash (cross-repo-raportointia varten) |
+| `custom_url` | Ei | Oma URL (ohittaa oletus-URL:n generoinnin) |
 | `root_repo` | Ei | Root-buildin repo (cross-repo-raportointia varten) |
 ### Kutsuesimerkkejä
 ```bash
-# Buildin aloitus
+# Testijobi, linkki git-pages-raporttiin
-report-status.sh pending "Building..." "$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID"
+report-status.sh success "Link to Bats reports" unit-tests bats
-# Testivaihe valmis, linkki raporttiin
+# Docker build, custom URL registryyn
-report-status.sh success "Unit tests OK" "$MINIO_BASE_URL/$GITHUB_REPOSITORY/${GITHUB_SHA::8}/cucumber/overview-features.html" "unit-test"
+report-status.sh success "Docker build & push 1.2.0 OK" ci-docker-build-push "" \
-
+  "https://gitea.example.com/org/-/packages/container/app/1.2.0"
 # Deployment valmis, cross-repo: raportoi takaisin mikropalvelun committiin
 report-status.sh success "Deployed to staging" "$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/commit/$GITHUB_SHA" "deploy-staging" "$ROOT_COMMIT" "$ROOT_REPO"
 ```
 ### URL-generointi
 - Jos `suite` annettu → URL: `${GIT_PAGES_URL}/${repo}/reports/${sha8}/${suite}/`
 - Jos `custom_url` annettu → käytetään sellaisenaan
 - Muuten → URL: `${GITEA_API_URL}/${repo}/actions/runs/${run_id}` (Gitea Actions -loki)
 ### Gitea API -kutsu
 ```bash
 curl -X POST "$GITEA_API_URL/api/v1/repos/$REPO/statuses/$COMMIT" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
-  -d "{
+  -d "{\"state\":\"$STATE\",\"target_url\":\"$URL\",\"description\":\"$DESCRIPTION\",\"context\":\"$CONTEXT\"}"
    \"state\": \"$STATE\",
    \"target_url\": \"$URL\",
    \"description\": \"$DESCRIPTION\",
    \"context\": \"$KEY\"
  }"
 ```
-Status-arvot mapataan Gitean skeemaan: `pending` (INPROGRESS), `success` (SUCCESS), `failure` (FAILURE), `error` (STOPPED).
+---
 ## `publish-git-pages.sh`
 Julkaisee raporttihakemiston git-pages-palveluun PATCH-tar:na.
 ### Rajapinta
 ```bash
 publish-git-pages.sh <suite>
 ```
 | Parametri | Pakollinen | Kuvaus |
 |---|---|---|
 | `suite` | Kyllä | Raporttihakemiston nimi (`bats`, `cucumber`, `junit`, ...) |
 ### Toiminta
 1. Lukee raportit hakemistosta `reports/${SHA8}/${suite}/`
 2. Pakkaa tar:ksi ja PATCHaa git-pagesiin BasicAuthilla
 3. Tulostaa raportin base-URL:n stdoutiin
 ### Vaaditut env-muuttujat
 | Muuttuja | Lähde |
 |---|---|
 | `GITEA_API_URL` | `env_json` → workflow `env:` |
 | `GIT_PAGES_URL` | `env_json` → workflow `env:` |
 | `GIT_PAGES_PUBLISH_TOKEN` | Gitea secret → `env:` |
 | `GITHUB_REPOSITORY` | Automaattinen |
 | `GITHUB_SHA` | Automaattinen |
 ---
 ## `ci-validate.sh`
 Validoi `.conf`-tiedoston ja tarkistaa että pakolliset secretit on asetettu.
 Kutsutaan `config-provider.yml`:stä osana konfiguraation latausta.
 ### Rajapinta
 ```bash
 ci-validate.sh
 ```
 Lukee tiedoston polun `CI_CONF_FILE`-env-muuttujasta (oletus: `.gitea/workflows/gitea-env.conf`).
 ### Validointisäännöt
 - `.conf`-tiedosto on olemassa
 - Jokaisella `KEY=VALUE`-rivillä on arvo (ei tyhjää)
 - URL-tyyppiset avaimet alkavat `http://` tai `https://`
 - `GITEA_TOKEN` on asetettu
 - `GIT_PAGES_PUBLISH_TOKEN` on asetettu
 ---
 ## `dispatch-workflow.sh`
 Dispatchaa workflow'n toisessa repossa ja pollaa sen valmistumista synkronisesti.
 Käytetään GitOps-deploymentissa ja klusteritestien ketjutuksessa (tuleva).
 ### Rajapinta
 ```bash
-dispatch-workflow.sh <target_repo> <workflow_file> <ref> <inputs_json> <gitea_api_url> <gitea_token> [timeout_minutes]
+dispatch-workflow.sh <target_repo> <workflow_file> <ref> <inputs_json> [timeout_minutes]
 ```
 | Parametri | Pakollinen | Kuvaus |
 |-----------|------------|--------|
 | `target_repo` | Kyllä | `owner/repo` |
 | `workflow_file` | Kyllä | Workflow-tiedoston nimi (esim. `test.yml`) |
 | `ref` | Kyllä | Branch |
 | `inputs_json` | Kyllä | JSON-objekti input-parametreina |
 | `gitea_api_url` | Kyllä | Gitean API-URL (esim. `https://gitea.example.com`) |
 | `gitea_token` | Kyllä | Gitea API -token |
 | `timeout_minutes` | Ei | Oletus: 360 (6 tuntia) |
 ### Toiminta
 1. **Dispatch:** `POST /api/v1/repos/{target_repo}/actions/workflows/{workflow_file}/dispatches`
-2. **Etsi run:** `GET /api/v1/repos/{target_repo}/actions/runs?status=running` → etsi uusin (aikaleimasta)
+2. **Poll:** `GET /api/v1/repos/{target_repo}/actions/runs` → odota valmistumista
-3. **Poll:** `GET /api/v1/repos/{target_repo}/actions/runs/{run_id}` 10s välein
+3. **Palauta:** `conclusion` (`success`/`failure`/`timeout`)
 4. **Lopeta:** Kun `status == "completed"` → palauta `conclusion` (`success`/`failure`/`cancelled`)
 5. **Timeout:** Jos kestää yli `timeout_minutes` → palauta `timeout`
 ### Kutsuesimerkki
 ```bash
 dispatch-workflow.sh "tests/integration" "test.yml" "main" \
  '{"version":"1.2.3","tags":"@smoke","root_commit":"abc123","root_repo":"services/temperature-store"}' \
  "https://gitea.example.com" "gtp_abc123"
 ```
 ---
 ## `push-reports.sh` (vanhentunut — korvattu `publish-git-pages.sh`:lla)
 Puskaa raporttihakemiston git-pagesiin.
 ### Rajapinta
 ```bash
 push-reports.sh <report_type> <source_dir> [index_title]
 ```
 | Parametri | Pakollinen | Kuvaus |
 |-----------|------------|--------|
 | `report_type` | Kyllä | Raportin tyyppi (`cucumber`, `jacoco`, `junit`, `site`) |
 | `source_dir` | Kyllä | Paikallinen hakemisto, jossa raporttitiedostot |
 | `index_title` | Ei | Näkyvä nimi indeksisivulla (esim. "Cucumber Reports") |
 ### Toiminta
 1. Kopioi raportit: `mc cp --recursive {source_dir} minio/reports/{repo}/{commit_short}/{report_type}/`
 2. Päivitä `/reports/{repo}/{commit_short}/index.html` — lisää linkki tähän raporttiin
 3. Päivitä `/reports/{repo}/index.html` — varmista että tämä build on listalla
 4. Palauta URL: `{MINIO_BASE_URL}/{repo}/{commit_short}/{report_type}/index.html`
 ### Indeksisivut
 **Projektin build-indeksi** (`/reports/{repo}/index.html`):
 - Lista buildeista aikajärjestyksessä (uusin ensin)
 - Jokainen rivi: commit hash (linkki), päivämäärä, status (✅/❌), branch
 **Buildin raportti-indeksi** (`/reports/{repo}/{commit_short}/index.html`):
 - Lista raporteista linkkeinä
 - Linkki "← Back to builds" → projektin build-indeksiin
 Molemmat generoidaan uudestaan jokaisen pushauksen yhteydessä. Staattinen HTML, ei vaadi palvelinpuolen logiikkaa.
 ### Kutsuesimerkki
 ```bash
 push-reports.sh cucumber target/cucumber-report "Cucumber Reports"
 # → https://reports.example.com/temperature-store/abc12345/cucumber/overview-features.html
 push-reports.sh jacoco target/jacoco-report "JaCoCo Coverage"
 # → https://reports.example.com/temperature-store/abc12345/jacoco/index.html
 ```
 ---
 ## `tag-commit.sh`
 Tagittaa commitin versiolla Gitea REST API:n kautta.
 ### Rajapinta
 ```bash
 tag-commit.sh <version>
 ```
 ### Toiminta
 ```bash
 curl -X POST "$GITEA_API_URL/api/v1/repos/$GITHUB_REPOSITORY/tags" \
  -H "Authorization: token $GITEA_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"tag_name\": \"$VERSION\",
    \"message\": \"Build #$GITHUB_RUN_NUMBER\",
    \"target\": \"$GITHUB_SHA\"
  }"
 ```
 ### Kutsu
 ```bash
 tag-commit.sh "1.2.3.$GITHUB_RUN_NUMBER"
 ```
 Tagataan vain onnistuneen buildin ja pushin jälkeen. Tämän jälkeen `isContainerBuilt()` palauttaa `true` samalle commitille.
 ---
 ## Muuttujat, joita skriptit olettavat
 Skriptit lukevat nämä Gitea Actionsin ympäristömuuttujat:
 | Muuttuja | Lähde | Käyttäjä |
-|----------|-------|----------|
+|---|---|---|
-| `GITEA_API_URL` | Org variable | `report-status.sh` |
+| `GITEA_API_URL` | `env_json` | `report-status.sh`, `ci-validate.sh` |
-| `GITEA_TOKEN` | Org secret | `report-status.sh`, `tag-commit.sh` |
+| `GIT_PAGES_URL` | `env_json` | `publish-git-pages.sh`, `report-status.sh` |
-| `MINIO_BASE_URL` | Org variable | `push-reports.sh` |
+| `GITEA_TOKEN` | Gitea secret | `report-status.sh`, `check-version.yml`, `docker-build-push.yml` |
-| `MINIO_ACCESS_KEY` | Org secret | `push-reports.sh` |
+| `GIT_PAGES_PUBLISH_TOKEN` | Gitea secret | `publish-git-pages.sh` |
 | `MINIO_SECRET_KEY` | Org secret | `push-reports.sh` |
 | `GITHUB_REPOSITORY` | Automaattinen | Kaikki skriptit |
 | `GITHUB_SHA` | Automaattinen | Kaikki skriptit |
-| `GITHUB_SERVER_URL` | Automaattinen | `report-status.sh` |
+| `GITHUB_RUN_ID` | Automaattinen | `report-status.sh` |
-| `GITHUB_RUN_ID` | Automaattinen | `report-status.sh`, `tag-commit.sh` |
+| `GITHUB_RUN_NUMBER` | Automaattinen | `docker-build-push.yml` (tag-commit) |
 | `GITHUB_RUN_NUMBER` | Automaattinen | `tag-commit.sh` |
 | `GITHUB_ACTOR` | Automaattinen | Docker-labelit |
@@ -1,7 +1,6 @@
 # Tech Stack — Gitea Actions CI -kirjasto
-> ⚠️ POC-vaihe. Osa teknologiavalinnoista voi muuttua uudelleenkirjoituksen
+> Katso myös `git-pages/docs/tech-stack.md`.
 > myötä. Katso myös `git-pages/docs/tech-stack.md`.
 ---
@@ -21,19 +20,22 @@ 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`.
 Tulevaisuus: `GITHUB_STEP_SUMMARY` (Gitea 1.27+) tarjoaa Summary-näkymän
 suoraan Gitea UI:ssa.
 ## Tuetut ulkoiset palvelut
 | Palvelu | Rajapinta | Käyttötarkoitus |
 |---|---|---|
-| **Gitea REST API** | `/api/v1/` | Commit-status, workflow-dispatch, branch-listaus (retention) |
+| **Gitea REST API** | `/api/v1/` | Commit-status, git-tagit, workflow-dispatch |
-| **git-pages** | HTTP | Raporttien hostaus |
+| **git-pages** | HTTP (PATCH tar) | Raporttien hostaus |
 | **Gitea Packages** | Container registry API | Docker-imagen push |
-## Mitä EI tueta (verrattuna Jenkins-versioon)
+## Mitä EI tueta
 | Teknologia | Syy |
 |---|---|
-| **MinIO** | Korvattu git-pagesilla |
+| **Multi-Git-platform** | Vain Gitea — yksi alusta kunnolla (periaate 10) |
-| **Multi-Git-platform** | Vain Gitea |
+| **Custom actionit** | Reusable workflow on kevyempi ja natiivimpi (periaate 2) |
-| **Jenkins** (shared library, plugins) | Gitea Actions korvaa |
+| **Ulkoinen orkestraattori** | Gitean `needs` + `if` hoitaa ohjauksen |
-| **Artifactory/Nexus** | MVP:ssä ei, factory/adapter-pattern valmiina |
+| **Artifactory/Nexus** | Gitea Packages riittää MVP:ssä |
@@ -108,7 +108,7 @@ raportit git-pagesiin, asettaa commit-statuksen linkillä raporttiin.
 Ajaa Cucumber-testit Node-kontissa, julkaisee raportit git-pagesiin, asettaa
 commit-statuksen linkillä raporttiin.
-### `example-report-summary.yml` — Raporttien koontinäkymä
+### `report-summary.yml` — Raporttien koontinäkymä
 **Trigger:** `workflow_call` — ajetaan `if: always()` testien jälkeen
@@ -0,0 +1,86 @@
 #!/usr/bin/env bash
 set -euo pipefail
 DESCRIPTION="${1:-}"
 CONTEXT="${2:-}"
 SUITE="${3:-}"
 [ -n "$DESCRIPTION" ] || { echo "ERROR: description argument required" >&2; exit 1; }
 [ -n "$CONTEXT" ] || { echo "ERROR: context argument required" >&2; exit 1; }
 [ -n "$SUITE" ] || { echo "ERROR: suite argument required" >&2; exit 1; }
 REPORT_DIR="reports/${SUITE}"
 if [ ! -d "$REPORT_DIR" ]; then
  echo "ERROR: $REPORT_DIR not found" >&2
  bash .ci/scripts/report-status.sh failure "$DESCRIPTION" "$CONTEXT"
  exit 1
 fi
 FILES=()
 while IFS= read -r -d '' f; do
  FILES+=("$(basename "$f")")
 done < <(find "$REPORT_DIR" -maxdepth 1 -type f ! -name index.html -print0 2>/dev/null || true)
 SUBDIRS=()
 while IFS= read -r -d '' d; do
  name="${d#$REPORT_DIR/}"
  [ -f "$d/index.html" ] && SUBDIRS+=("$name")
 done < <(find "$REPORT_DIR" -maxdepth 1 -type d ! -name . -print0 2>/dev/null || true)
 TOTAL=$(( ${#FILES[@]} + ${#SUBDIRS[@]} ))
 if [ "$TOTAL" -eq 0 ]; then
  echo "ERROR: no reportable items in $REPORT_DIR" >&2
  bash .ci/scripts/report-status.sh failure "$DESCRIPTION" "$CONTEXT"
  exit 1
 fi
 SHA8="${GITHUB_SHA:0:8}"
 humanize() {
  local name="$1"
  name="${name%.*}"
  name="${name//-/ }"
  name="${name//_/ }"
  echo "${name^}"
 }
 generate_index() {
  local html
  html='<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">'
  html+="<title>$DESCRIPTION</title>"
  html+='<style>body{font-family:sans-serif;margin:2em;max-width:960px}h1{color:#1e293b}ul{list-style:none;padding:0}li{margin:.5em 0;padding:.5em;background:#f8fafc;border-radius:6px}a{color:#2563eb;text-decoration:none}a:hover{text-decoration:underline}</style>'
  html+="</head><body><h1>$DESCRIPTION</h1><ul>"
  for f in "${FILES[@]}"; do
    html+="<li><a href=\"$f\">$(humanize "$f")</a></li>"
  done
  for d in "${SUBDIRS[@]}"; do
    html+="<li><a href=\"$d/index.html\">${d^}</a></li>"
  done
  html+='</ul></body></html>'
  printf '%s' "$html" > "$REPORT_DIR/index.html"
 }
 STAGED="reports/${SHA8}/${SUITE}"
 mkdir -p "$STAGED"
 if [ "$TOTAL" -eq 1 ]; then
  cp -a "$REPORT_DIR/." "$STAGED/"
  bash .ci/scripts/publish-git-pages.sh "$SUITE"
  if [ ${#FILES[@]} -eq 1 ]; then
    ENTRY="${FILES[0]}"
  else
    ENTRY="${SUBDIRS[0]}/index.html"
  fi
  URL="${GIT_PAGES_URL}/${GITHUB_REPOSITORY}/reports/${SHA8}/${SUITE}/${ENTRY}"
  bash .ci/scripts/report-status.sh success "$DESCRIPTION" "$CONTEXT" "" "$URL"
 else
  generate_index
  cp -a "$REPORT_DIR/." "$STAGED/"
  bash .ci/scripts/publish-git-pages.sh "$SUITE"
  bash .ci/scripts/report-status.sh success "$DESCRIPTION" "$CONTEXT" "$SUITE"
 fi
 rm -rf "$STAGED"
@@ -33,7 +33,42 @@ else
 fi
 mkdir -p "$TARGET"
 cp -a "$REPORT_DIR/." "$TARGET/"
-cat > "$WORK/${OWNER}/${REPO}/reports/${SHA8}/.meta" <<EOF
+if [ ! -f "$TARGET/index.html" ]; then
  items=()
  while IFS= read -r -d '' f; do
    items+=("$(basename "$f")")
  done < <(find "$TARGET" -maxdepth 1 -type f ! -name index.html -print0 2>/dev/null || true)
  while IFS= read -r -d '' d; do
    name=$(basename "$d")
    [ -f "$d/index.html" ] && items+=("$name")
  done < <(find "$TARGET" -maxdepth 1 -type d ! -name . -print0 2>/dev/null || true)
  if [ ${#items[@]} -gt 1 ]; then
    {
      echo '<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">'
      echo "<title>Test report ${SHA8}</title>"
      echo '<style>body{font-family:sans-serif;margin:2em;max-width:960px}'
      echo 'h1{color:#1e293b}ul{list-style:none;padding:0}'
      echo 'li{margin:.5em 0;padding:.5em;background:#f8fafc;border-radius:6px}'
      echo 'a{color:#2563eb;text-decoration:none}a:hover{text-decoration:underline}'
      echo '</style></head><body>'
      echo "<h1>Test report <code>${SHA8}</code></h1><ul>"
      for item in "${items[@]}"; do
        label="${item%.*}"
        label="${label//-/ }"
        label="${label//_/ }"
        if [ -f "$TARGET/$item" ]; then
          echo "<li><a href=\"$item\">${label^}</a></li>"
        else
          echo "<li><a href=\"$item/index.html\">${label^}</a></li>"
        fi
      done
      echo '</ul></body></html>'
    } > "$TARGET/index.html"
  fi
 fi
 cat > "$TARGET/.meta" <<EOF
 {"branch":"${GITHUB_REF_NAME:-}","sha":"${GITHUB_SHA}","published_at":"$(date -u +%Y-%m-%dT%H:%M:%SZ)"}
 EOF
 find "$WORK/$OWNER" \( -type f -o -type l \) -print | sed "s|^${WORK}/||" | tar -cf "$TAR" -C "$WORK" -T -
@@ -0,0 +1,149 @@
 ---
 name: ci-container-build
 description: |
  Creating or modifying CI container build workflows. Activates when consumer
  needs to build a custom CI container image (multi-tool image for tests,
  linting, validation) that is pushed to a container registry for use in
  other pipeline jobs.
 activation-gate: |
  User mentions CI container, custom CI image, ci-container-build, Dockerfile
  for CI tools, multi-tool container, or needs to build/push a container that
  other CI jobs will use as their runtime environment.
 category: ci
 impact: high
 ---
 # CI Container Build — Template
 Template jolla consumer luo oman CI-kontin build-workflown.
 Kontti sisältää useamman työkalun yhdistelmän (esim. helm + kubeconform + xsltproc),
 jota muut jobit käyttävät ajonaikaisena ympäristönä.
 ## Rakenne
 Vain `workflow_dispatch` — **ei automaattista buildausta koskaan**. Kontti buildataan
 manuaalisesti Gitea Actions UI:sta. Tiedoston ilmestyessä main-haaraan workflow näkyy
 välittömästi Actions-tabissa ajettavana.
 Build-prosessi lataa ensin `config-provider.yml`:llä `DOCKER_REGISTRY`:n
 conf-tiedostosta, sitten buildaa ja puskaa kontin.
 Kun kontti on pushattu registryyn, se on muiden pipeline-jobien käytettävissä
 `latest`-tägillä — rebuild = käyttöönotto. Mitään versioviittauksia ei tarvitse
 päivittää.
 ## Nimeäminen
 CI-kontin build-workflow noudattaa samaa nimeämiskonventiota kuin muutkin
 tiedostot `.gitea/workflows/`-kansiossa:
 ```
 <komponentti>.ci-feature.yml                  ← feature-haaran reititin
 <komponentti>.ci-main.yml                     ← main-haaran reititin
 <komponentti>.<testityyppi>.yml               ← yksittäinen testi tai operaatio
 <komponentti>.ci-container-build-<kontti>.yml ← CI-kontin build-workflow
 <komponentti>.gitea-env.conf                  ← komponenttikohtainen konfiguraatio
 ```
 Single repossa `<komponentti>` jätetään pois — tiedostot ovat suoraan `ci-feature.yml`,
 `ci-main.yml`, `<testityyppi>.yml`, `ci-container-build-<kontti>.yml`.
 Monorepossa prefiksi pitää komponentin tiedostot yhdessä: `ls <komponentti>.*` löytää kaikki
 kerralla. **Olemassaolevia prefiksejä ei saa poistaa.**
 Esimerkkejä:
 ```
 .gitea/workflows/chart.ci-container-build-helm.yml
 .gitea/workflows/api.ci-container-build-node.yml
 .gitea/workflows/ci-container-build-bats.yml    ← single repo
 ```
 ## Template
 > **Korvaa kaikki `__SUURAAKKOSET__`-placeholderit projektin todellisilla arvoilla.**
 > Ainoastaan `${{ ... }}`-syntaksilla merkityt Gitea Actions -muuttujat ovat ajonaikaisia
 > eikä niitä korvata.
 Luo `.gitea/workflows/__KOMPONENTTI__.ci-container-build-__KONTTI__.yml`
 (single repo: `ci-container-build-__KONTTI__.yml`):
 ```yaml
 name: CI Container Build & Push
 on:
  workflow_dispatch:
    inputs:
      config_path:
        required: true
        type: string
        description: 'Polku .gitea-env.conf-tiedostoon (esim. .gitea/workflows/chart.gitea-env.conf)'
      dockerfile_path:
        required: true
        type: string
        description: 'Polku Dockerfileen (esim. ci-helm.Dockerfile)'
      image_name:
        required: true
        type: string
        description: 'Kontin nimi ilman registry-polkua (esim. ci-helm)'
      tag:
        required: true
        type: string
        default: 'latest'
        description: 'Image-tägi'
 jobs:
  load-config:
    uses: __OWNER__/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
    secrets: inherit
    with:
      config_path: ${{ inputs.config_path }}
  build-push:
    needs: [load-config]
    uses: __OWNER__/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@v1
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      dockerfile_path: ${{ inputs.dockerfile_path }}
      image_name: ${{ inputs.image_name }}
      tag: ${{ inputs.tag }}
 ```
 ### Käyttö
 **Gitea Actions UI:sta** (heti kun tiedosto on main-haarassa):
 ```
 Gitea → Actions → CI Container Build & Push → Run workflow
 config_path:      .gitea/workflows/__KOMPONENTTI__.gitea-env.conf
 dockerfile_path:  ci-__TYÖKALU__.Dockerfile
 image_name:       ci-__TYÖKALU__
 tag:              latest
 ```
 ### Dockerfile
 Dockerfile yhdistää tarvitut työkalut yhteen konttiin. Molemmat tavat kelpaavat:
 ```dockerfile
 # Tapa A: COPY --from toisesta imagesta
 FROM __BASE_IMAGE__:__VERSION__
 COPY --from=__SOURCE_IMAGE__:__VERSION__ /path/to/binary /usr/local/bin/
 RUN apk add --no-cache __PAKETIT__    # Ei koskaan git:iä — kloonaus kuuluu pipelinelle
 # Tapa B: curl-lataus (normaali Dockerfilessa)
 FROM __BASE_IMAGE__:__VERSION__
 RUN apk add --no-cache curl __PAKETIT__ && \
    curl -fsSL __URL__/__BINARY__.tar.gz | tar xz -C /usr/local/bin && \
    apk del curl
 ```
 `COPY --from` on kevyempi (ei curl-asennusta). `curl` on selkeämpi kun binääri
 tulee suoraan GitHub Releasesista tai vastaavasta.
 ## Mitä EI kannata tehdä
 - Älä lisää `workflow_call`-triggariä — CI-konttia ei koskaan buildata automaattisesti
 - Älä poista `<komponentti>.`-prefiksiä olemassaolevista tiedostoista — ne kuuluvat monorepo-nimeämiskonventioon
 - Älä sisällytä CI-konttiin mitään sovelluskoodia — vain työkalut
 - Älä koskaan asenna `git`:iä CI-konttiin — repon kloonaus ja checkout ovat Gitea Actionsin natiiveja operaatioita, eivät kontin vastuulla. Git paisuttaa konttia turhaan ja luo harhan että kontti hallitsee repoa
@@ -0,0 +1,609 @@
 ---
 name: consumer-pipelines
 description: |
  Creating or modifying consumer CI pipelines, .gitea/workflows/ files,
  reusable test workflows, monorepo CI configuration, or CI routing files
  (ci-feature.yml, ci-main.yml, ci-*.yml). Activates when the user asks to
  build, fix, or change consumer-side Gitea Actions pipelines that use
  gitea-ci-library providers.
 activation-gate: |
  User mentions consumer pipelines, ci-feature.yml, ci-main.yml, test
  workflows, .gitea/workflows/ files, monorepo CI, routing files, or asks
  to create/modify CI pipelines on top of gitea-ci-library.
 category: ci
 impact: high
 ---
 # Consumer Pipelines — Pipeline Standards
 Säännöt joilla consumer-projektit rakentavat CI-pipelinejä `gitea-ci-library`-kirjaston päälle.
 Nämä eivät ole provider-kirjaston sääntöjä — ne kuvaavat miten consumerin kuuluu käyttää kirjastoa oikein.
 ## 1. Reitittimen puhtaus
 Reitittimet (`ci-feature.yml`, `ci-main.yml`) eivät sisällä `run:`-steppejä. Ne koostuvat vain:
 ```yaml
 uses:
 needs:
 if:
 secrets: inherit
 with:
  env_json:
  <parametrit>:
 ```
 Jokainen job vastaa yhtä loogista testiä tai operaatiota. Reititin on orkestraattori — kaikki suorittava
 logiikka on omassa `workflow_call`-tiedostossaan.
 **Esimerkki:**
 ```yaml
 jobs:
  load-config:
    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
    secrets: inherit
  <test-1>:
    needs: [load-config]
    uses: ./.gitea/workflows/<component>.<test-1>.yml
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
  <test-2>:
    needs: [load-config]
    uses: ./.gitea/workflows/<component>.<test-2>.yml
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
  report-summary:
    needs: [load-config, <test-1>, <test-2>]
    if: always()
    uses: <owner>/gitea-ci-library/.gitea/workflows/report-summary.yml@v1
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      suites: <suite-1> <suite-2>
 ```
 ## 2. Yksi asia per tiedosto
 Ei monoliittista `ci-tests.yml`. Jokainen testityyppi tai operaatio on oma `workflow_call`-tiedostonsa.
 **Miksi:**
 - Testit ajetaan rinnakkain (ei keinotekoisia riippuvuuksia)
 - Yhden testin fail ei estä muita
 - Testattavissa itsenäisesti `workflow_dispatch`:llä
 - Diff näyttää heti mitä testiä muutettiin
 ## 3. Exit-koodin käsittely
 `set -e` on oletuksena käytössä Gitea Actions -stepeissä — ensimmäinen feilaava komento pysäyttää stepin
 ja exit-koodi välittyy natiivisti. Ylimääräistä `EXIT=$?` + `echo >> GITHUB_ENV` -käärettä ei tarvita.
 ```yaml
 - name: Run tests
  shell: bash
  run: |
    <testikomento> > results.txt 2>&1
 ```
 **Miksi ei pipeä (`| tee`):**
 ```bash
 # VÄÄRIN — pipe syö exit-koodin
 <komento> | tee results.txt
 # OIKEIN — redirect tiedostoon
 <komento> > results.txt 2>&1
 ```
 `set -e` ei pelasta pipe-tilanteessa — `|` syö exit-koodin kuten ennenkin. Redirectillä exit-koodi
 välittyy luonnollisesti.
 **Yksi asia per step:** Älä koskaan niputa useaa post-process-komentoa samaan `run:`-blockiin.
 `bash -e` pysäyttää koko stepin jos yksi komento epäonnistuu — seuraavat jäävät ajamatta.
 Käytä erillisiä steppejä `if: always()`:lla, jotta jokainen vaihe ajetaan itsenäisesti:
 ```yaml
 # VÄÄRIN — jos coverage epäonnistuu, report jää generoimatta
 - name: Post-process reports
  run: |
    bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
    bash .ci/.gitea/scripts/bats-report.sh reports/bats
 # OIKEIN — erilliset stepit if: always()
 - name: Post-process coverage
  if: always()
  run: bash .ci/.gitea/scripts/bats-coverage.sh reports/bats
 - name: Post-process test report
  if: always()
  run: bash .ci/.gitea/scripts/bats-report.sh reports/bats
 ```
 ## 4. Konttipolitiikka
 1. **Julkiset registry-kontit kiinteällä versiolla** — `alpine/helm:3.19.0`, `node:22`, `maven:3.9-eclipse-temurin-21`.
   Toistettavuus ja turvallisuus eivät saa riippua ulkoisesta `latest`:sta
 2. **Projektin omat CI-kontit `latest`-tägillä** — buildattu `ci-container-build-<kontti>.yml`:llä.
   Kontin build-pipeline päivittää `latest`:n automaattisesti. Rebuild = käyttöönotto
   kaikissa pipelineissa ilman versioviittauksien päivittelyä.
   `latest` on näille paras käytäntö, ei kompromissi
 3. **Ei koskaan `curl`-latauksia CI-ajon sisällä** — työkalujen asennus CI-stepeissä hidastaa,
   epäluotettavaa, ja vaikeuttaa toistettavuutta
 4. **Konttikuva hallitaan workflow'ssa, ei kutsujassa** — jos workflow vaatii tietyn
   konttikuvan, se määritellään oletuksena (`default:`) workflow'n inputissa.
   Kutsujan ei tarvitse tietää eikä välittää image-nimeä ellei halua ylikirjoittaa.
 CI-kontin build-workflow'n template: [skills/ci-container-build/SKILL.md](../ci-container-build/SKILL.md) — sisältää
 valmiin `ci-container-build-<kontti>.yml`-pohjan jossa `workflow_dispatch`-tuki manuaaliajoon.
 ### 4.1 CI-kontin ajaminen jobissa
 Ainoa sallittu tapa on `container:`-direktiivi. `docker run` komennolla kontin
 käynnistäminen stepin sisällä on anti-pattern.
 **Miksi:** `docker run` erilliskonttina aiheuttaa:
 - Tiedostojen jako vaatii erillisen volyyminhallinnan (`docker volume create`)
 - Coverage-data jää volyymiin, ei filesystemille → post-process-skriptit eivät löydä sitä
 - Ylimääräisiä siirtoja (`tar`, `docker cp`), jotka voivat epäonnistua hiljaa
 - Vaikeampi debugata (data on kontissa, ei CWD:ssä)
 `container:`-direktiivillä kaikki ajetaan samassa kontissa — tiedostot ovat suoraan
 filesystemillä, post-process-skriptit näkevät ne ilman erillistä siirtoa.
 ```yaml
 jobs:
  <työkalu>:
    runs-on: ubuntu-latest
    container:
      image: ${{ inputs.<image-name> }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/checkout@v4
        with:
          repository: <owner>/gitea-ci-library
          path: .ci
      - name: Run <työkalu>
        shell: bash
        run: |
          mkdir -p "reports/<suite>"
          <komento> > "reports/<suite>/results.txt" 2>&1
      - name: Post-process reports
        if: always()
        run: |
          <mahdollinen_raporttien_jälkikäsittely>
      - name: Report
        if: always()
        run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite>
 ```
 Jos testi tuottaa raportteja suoraan ilman jälkikäsittelyä, Post-process-steppiä ei tarvita.
 Jos jälkikäsittely on tarpeen (coverage-siirto, HTML-generointi raa'asta outputista),
 se tehdään omassa stepissä `if: always()` — katso tarkemmin [Raporttitasot](#5-raporttitasot).
 **Mallit:**
 - `example-cucumber-tests.yml` — ei post-processia
 - `example-bats-tests.yml` — post-process coverage + report
 ## 5. Raporttitasot
 Testi tuottaa raportin `reports/<suite>/`-hakemistoon. Yksi `ci-report.sh`-kutsu hoitaa sekä
 julkaisun että commit-statuksen — erillistä Publish + Report Status -kaksivaiheisuutta ei tarvita.
 ### Taso 1: Ei jälkikäsittelyä
 Kun testi tuottaa raportit suoraan (kuten `pytest --html` tai `cucumber-js --format html`):
 ```yaml
 - name: Run tests
  shell: bash
  run: |
    mkdir -p "reports/<suite>"
    <testikomento>
 - name: Report
  if: always()
  run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite>
 ```
 ### Taso 2: Jälkikäsittely tarvitaan
 Kun testi tuottaa raakadataa (stdout, coverage-tiedostot) joka pitää muuntaa tai siirtää
 `reports/<suite>/`-hakemistoon, käytetään Post-process-steppejä. **Jokainen operaatio
 omassa stepissään** — älä koskaan niputa useaa post-process-komentoa samaan `run:`-blockiin:
 ```yaml
 - name: Run tests
  shell: bash
  run: |
    mkdir -p "reports/<suite>"
    <testikomento> > "reports/<suite>/results.txt" 2>&1
 - name: Post-process coverage
  if: always()
  run: <siirrä coverage-data reports/<suite>/coverage/-hakemistoon>
 - name: Post-process test report
  if: always()
  run: <HTML-generointi raa'asta outputista>
 - name: Report
  if: always()
  run: bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite>
 ```
 **Huomio subdir-sisällöstä:** Jos testi tuottaa dataa alihakemistoon (esim.
 coverage `./coverage/`-kansioon), se pitää erikseen SIIRTÄÄ
 `reports/<suite>/<subdir>/`-hakemistoon ennen `ci-report.sh`:n ajoa.
 Ilman siirtoa sisältö ei näy index-sivulla, vaikka työkalu tuottaisi sen oikein.
 Subdir vaatii lisäksi `index.html`:n, jotta `ci-report.sh` löytää sen.
 **Miksi:** Gitea Actions käyttää `bash -e`-oletusta. Jos yksi post-process-komento
 epäonnistuu (esim. `set -euo pipefail`-skripti), koko stepi pysähtyy eivätkä seuraavat
 komennot käynnisty — raportti jää julkaisematta. Erilliset stepit `if: always()` takaavat
 että jokainen post-process-vaihe ajetaan itsenäisesti.
 ### Monta raportoitavaa tiedostoa
 Kun `reports/<suite>/`-hakemistossa on useita tiedostoja tai alihakemistoja,
 `ci-report.sh` generoi automaattisesti `reports/<suite>/index.html` jos hakemistossa
 on enemmän kuin yksi raportoitava item.
 ```
 reports/<suite>/
 ├── results.txt               ← testin stdout (skannataan FILES)
 ├── test-report.html          ← generoitu HTML (skannataan FILES)
 └── <mikä tahansa>/           ← alihakemisto (skannataan SUBDIRS)
    └── index.html            ← VAIN jos tämä on olemassa
 ```
 **Subdir-sääntö:** Alihakemisto näkyy indexissä VAIN jos se sisältää `index.html`:n.
 Pelkkä tyhjä subdir ilman `index.html`:ää ei näy — tämä on yleisin syy miksi
 jokin raportin osa (kuten coverage) puuttuu indexistä.
 ## 6. Raportin julkaisukelpoisuus
 `ci-report.sh` päättää onko raportti julkaisukelpoinen skannaamalla
 `reports/<suite>/`-hakemistoa.
 ### Mitä skannataan
 | Mitä | Sääntö |
 |---|---|
 | **Tiedostot (FILES)** | Kaikki `reports/<suite>/`-juuressa olevat tiedostot paitsi `index.html` |
 | **Alihakemistot (SUBDIRS)** | Vain ne, joissa on `index.html` |
 ### Julkaisukelpoisuus
 | Tila | Seuraus |
 |---|---|
 | `FILES + SUBDIRS = 0` | **Failure** — `ci-report.sh` palauttaa virheen, raporttia ei julkaista |
 | `FILES + SUBDIRS = 1` | Suora linkki itemiin — ei generoi index-sivua |
 | `FILES + SUBDIRS > 1` | Generoi `reports/<suite>/index.html`-sivun, linkit kaikkiin itemeihin |
 ### Esimerkki: coverage-näkymä
 ```
 reports/<suite>/coverage/index.html   ← on olemassa
 ```
 Coverage-dataa ei siirretä automaattisesti. Testin tai post-process-stepin pitää
 siirtää coverage `reports/<suite>/coverage/`-hakemistoon ja varmistaa että
 `index.html` on mukana. Sama periaate pätee mihin tahansa subdir-sisältöön.
 ## 7. Debug-ohje: raportti ei näy
 ### 1. Aja lokaalisti samalla komennolla kuin CI
 Näet mitä tiedostoja syntyy, mihin ne tulevat ja mikä on työkalun exit-koodi.
 ```bash
 # Esimerkki
 mkdir -p reports/bats
 bashcov -- bats tests/ > reports/bats/results.txt 2>&1
 echo "exit: $?"
 ls -la reports/bats/
 ```
 ### 2. Lisää `echo "DEBUG: ..." >&2` ennen ja jälkeen kriittisen operaation
 Debuggaus stderriin (`>&2`) näkyy CI-logissa eikä häiritse skriptin normaalia outputia.
 ```bash
 echo "DEBUG: coverage exists? $([ -d coverage ] && echo YES || echo NO)" >&2
 echo "DEBUG: target/index.html exists? $([ -f reports/suite/coverage/index.html ] && echo YES || echo NO)" >&2
 ```
 ### 3. Tarkista kutsuparametrit
 Yleisin virhe: skripti odottaa `$1` = X, mutta kutsuja antaa `$1` = Y ja `$2` = X.
 Skripti lukee väärän parametrin ja etsii dataa väärästä paikasta.
 ### 4. Tarkista tiedostopolut
 1. Onko lähdetiedosto olemassa ennen kopiointia?
 2. Onko kohde olemassa kopioinnin jälkeen?
 3. Onko `index.html` subdirissä (vaaditaan `ci-report.sh`:lle)?
 Jos vastaus johonkin on "ei" — tiedät mikä pitää korjata.
 ### 5. Poista debug-echot kun ongelma on korjattu
 Debug-rivit eivät kuulu tuotantoon.
 ### 6. Älä kokeile — debuggaa
 Kokeilu = arvaus. Debuggaus = lisää echo, aja, lue logi, eristä ongelma.
 Vasta sitten korjaa. Tämä on nopeampi tie oikeaan ratkaisuun.
 ## 8. Nimeäminen
 Tiedostonimet `.gitea/workflows/`-kansiossa noudattavat yhtenäistä rakennetta, jotta
 tiedostot löytyvät nopeasti ja niiden rooli on selvillä:
 ```
 <komponentti>.ci-feature.yml                  ← feature-haaran reititin
 <komponentti>.ci-main.yml                     ← main-haaran reititin
 <komponentti>.<testityyppi>.yml               ← yksittäinen testi tai operaatio
 <komponentti>.ci-container-build-<kontti>.yml ← CI-kontin build-workflow
 <komponentti>.gitea-env.conf                  ← komponenttikohtainen konfiguraatio
 ```
 Single repossa `<komponentti>` jätetään pois — tiedostot ovat suoraan `ci-feature.yml`,
 `ci-main.yml`, `<testityyppi>.yml`, `ci-container-build-<kontti>.yml`.
 Monorepossa prefiksi pitää komponentin tiedostot yhdessä: `ls <komponentti>.*` löytää kaikki
 kerralla.
 ## 9. Artifact-kuri
 Gitea Actionsin `upload-artifact` jättää pysyvän tiedoston. Artifakteja ei käytetä
 workflow_call:ien väliseen datan siirtoon ellei se ole teknisesti välttämätöntä.
 **Ensisijainen ratkaisu:** jokainen testi tuottaa tarvitsemansa datan itse. Ei
 `upload-artifact` + `download-artifact` -riippuvuuksia.
 ```yaml
 # OIKEIN — molemmat testit tuottavat oman datansa
 - name: Prepare data
  run: <komento> > /tmp/data
 - name: Validate data
  run: <validointikomento> /tmp/data
 ```
 **Miksi:**
 - Testit pysyvät itsenäisinä — yhden testin fail ei estä muita
 - Ei "artifact expired" -virheitä myöhemmin
 - Ei pysyviä artifakteja siivoamatta
 ---
 ## Konfiguraatiotiedosto (.gitea-env.conf)
 Tiedosto on `key=value`-muotoinen (kuten `.env`). Kommentit ja tyhjät rivit sallittuja.
 ### Single repo
 ```ini
 # .gitea/workflows/gitea-env.conf
 GITEA_API_URL=https://gitea.example.com
 GIT_PAGES_URL=https://reports.example.com
 ```
 ### Docker-artifaktin buildaavat projektit
 ```ini
 DOCKER_REGISTRY=gitea.example.com/myorg
 DOCKER_IMAGE_NAME=my-service
 DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container
 #DOCKERFILE=Dockerfile.platform   # valinnainen, oletus Dockerfile
 ```
 `DOCKER_UI_URL` ei sisällä image-nimeä — se on puhdas container-registryn osoite.
 Image-nimi lisätään automaattisesti URL:iin `docker-build-push.yml`:ssä.
 ### Salaisuudet (Gitea Settings → Secrets)
 | Secret | Pakollinen |
 |---|---|
 | `GITEA_TOKEN` | Aina (Gitean sisäinen, automaattisesti saatavilla) |
 | `GIT_PAGES_PUBLISH_TOKEN` | Aina |
 | `DOCKER_USERNAME` | Vain jos buildaat kontteja |
 | `DOCKER_PASSWORD` | Vain jos buildaat kontteja |
 ---
 ## Monorepo
 Monorepossa yhdessä repossa asuu useampi julkaistava komponentti. Jokaiselle komponentille
 oma conf-tiedosto `.gitea/workflows/<komponentti>.gitea-env.conf`, jossa on kaikki
 komponenttikohtainen tieto.
 ### Suositus: komponentit omiin juurihakemistoihin
 On suositeltavaa sijoittaa jokaisen komponentin koko lähdekoodi omaan juuritason
 hakemistoonsa (`api/`, `frontend/`, `shared/`). Tämä helpottaa `paths:`-filtteröintiä,
 pitää komponentit selkeästi erillään, ja tekee repossa navigoinnista suoraviivaista.
 Tämä on kuitenkin vain suositus — ei pakottava sääntö.
 ### Ongelmat ja ratkaisut
 | Ongelma | Ratkaisu |
 |---|---|
 | Monta komponenttia, yksi repo — mikä triggeröi? | `paths:`-filtteri: `push: { paths: ['<komponentti>/**'] }` |
 | Jokaisella komponentilla oma versio | `VERSION_FILE=<komponentti>/package.json` confissa |
 | Git-tägit sekaisin ellei nimiavaruutta | `GIT_TAG_PREFIX=<komponentti>/` confissa → tägi `<komponentti>/1.2.3` |
 | Eri julkaisutahdit | Riippumattomat CI-triggerit, omat versiopolut |
 ### Komponenttikohtainen conf
 ```ini
 # .gitea/workflows/<komponentti>.gitea-env.conf
 GITEA_API_URL=https://gitea.example.com
 GIT_PAGES_URL=https://reports.example.com
 DOCKER_REGISTRY=gitea.example.com/myorg
 DOCKER_IMAGE_NAME=<image-nimi>
 DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container
 GIT_TAG_PREFIX=<komponentti>/
 # Jompikumpi — JSON (.version-kenttä) tai plain text:
 VERSION_FILE=<komponentti>/package.json
 #VERSION_FILE=<komponentti>/VERSION
 ```
 ### Monorepo reititin
 ```yaml
 name: CI <Komponentti> Main
 on:
  push:
    branches:
      - main
    paths:
      - '<komponentti>/**'
 jobs:
  load-config:
    uses: <owner>/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
    secrets: inherit
    with:
      config_path: .gitea/workflows/<komponentti>.gitea-env.conf
  check-version:
    needs: [load-config]
    uses: <owner>/gitea-ci-library/.gitea/workflows/check-version.yml@v1
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
  <testit>:
    needs: [load-config, check-version]
    if: needs.check-version.outputs.artifact_exists != 'true'
    uses: ./.gitea/workflows/<komponentti>.<testi>.yml
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
  build-push:
    needs: [load-config, check-version, <testit>]
    if: needs.check-version.outputs.artifact_exists != 'true'
    uses: <owner>/gitea-ci-library/.gitea/workflows/docker-build-push.yml@v1
    secrets: inherit
    with:
      env_json: ${{ needs.load-config.outputs.env_json }}
      version: ${{ needs.check-version.outputs.version }}
 ```
 ### Version elinkaari per komponentti
 `GIT_TAG_PREFIX` takaa että eri komponenttien versiohistoria pysyy erillään.
 Git-tägi `<komponentti>/0.2.3` ei sekoitu toisen komponentin tägeihin.
 `check-version.yml` suodattaa ja laskee seuraavan patchin vain kyseisen
 komponentin etuliitteellä. Idempotenttius toimii komponenttikohtaisesti:
 jos commitilla on jo tägi, pipeline skipataan `if: artifact_exists != 'true'`.
 ### Mitä EI kannata tehdä monorepossa
 - Älä aja kaikkia komponentteja samasta triggeristä — `paths:` pitää CI:t erillisinä
 - Älä käytä samaa versionhallintatiedostoa usealle komponentille
 - Älä anna monorepo-parametreja pipeline-overrideina — kaikki kuuluu conf-tiedostoon
 ---
 ## Versionhallinta
 `check-version.yml` lukee version automaattisesti prioriteettijärjestyksessä:
 | # | Lähde | Formaatti |
 |---|---|---|
 | 1 | `VERSION_FILE` confissa | Määritelty polku |
 | 2 | `VERSION`-tiedosto (root) | Plain text |
 | 3 | `package.json` (root) | `.version`-kenttä |
 | 4 | `pom.xml` (root) | `<version>`-elementti |
 `major.minor` otetaan tästä. Patch lasketaan automaattisesti git-tageista.
 Esim. `VERSION` = `0.2`, tagit = `0.2.0`, `0.2.1` → seuraava `0.2.2`.
 ---
 ## Branch protection (PR-gate)
 Gitean Settings → Branches → Add Rule:
 - **Branch:** `main`
 - **Enable Require Status Checks:** päälle
 - **Status checks:** valitse testijobien nimet
 ---
 ## Provider-rajapinnat — referenssi
 ### Workflowt
 | Workflow | Käyttötarkoitus |
 |---|---|
 | `config-provider.yml` | Lataa + validoi `.conf`, tuottaa `env_json` |
 | `check-version.yml` | Tarkistaa onko commit buildattu, laskee version |
 | `docker-build-push.yml` | Buildaa + puskea Docker-imagen, tagittaa commitin |
 | `report-summary.yml` | `GITHUB_STEP_SUMMARY`-taulukko raporttilinkeillä (Gitea 1.27+) |
 ### Skriptit (kutsutaan `.ci/scripts/`-polun kautta)
 | Skripti | Käyttötarkoitus |
 |---|---|
 | `ci-report.sh` | Yhdistetty raportointi: julkaisee git-pagesiin ja asettaa commit-statuksen. Korvaa erilliset `publish-git-pages.sh` + `report-status.sh` -kutsut. Käyttö: `bash .ci/scripts/ci-report.sh "<kuvaus>" <context> <suite>` |
 | `report-status.sh` | POSTaa commit-statuksen linkillä (kutsutaan `ci-report.sh`:n sisältä) |
 | `publish-git-pages.sh` | Julkaisee raporttihakemiston git-pagesiin (kutsutaan `ci-report.sh`:n sisältä) |
 | `ci-validate.sh` | Validoi `.conf`-tiedoston (kutsutaan `config-provider.yml`:stä) |
 ---
 ## ADR-yhteenveto — consumerin kannalta oleelliset säännöt
 ### Reititin ei sisällä suorittavaa koodia (ADR 0010)
 `ci-feature.yml` ja `ci-main.yml` koostuvat **vain** `uses:`, `needs:` ja `if:`-avainsanoista.
 Ei `run:`-komentoja, ei inline-skriptejä, ei `actions/checkout`.
 ### Yksi steppi = yksi workflow_call-tiedosto
 Jokainen job reitittimessä on oma `workflow_call`-tiedostonsa.
 Ei kahta eri komentoa samassa workflow'ssa.
 ### Provider-versio on `@v1` (ADR 0009)
 Kaikki provider-viittaukset käyttävät `@v1`-tagia. `@main` on vain providerin oman repon
 sisäiseen dogfood-käyttöön. Breaking changet kielletty — `v1`-rajapinta on pysyvä.
 ### Paikalliset `uses:` eivät käytä refiä
 Gitea act runner v1.0.8 muodostaa paikallisista `uses: ./.gitea/workflows/*.yml@main`-viittauksista
 epävalidin git-refin `main@<sha>`, joka aiheuttaa virheen `Revision invalid : reference must
 be defined once at the beginning`.
 Paikallisista `uses:`-direktiiveistä EI koskaan käytetä `@main`- tai muuta ref-päätettä:
 - `uses: ./.gitea/workflows/chart.helm-lint.yml`  ← oikein
 - `uses: ./.gitea/workflows/chart.helm-lint.yml@main` ← väärin
 Ilman refiä runner käyttää workflow'ta triggeröivästä commitista. Ulkoisten repojen
 viittauksissa (`niko/...@v1`) pääte pysyy. Nämä resolvoidaan eri reittiä ja toimivat oikein.
 ### Exit-koodi on ainoa onnistumisen mittari (ADR 0008)
 Ei pipeä (`|`) komennon perässä — se syö exit-koodin. Käytä redirectiä (`> file 2>&1`).
 ### Commit-status vain raporttilinkille (ADR 0007)
 `ci-report.sh`-skriptiä käytetään VAIN kun on raportti linkitettäväksi.
 Tool-jobit (build, deploy) luottavat Gitean natiiviin job-statukseen.
 ### Providerin checkout ei kuulu consumerille
 Providerin scriptit haetaan `actions/checkout`-stepillä `.ci/`-polkuun.
 Consumer ei kopioi eikä muokkaa providerin tiedostoja.
@@ -6,7 +6,7 @@ const PROJECT_ROOT = path.resolve(__dirname, '..', '..', '..');
 const MOCK_SCRIPT = path.join(PROJECT_ROOT, 'tests', 'helpers', 'mock-api.sh');
 Before({ tags: '@mock' }, function () {
-  const out = execSync(`bash -c 'source "${MOCK_SCRIPT}" && mock_start && sleep 0.3 && curl -s -o /dev/null -w "%{http_code}" --max-time 3 http://localhost:18080/api/v1/repos/health/check'`, {
+  const out = execSync(`bash -c 'source "${MOCK_SCRIPT}" && mock_start && sleep 1 && curl -s -o /dev/null -w "%{http_code}" --max-time 3 http://localhost:18080/api/v1/repos/health/check'`, {
    cwd: PROJECT_ROOT,
    encoding: 'utf-8',
    stdio: ['pipe', 'pipe', 'pipe'],
@@ -24,6 +24,14 @@ _wait_port_free() {
  done
 }
 _wait_port_ready() {
  local i=0
  while ! lsof -ti ":$MOCK_PORT" >/dev/null 2>&1 && [ $i -lt 5 ]; do
    sleep 0.2
    i=$((i + 1))
  done
 }
 mock_set_sequence() {
  MOCK_SEQUENCE_FILE=$(mktemp)
  echo "$1" | jq -c '.' > "$MOCK_SEQUENCE_FILE"
@@ -55,7 +63,7 @@ mock_start() {
  nohup python3 "$(dirname "${BASH_SOURCE[0]}")/mock-server.py" "$MOCK_PORT" "$MOCK_CONFIG_FILE" "$MOCK_REQUEST_FILE" \
    </dev/null >/dev/null 2>&1 &
  MOCK_PID=$!
-  sleep 0.5
+  _wait_port_ready
 }
 mock_stop() {
Author	SHA1	Message	Date
niko	1e10633e60	Fix/uusi consumer kontti taktiikka (#23 ) acc-tests Cucumber test report Details CI Main / Cucumber tests (push) Successful in 49s Details CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 17s Details CI Main / Check existing artifact (push) Successful in 12s Details CI Main / Build & Push Docker (push) Successful in 35s Details CI Main / Move provider version tag (push) Successful in 13s Details unit-tests Bats test report Details CI Main / Bats tests (push) Successful in 1m19s Details ci-docker-build-push Docker build & push 0.2.10 OK Details CI Main / Report Summary (push) Successful in 6s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #23	2026-06-18 13:54:38 +03:00
niko	737b2fc3f2	Feature/yksinkertaistetaan raportointi logiikkaa (#22 ) unit-tests Bats test report Details CI Main / Bats tests (push) Successful in 1m21s Details ci-docker-build-push Docker build & push 0.2.9 OK Details CI Main / Build & Push Docker (push) Successful in 40s Details CI Main / Report Summary (push) Successful in 5s Details CI Main / Move provider version tag (push) Successful in 12s Details CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 18s Details CI Main / Check existing artifact (push) Successful in 12s Details acc-tests Cucumber test report Details CI Main / Cucumber tests (push) Successful in 2m3s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #22	2026-06-18 12:55:02 +03:00
niko	65d385f9b9	skill päivitetty (#21 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 17s Details CI Main / Check existing artifact (push) Successful in 13s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m35s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 54s Details ci-docker-build-push Docker build & push 0.2.8 OK Details CI Main / Build & Push Docker (push) Successful in 40s Details CI Main / Report Summary (push) Successful in 6s Details CI Main / Move provider version tag (push) Successful in 13s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #21	2026-06-17 17:02:44 +03:00
niko	2e5a4dca3a	Fix/ci container manual start (#20 ) CI Main / Bats tests (push) Successful in 1m34s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 51s Details CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 21s Details CI Main / Check existing artifact (push) Successful in 13s Details unit-tests Link to Bats reports Details ci-docker-build-push Docker build & push 0.2.7 OK Details CI Main / Build & Push Docker (push) Successful in 41s Details CI Main / Report Summary (push) Successful in 6s Details CI Main / Move provider version tag (push) Successful in 12s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #20	2026-06-17 14:19:05 +03:00
niko	29fde14445	Fix/fragile test (#19 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 17s Details CI Main / Check existing artifact (push) Successful in 12s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 2m41s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 1m44s Details CI Main / Move provider version tag (push) Successful in 12s Details ci-docker-build-push Docker build & push 0.2.6 OK Details CI Main / Build & Push Docker (push) Successful in 38s Details CI Main / Report Summary (push) Successful in 5s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #19	2026-06-17 07:41:01 +03:00
niko	f17ea7936e	Feature/monorepo support (#18 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 19s Details CI Main / Check existing artifact (push) Successful in 12s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m35s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 46s Details ci-docker-build-push Docker build & push 0.2.6 OK Details CI Main / Build & Push Docker (push) Successful in 42s Details CI Main / Report Summary (push) Successful in 4s Details CI Main / Move provider version tag (push) Successful in 13s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #18	2026-06-17 07:40:24 +03:00
niko	153205be40	cucumber kontin konf (#17 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 18s Details CI Main / Check existing artifact (push) Successful in 12s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m36s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 48s Details ci-docker-build-push Docker build & push 0.2.5 OK Details CI Main / Build & Push Docker (push) Successful in 31s Details CI Main / Report Summary (push) Successful in 3s Details CI Main / Move provider version tag (push) Successful in 10s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #17	2026-06-16 13:24:29 +03:00
niko	f3a54d6ed3	käytetään omia kontteja, eikä rakenneta lennosta! (#16 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 20s Details CI Main / Check existing artifact (push) Successful in 11s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m37s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Failing after 39s Details CI Main / Build & Push Docker (push) Has been skipped Details CI Main / Report Summary (push) Successful in 5s Details CI Main / Move provider version tag (push) Has been skipped Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #16	2026-06-16 10:17:53 +03:00
niko	8622b6fc4e	Feature/ci container (#15 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 19s Details CI Main / Check existing artifact (push) Successful in 14s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m43s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 1m9s Details ci-docker-build-push Docker build & push 0.2.4 OK Details CI Main / Build & Push Docker (push) Successful in 37s Details CI Main / Report Summary (push) Successful in 5s Details CI Main / Move provider version tag (push) Successful in 13s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #15	2026-06-16 09:13:36 +03:00
niko	dd9ad9e2c8	Feature/ci container (#14 ) ci-docker-build-push Docker build & push 0.2.3 OK Details CI Main / Build & Push Docker (push) Successful in 36s Details CI Main / Report Summary (push) Successful in 5s Details CI Main / Move provider version tag (push) Successful in 12s Details CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 21s Details CI Main / Check existing artifact (push) Successful in 14s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m46s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 1m12s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #14	2026-06-16 07:16:47 +03:00
niko	ffc0734b65	tägitys käyttöön consumer viittauksessa provider tiedostoihin (#13 ) CI Main / Check existing artifact (push) Successful in 12s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m44s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 1m31s Details CI Main / Build & Push Docker (push) Successful in 54s Details CI Main / Report Summary (push) Successful in 13s Details CI Main / Move provider version tag (push) Successful in 13s Details CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 19s Details ci-docker-build-push Docker build & push 0.2.2 OK Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #13	2026-06-16 06:07:40 +03:00
niko	14a411e340	consumer project käyttöönotossa tulleitea muutoksia (#12 ) CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 18s Details CI Main / Check existing artifact (push) Successful in 12s Details unit-tests Link to Bats reports Details CI Main / Bats tests (push) Successful in 1m41s Details acc-tests Link to Cucumber reports Details CI Main / Cucumber tests (push) Successful in 1m7s Details ci-docker-build-push Docker build & push 0.2.1 OK Details CI Main / Build & Push Docker (push) Successful in 34s Details CI Main / Report Summary (push) Successful in 4s Details Co-authored-by: moilanik <niko.moilanen@tietoevry.com> Reviewed-on: #12	2026-06-16 04:48:05 +03:00