Compare commits

..

4 Commits

Author SHA1 Message Date
niko 65d385f9b9 skill päivitetty (#21)
CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 17s
CI Main / Check existing artifact (push) Successful in 13s
unit-tests Link to Bats reports
CI Main / Bats tests (push) Successful in 1m35s
acc-tests Link to Cucumber reports
CI Main / Cucumber tests (push) Successful in 54s
ci-docker-build-push Docker build & push 0.2.8 OK
CI Main / Build & Push Docker (push) Successful in 40s
CI Main / Report Summary (push) Successful in 6s
CI Main / Move provider version tag (push) Successful in 13s
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
acc-tests Link to Cucumber reports
CI Main / Cucumber tests (push) Successful in 51s
CI Main / Load example-gitea-env.conf to pipeline env (push) Successful in 21s
CI Main / Check existing artifact (push) Successful in 13s
unit-tests Link to Bats reports
ci-docker-build-push Docker build & push 0.2.7 OK
CI Main / Build & Push Docker (push) Successful in 41s
CI Main / Report Summary (push) Successful in 6s
CI Main / Move provider version tag (push) Successful in 12s
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
CI Main / Check existing artifact (push) Successful in 12s
unit-tests Link to Bats reports
CI Main / Bats tests (push) Successful in 2m41s
acc-tests Link to Cucumber reports
CI Main / Cucumber tests (push) Successful in 1m44s
CI Main / Move provider version tag (push) Successful in 12s
ci-docker-build-push Docker build & push 0.2.6 OK
CI Main / Build & Push Docker (push) Successful in 38s
CI Main / Report Summary (push) Successful in 5s
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
CI Main / Check existing artifact (push) Successful in 12s
unit-tests Link to Bats reports
CI Main / Bats tests (push) Successful in 1m35s
acc-tests Link to Cucumber reports
CI Main / Cucumber tests (push) Successful in 46s
ci-docker-build-push Docker build & push 0.2.6 OK
CI Main / Build & Push Docker (push) Successful in 42s
CI Main / Report Summary (push) Successful in 4s
CI Main / Move provider version tag (push) Successful in 13s
Co-authored-by: moilanik <niko.moilanen@tietoevry.com>
Reviewed-on: #18
2026-06-17 07:40:24 +03:00
13 changed files with 744 additions and 476 deletions
+14 -3
View File
@@ -16,6 +16,8 @@ on:
env: env:
GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }} GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
GIT_TAG_PREFIX: ${{ fromJson(inputs.env_json).GIT_TAG_PREFIX || '' }}
VERSION_FILE: ${{ fromJson(inputs.env_json).VERSION_FILE || '' }}
jobs: jobs:
check: check:
@@ -28,7 +30,13 @@ jobs:
- name: Check existing artifact and calculate version - name: Check existing artifact and calculate version
run: | run: |
if [ -f VERSION ]; then 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:]') RAW_VERSION=$(cat VERSION | tr -d '[:space:]')
elif [ -f package.json ]; then elif [ -f package.json ]; then
RAW_VERSION=$(jq -r '.version' package.json) RAW_VERSION=$(jq -r '.version' package.json)
@@ -44,7 +52,10 @@ jobs:
TAGS_JSON=$(curl -s -f -H "Authorization: token $GITEA_TOKEN" \ TAGS_JSON=$(curl -s -f -H "Authorization: token $GITEA_TOKEN" \
"${{ gitea.server_url }}/api/v1/repos/${{ gitea.repository }}/tags") "${{ 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 mkdir -p /tmp/build-ctx
@@ -55,7 +66,7 @@ jobs:
else else
echo "ARTIFACT_EXISTS=false" > /tmp/build-ctx/build.env 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 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 if [ -z "$HIGHEST_PATCH" ]; then NEXT_PATCH=0; else NEXT_PATCH=$((HIGHEST_PATCH + 1)); fi
+9 -9
View File
@@ -12,31 +12,32 @@ on:
required: true required: true
type: string type: string
tag: tag:
required: true required: false
type: string type: string
default: 'latest'
secrets: secrets:
DOCKER_USERNAME: DOCKER_USERNAME:
required: false required: false
DOCKER_PASSWORD: DOCKER_PASSWORD:
required: true required: true
env:
DOCKER_REGISTRY: ${{ fromJson(inputs.env_json).DOCKER_REGISTRY || '' }}
IMAGE_NAME: ${{ inputs.image_name }}
TAG: ${{ inputs.tag }}
DOCKERFILE: ${{ inputs.dockerfile_path }}
jobs: jobs:
build-push: build-push:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/checkout@v4 - uses: actions/checkout@v4
- name: Build and push CI container - name: Build and push container
env: env:
DOCKER_REGISTRY: ${{ fromJson(inputs.env_json).DOCKER_REGISTRY || '' }}
DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME || github.actor }} DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME || github.actor }}
DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }} DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
run: | 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) NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
docker build \ docker build \
--label "git.commit=${{ github.sha }}" \ --label "git.commit=${{ github.sha }}" \
@@ -45,7 +46,6 @@ jobs:
-f "${DOCKERFILE}" \ -f "${DOCKERFILE}" \
-t "${IMAGE_NAME}:${TAG}" . -t "${IMAGE_NAME}:${TAG}" .
REGISTRY="${DOCKER_REGISTRY:?DOCKER_REGISTRY not set in env.conf}"
REGISTRY_HOST="${REGISTRY%%/*}" REGISTRY_HOST="${REGISTRY%%/*}"
FULL_IMAGE="${REGISTRY}/${IMAGE_NAME}:${TAG}" FULL_IMAGE="${REGISTRY}/${IMAGE_NAME}:${TAG}"
+11 -3
View File
@@ -23,6 +23,7 @@ env:
DOCKER_IMAGE_NAME: ${{ fromJson(inputs.env_json).DOCKER_IMAGE_NAME || '' }} DOCKER_IMAGE_NAME: ${{ fromJson(inputs.env_json).DOCKER_IMAGE_NAME || '' }}
DOCKER_UI_URL: ${{ fromJson(inputs.env_json).DOCKER_UI_URL || '' }} DOCKER_UI_URL: ${{ fromJson(inputs.env_json).DOCKER_UI_URL || '' }}
DOCKERFILE: ${{ fromJson(inputs.env_json).DOCKERFILE || 'Dockerfile' }} DOCKERFILE: ${{ fromJson(inputs.env_json).DOCKERFILE || 'Dockerfile' }}
GIT_TAG_PREFIX: ${{ fromJson(inputs.env_json).GIT_TAG_PREFIX || '' }}
VERSION: ${{ inputs.version }} VERSION: ${{ inputs.version }}
concurrency: concurrency:
@@ -50,7 +51,8 @@ jobs:
--label "git.commitBy=${{ github.actor }}" \ --label "git.commitBy=${{ github.actor }}" \
--label "build.date=${NOW}" \ --label "build.date=${NOW}" \
-f "${DOCKERFILE}" \ -f "${DOCKERFILE}" \
-t "${DOCKER_IMAGE_NAME}:${VERSION}" . -t "${DOCKER_IMAGE_NAME}:${VERSION}" \
-t "${DOCKER_IMAGE_NAME}:latest" .
REGISTRY="${DOCKER_REGISTRY:?DOCKER_REGISTRY not set in env.conf}" REGISTRY="${DOCKER_REGISTRY:?DOCKER_REGISTRY not set in env.conf}"
IMAGE="${DOCKER_IMAGE_NAME:?DOCKER_IMAGE_NAME not set in env.conf}" IMAGE="${DOCKER_IMAGE_NAME:?DOCKER_IMAGE_NAME not set in env.conf}"
@@ -62,6 +64,12 @@ jobs:
docker tag "${DOCKER_IMAGE_NAME}:${VERSION}" "$FULL_IMAGE" docker tag "${DOCKER_IMAGE_NAME}:${VERSION}" "$FULL_IMAGE"
echo "$DOCKER_PASSWORD" | docker login "$REGISTRY_HOST" -u "$DOCKER_USERNAME" --password-stdin echo "$DOCKER_PASSWORD" | docker login "$REGISTRY_HOST" -u "$DOCKER_USERNAME" --password-stdin
docker push "$FULL_IMAGE" 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" docker logout "$REGISTRY_HOST"
- name: Report status SUCCESS - name: Report status SUCCESS
@@ -69,7 +77,7 @@ jobs:
run: | run: |
CONTAINER_URL="" CONTAINER_URL=""
if [ -n "${DOCKER_UI_URL:-}" ] && [ -n "${VERSION:-}" ]; then if [ -n "${DOCKER_UI_URL:-}" ] && [ -n "${VERSION:-}" ]; then
CONTAINER_URL="${DOCKER_UI_URL}/${VERSION}" CONTAINER_URL="${DOCKER_UI_URL}/${DOCKER_IMAGE_NAME}/${VERSION}"
fi fi
bash .ci/scripts/report-status.sh success "Docker build & push ${VERSION} OK" ci-docker-build-push "" "$CONTAINER_URL" bash .ci/scripts/report-status.sh success "Docker build & push ${VERSION} OK" ci-docker-build-push "" "$CONTAINER_URL"
@@ -94,7 +102,7 @@ jobs:
"$SERVER_URL/api/v1/repos/${{ github.repository }}/tags" \ "$SERVER_URL/api/v1/repos/${{ github.repository }}/tags" \
-H "Authorization: token $GITEA_TOKEN" \ -H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \ -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 if [ "$HTTP_CODE" = "201" ] || [ "$HTTP_CODE" = "409" ]; then
exit 0 exit 0
+30 -10
View File
@@ -1,21 +1,41 @@
name: Build CI Cucumber Container (Manual) name: CI Container Build Cucumber
on: workflow_dispatch 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: jobs:
load-config: load-config:
name: Load config uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
uses: niko/gitea-ci-library/.gitea/workflows/config-provider.yml@main
secrets: inherit secrets: inherit
with: with:
config_path: .gitea/workflows/example-gitea-env.conf config_path: ${{ inputs.config_path }}
build-push: build-push:
name: Build & Push
needs: [load-config] needs: [load-config]
uses: niko/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@main uses: niko/gitea-ci-library/.gitea/workflows/ci-container-build-push.yml@v1
secrets: inherit secrets: inherit
with: with:
env_json: ${{ needs.load-config.outputs.env_json }} env_json: ${{ needs.load-config.outputs.env_json }}
dockerfile_path: Dockerfile.ci-cucumber dockerfile_path: ${{ inputs.dockerfile_path }}
image_name: ci-cucumber image_name: ${{ inputs.image_name }}
tag: latest tag: ${{ inputs.tag }}
+1 -1
View File
@@ -2,5 +2,5 @@ GITEA_API_URL=https://gitea.app.keskikuja.site
GIT_PAGES_URL=https://ci-reports.helm-dev.keskikuja.site GIT_PAGES_URL=https://ci-reports.helm-dev.keskikuja.site
DOCKER_REGISTRY=gitea.app.keskikuja.site/niko DOCKER_REGISTRY=gitea.app.keskikuja.site/niko
DOCKER_IMAGE_NAME=gitea-ci-library-test-image 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 #DOCKERFILE=Dockerfile.platform
+1
View File
@@ -7,3 +7,4 @@ tmp/
coverage/ coverage/
.DS_Store .DS_Store
reports/ reports/
.vscode/
+6 -1
View File
@@ -2,7 +2,12 @@
Reusable workflow -kirjasto Gitea Actionsille. Lisätietoja: [docs/](docs/) Reusable workflow -kirjasto Gitea Actionsille. Lisätietoja: [docs/](docs/)
**Consumer-käyttöönotto:** [docs/consumer-guide.md](docs/consumer-guide.md) — vaiheittainen ohje uuden projektin liittämiseen **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 ## Provider-binding — miten consumer löytää providerin
+5 -1
View File
@@ -26,21 +26,25 @@ kuuluu `git-pages/docs/`-alle, ei juuren `docs/`-kansioon.
| `.gitea/workflows/config-provider.yml` | Provider: lataa + validoi config-tiedoston, tuottaa `env_json` | | `.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/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/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) | | `.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` | | `scripts/` | Provider-skriptit: `report-status.sh`, `publish-git-pages.sh`, `ci-validate.sh` |
| `.gitea/scripts/` | **Consumer-skriptit**: `bats-coverage.sh`, `bats-report.sh` | | `.gitea/scripts/` | **Consumer-skriptit**: `bats-coverage.sh`, `bats-report.sh` |
| `docs/` | Arkkitehtuuri, ADRt (00040008) | | `docs/` | Arkkitehtuuri, ADRt (00040008) |
| `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 | | `docs/adr/` | Architecture Decision Records |
| `git-pages/` | Raporttien hostaus (Helm-chartti) | | `git-pages/` | Raporttien hostaus (Helm-chartti) |
| `tests/` | Bats-testit skripteille | | `tests/` | Bats-testit skripteille |
### Provider workflowt (4 kpl) ### Provider workflowt (5 kpl)
| Workflow | Input | Output | Kuvaus | | Workflow | Input | Output | Kuvaus |
|---|---|---|---| |---|---|---|---|
| `config-provider.yml` | `config_path` | `env_json`, `config_path` | Validoi ja jäsentää `.conf` → JSON. Sama kutsu hoitaa validoinnin. | | `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. | | `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. | | `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+) | | `report-summary.yml` | `env_json`, `suites` | — | Generoi `GITHUB_STEP_SUMMARY`-taulukon raporttilinkeillä (Gitea 1.27+) |
### Example-tiedostot (consumer-referenssi) ### Example-tiedostot (consumer-referenssi)
-446
View File
@@ -1,446 +0,0 @@
# Consumer Guide — Kirjaston käyttöönotto
> Anna tämä dokumentti AI:lle kun haluat ottaa `gitea-ci-library`:n käyttöön
> uudessa projektissa tai muokata olemassa olevia pipelineja.
---
## Rakenneperiaate
**Pipeline-tiedostot (`ci-feature.yml`, `ci-main.yml`) eivät saa sisältää
varsinaista logiikkaa.** Ne ovat puhtaita reitittimiä: pelkkiä `uses:`-kutsuja
`if`- ja `needs`-ehdoilla. Kaikki testien ajaminen, buildaus ja raportointi
kuuluu omiin `workflow_call`-tiedostoihinsa.
```
ci-unit-tests.yml ← testien ajaminen (varsinainen logiikka)
ci-acc-tests.yml ← hyväksymätestit (varsinainen logiikka)
ci-feature.yml ← reititin: load-config → test-workflow't → summary
ci-main.yml ← reititin: load-config → check-version → testit → build → summary
```
Provider tarjoaa 3 reusable workflow'ta ja joukon skriptejä.
Consumer omistaa orkestroinnin: mitä palikoita käytetään, missä järjestyksessä,
millä branch-ehdoilla. Consumer ei kopioi providerin koodia — se viittaa
`uses:`-direktiivillä.
---
## Vaihe 1: Konfiguraatiotiedosto
Luo `.gitea/workflows/gitea-env.conf`:
```ini
GITEA_API_URL=https://gitea.example.com
GIT_PAGES_URL=https://reports.example.com
```
Jos buildaat Docker-kontteja, lisää:
```ini
DOCKER_REGISTRY=gitea.example.com/myorg
DOCKER_IMAGE_NAME=my-service
DOCKER_UI_URL=https://gitea.example.com/myorg/-/packages/container/my-service
#DOCKERFILE=Dockerfile.platform # valinnainen, oletus Dockerfile
```
Salaisuudet määritellään Gitean Settings → Secrets -näkymässä:
| Secret | Pakollinen |
|---|---|
| `GITEA_TOKEN` | Aina |
| `GIT_PAGES_PUBLISH_TOKEN` | Aina |
| `DOCKER_USERNAME` | Vain jos buildaat kontteja (ei pakollinen kaikissa registryissä) |
| `DOCKER_PASSWORD` | Vain jos buildaat kontteja |
---
## Vaihe 2: Test-workflow't (varsinainen logiikka)
Jokainen testityyppi omaan `workflow_call`-tiedostoonsa. Tässä esimerkki
Maven-yksikkötesteistä. Luo `.gitea/workflows/ci-unit-tests.yml`:
```yaml
name: Unit Tests
on:
workflow_call:
inputs:
env_json:
required: true
type: string
secrets:
GITEA_TOKEN:
required: true
GIT_PAGES_PUBLISH_TOKEN:
required: true
env:
GITEA_API_URL: ${{ fromJson(inputs.env_json).GITEA_API_URL }}
GIT_PAGES_URL: ${{ fromJson(inputs.env_json).GIT_PAGES_URL }}
GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}
GIT_PAGES_PUBLISH_TOKEN: ${{ secrets.GIT_PAGES_PUBLISH_TOKEN }}
jobs:
test:
runs-on: ubuntu-latest
container: maven:3.9-eclipse-temurin-21
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v4
with:
repository: org/gitea-ci-library
path: .ci
- name: Run tests
shell: bash
run: |
mvn test
EXIT=$?
echo "EXIT=${EXIT}" >> "${GITHUB_ENV}"
exit ${EXIT}
- name: Publish reports
if: always()
run: bash .ci/scripts/publish-git-pages.sh junit
- name: Report status
if: always()
shell: bash
run: |
if [ "${EXIT}" = "0" ]; then
bash .ci/scripts/report-status.sh success "Link to JUnit reports" unit-tests junit
else
bash .ci/scripts/report-status.sh failure "Link to JUnit reports" unit-tests junit
fi
```
Hyväksymätesteille vastaava tiedosto `ci-acc-tests.yml` (Cucumber, Playwright
tms.), jossa oma `container:`, oma testikomento ja oma `suite`-nimi.
**Tärkeää:** `mvn test` korvataan omalla testikomennolla. `container:` ja
`publish-git-pages.sh`-suite ovat projektikohtaisia. Muu runko pysyy samana.
---
## Vaihe 3: Feature-haaran CI (puhdas reititin)
Luo `.gitea/workflows/ci-feature.yml`. **Ei sisällä yhtään `run:`-steppiä**
— pelkkiä `uses:`-kutsuja:
```yaml
name: CI Feature
on:
push:
branches-ignore:
- main
workflow_dispatch:
jobs:
load-config:
uses: org/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
secrets: inherit
with:
config_path: .gitea/workflows/gitea-env.conf
unit-tests:
needs: [load-config]
uses: ./.gitea/workflows/ci-unit-tests.yml@main
secrets: inherit
with:
env_json: ${{ needs.load-config.outputs.env_json }}
acc-tests:
needs: [load-config]
uses: ./.gitea/workflows/ci-acc-tests.yml@main
secrets: inherit
with:
env_json: ${{ needs.load-config.outputs.env_json }}
report-summary:
needs: [load-config, unit-tests, acc-tests]
if: always()
uses: org/gitea-ci-library/.gitea/workflows/report-summary.yml@v1
with:
env_json: ${{ needs.load-config.outputs.env_json }}
suites: junit cucumber
```
---
## Vaihe 4: Main-haaran CI (puhdas reititin)
Luo `.gitea/workflows/ci-main.yml`. **Ei sisällä yhtään `run:`-steppiä**:
```yaml
name: CI Main
on:
push:
branches:
- main
workflow_dispatch:
jobs:
load-config:
uses: org/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
secrets: inherit
with:
config_path: .gitea/workflows/gitea-env.conf
check-version:
needs: [load-config]
uses: org/gitea-ci-library/.gitea/workflows/check-version.yml@v1
secrets: inherit
with:
env_json: ${{ needs.load-config.outputs.env_json }}
unit-tests:
needs: [load-config, check-version]
if: needs.check-version.outputs.artifact_exists != 'true'
uses: ./.gitea/workflows/ci-unit-tests.yml@main
secrets: inherit
with:
env_json: ${{ needs.load-config.outputs.env_json }}
acc-tests:
needs: [load-config, check-version]
if: needs.check-version.outputs.artifact_exists != 'true'
uses: ./.gitea/workflows/ci-acc-tests.yml@main
secrets: inherit
with:
env_json: ${{ needs.load-config.outputs.env_json }}
build-push:
needs: [load-config, check-version, unit-tests, acc-tests]
if: needs.check-version.outputs.artifact_exists != 'true'
uses: org/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 }}
report-summary:
needs: [load-config, unit-tests, acc-tests]
if: always()
uses: org/gitea-ci-library/.gitea/workflows/report-summary.yml@v1
with:
env_json: ${{ needs.load-config.outputs.env_json }}
suites: junit cucumber
```
Mihin kiinnittää huomiota:
- `check-version` on **idempotentti** — jos commitilla on jo tagi, kaikki
sen jälkeiset jobit skipataan (`if: artifact_exists != 'true'`)
- `needs`-ketju takaa järjestyksen ja virheiden propagointin
- Artifakti voi olla **mitä tahansa**`docker-build-push.yml` on yksi
esimerkki. Voit korvata sen Maven-deploylla, npm-publishilla, tai millä
tahansa omalla build-workflow'lla. Rajapinta on `version`-input.
---
## Versionhallinta
`check-version.yml` lukee version automaattisesti prioriteettijärjestyksessä:
| # | Lähde | Formaatti | Esimerkki |
|---|---|---|---|
| 1 | `VERSION`-tiedosto | Plain text | `0.2` |
| 2 | `package.json` | `.version` | `"version": "0.2.0"` |
| 3 | `pom.xml` | `<version>` | `<version>0.2.0</version>` |
`major.minor` otetaan tästä. Patch (kolmas numero) lasketaan automaattisesti
git-tageista. Esim. jos `VERSION` on `0.2` ja tagit ovat `0.2.0`, `0.2.1`,
niin seuraava on `0.2.2`.
---
## Testien lisääminen — oma työkalu
Kopioi `ci-unit-tests.yml`:n rakenne uudelle testityypille ja muuta:
- `container:` — oma testikonttisi
- Testikomento — oma testityökalusi (`npm test`, `pytest`, `go test`, ...)
- `publish-git-pages.sh <suite>` — oma suite-nimi
- `report-status.sh ... <context> <suite>` — oma uniikki konteksti
Lisää uusi jobi reititintiedostoihin (`ci-feature.yml`, `ci-main.yml`)
samalla `uses:`-kaavalla.
Testijobit ajetaan rinnakkain — ne kaikki `needs: [load-config]` ilman
keskinäisiä riippuvuuksia.
### Tärkeimmät säännöt
1. **Exit-koodi aina ylös:**
```bash
run-tests
EXIT=$?
echo "EXIT=${EXIT}" >> "${GITHUB_ENV}"
exit ${EXIT}
```
2. **Ei pipeä testikomennon perään.** `command | tee file` syö exit-koodin.
Käytä `command > file 2>&1` jos haluat logit talteen.
3. **Status vain jos on raportti.** Testijobit käyttävät commit-status API:a
raporttilinkin takia. Tool-jobit luottavat Gitean natiiviin job-statukseen.
4. **`if: always()`** publish- ja status-stepeissä — raportti julkaistaan
ja status asetetaan vaikka testit feilaisivat.
### Raporttien generointi
`publish-git-pages.sh <suite>` odottaa hakemiston `reports/${SHA8}/<suite>/`
olevan olemassa. Sen sisältö sellaisenaan julkaistaan git-pagesiin.
`report-status.sh` linkittää statuksen suoraan tähän hakemistoon — selain
avaa sieltä `index.html`:n.
Test-workflow'n vastuulla on tuottaa raportit oikeaan polkuun. Kaksi
tyypillistä patternia:
**Pattern 1: Yksi raporttitiedosto (Cucumber)**
Testityökalu tuottaa suoraan HTML-raportin. Yksinkertaisin tapaus:
```bash
mkdir -p "reports/${GITHUB_SHA:0:8}/cucumber"
npx cucumber-js \
--format html:"reports/${GITHUB_SHA:0:8}/cucumber/index.html"
```
**Pattern 2: Monta raporttitiedostoa (Bats + coverage)**
Eri työkalut tuottavat eri tiedostoja. Generoi `index.html` joka linkittää
ne yhteen:
```
reports/${SHA8}/bats/
├── index.html ← generoitu: linkit alla oleviin
├── results.txt ← bats-testien stdout
├── coverage/ ← bashcov-coverage HTML
│ └── index.html
└── ...
```
```bash
mkdir -p "reports/${GITHUB_SHA:0:8}/bats"
# Aja testit → results.txt
bats tests/ > "reports/${GITHUB_SHA:0:8}/bats/results.txt" 2>&1
# Generoi coverage → coverage-hakemisto
bashcov -- bats tests/
# Generoi index.html joka linkittää kaikkiin raportteihin
cat > "reports/${GITHUB_SHA:0:8}/bats/index.html" <<'EOF'
<!DOCTYPE html>
<html><body>
<h1>Bats Test Reports</h1>
<ul>
<li><a href="results.txt">Test results (raw)</a></li>
<li><a href="coverage/index.html">Code coverage</a></li>
</ul>
</body></html>
EOF
```
Yhteistä molemmille: `publish-git-pages.sh <suite>`-kutsun jälkeen raportit
ovat julkisesti selailtavissa. `report-status.sh`-kutsu `suite`-parametrilla
linkittää commit-statuksen suoraan `index.html`:ään.
Jos testit feilasivat, raportti generoidaan silti — se kertoo MITKÄ testit
feilasivat. Siksi publish- ja status-stepit käyttävät `if: always()`.
---
## Branch protection (PR-gate)
Gitean Settings → Branches → Add Rule:
- **Branch:** `main`
- **Enable Require Status Checks:** päälle
- **Status checks:** valitse `unit-tests`, `acc-tests`
---
## Raporttien koonti (Gitea 1.27+)
Kun Gitea päivittyy versioon 1.27, `GITHUB_STEP_SUMMARY`-tuki mahdollistaa
raporttilinkkien koontinäkymän suoraan Gitea UI:ssa. `report-summary`-jobi
on mukana molemmissa reititinesimerkeissä yllä — forward-compatibeli, ei
hajota vanhemmilla versioilla.
---
## 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 |
| `report-summary.yml` | `GITHUB_STEP_SUMMARY`-taulukko raporttilinkeillä |
### Skriptit (kutsutaan `.ci/scripts/`-polun kautta)
| Skripti | Käyttötarkoitus |
|---|---|
| `report-status.sh` | POSTaa commit-statuksen linkillä |
| `publish-git-pages.sh` | Julkaisee raporttihakemiston git-pagesiin |
| `ci-validate.sh` | Validoi `.conf`-tiedoston (kutsutaan `config-provider.yml`:stä) |
---
## ADR-yhteenveto — consumerin kannalta oleelliset säännöt
Nämä säännöt on formalisoitu [docs/adr/](docs/adr/)-hakemistossa. Tässä tiivistelmä
consumer-näkökulmasta:
### Reititin ei sisällä suorittavaa koodia (ADR 0010)
`ci-feature.yml` ja `ci-main.yml` ovat **puhtaita reitittimiä**:
- **Vain** `uses:`, `needs:` ja `if:` sallittu
- **Ei** `run:`-komentoja, ei inline-skriptejä, ei `actions/checkout`
Kaikki suorittava koodi on omissa `workflow_call`-tiedostoissaan:
- `ci-unit-tests.yml` — testikomento, publish, status
- `ci-acc-tests.yml` — testikomento, publish, status
- Provider-workflowt (`config-provider.yml`, `check-version.yml`, …)
### Yksi steppi = yksi workflow_call-tiedosto
Jokainen pipeline-steppi (testityyppi, build, deploy) on oma tiedostonsa.
Ei kahta eri komentoa samassa workflow'ssa. Tämä pitää reitittimet ohuina
ja steppitiedostot itsenäisinä — testattavissa erikseen.
### Provider-versio on `@v1` (ADR 0009)
Kaikki `org/gitea-ci-library/…`-viittaukset käyttävät `@v1`-tagia:
```yaml
uses: org/gitea-ci-library/.gitea/workflows/config-provider.yml@v1
```
`@main` on vain providerin oman repon sisäiseen dogfood-käyttöön.
Breaking changet on kielletty — `v1`-rajapinta on pysyvä.
### Exit-koodi on ainoa onnistumisen mittari (ADR 0008)
Älä käytä pipeä (`|`) komennon perässä — se syö exit-koodin.
Käytä redirectiä (`> file 2>&1`) jos haluat logit talteen.
### Commit-status vain raporttilinkille (ADR 0007)
`report-status.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ä. Consumer käyttää
providerin määrittelemää polkua (`.ci/scripts/`). Consumer ei kopioi eikä
muokkaa providerin tiedostoja.
### Testattavuus
Jokainen `workflow_call`-tiedosto on testattavissa itsenäisesti — consumer
voi ajaa `ci-unit-tests.yml`:n paikallisesti act:lla tai Gitean
`workflow_dispatch`:llä ilman koko pipelineä.
+149
View File
@@ -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
+508
View File
@@ -0,0 +1,508 @@
---
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
Jokainen testi kaappaa komentonsa exit-koodin eksplisiittisesti:
```yaml
- name: Run tests
shell: bash
run: |
<testikomento> > results.txt 2>&1
EXIT=$?
echo "EXIT=${EXIT}" >> "${GITHUB_ENV}"
exit ${EXIT}
```
**Miksi ei pipeä (`| tee`):**
```bash
# VÄÄRIN — pipe syö exit-koodin
<komento> | tee results.txt
# OIKEIN — redirect tiedostoon
<komento> > results.txt 2>&1
```
Ilman `EXIT=$?` + `exit ${EXIT}` komento voi feilata mutta job menee läpi vihreänä — `container:`-modessa
shellin käyttäytyminen vaihtelee.
## 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
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
CI-kontin voi ajaa joko `container:`-direktiivillä (kaikki stepit kontissa)
tai `docker run --rm`:llä stepin sisällä (checkout natiivisti). Molemmat tavat
toimivat.
```yaml
# Tapa A: container:-direktiivi
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/${GITHUB_SHA:0:8}/<suite>"
<komento> > "reports/${GITHUB_SHA:0:8}/<suite>/results.txt" 2>&1
EXIT=$?
echo "EXIT=${EXIT}" >> "${GITHUB_ENV}"
exit ${EXIT}
```
```yaml
# Tapa B: docker run --rm stepin sisällä (kuten example-bats-tests.yml)
jobs:
<työkalu>:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@v4
with:
repository: <owner>/gitea-ci-library
path: .ci
- name: Run <työkalu>
shell: bash
run: |
docker volume create ws-<suite>
tar c . | docker run --rm -i -v ws-<suite>:/data alpine tar x -C /data
mkdir -p "reports/${GITHUB_SHA:0:8}/<suite>"
set +e
docker run --rm \
-v ws-<suite>:/data \
--entrypoint bash ${{ inputs.<image-name> }} \
-c 'cd /data && <komento>' \
> "reports/${GITHUB_SHA:0:8}/<suite>/results.txt" 2>&1
EXIT=$?
docker volume rm ws-<suite> > /dev/null 2>&1
echo "EXIT=${EXIT}" >> "${GITHUB_ENV}"
exit ${EXIT}
- name: Publish <suite> reports
if: always()
run: bash .ci/scripts/publish-git-pages.sh <suite>
- name: Report status
if: always()
run: |
if [ "${EXIT}" = "0" ]; then
bash .ci/scripts/report-status.sh success "<kuvaus>" <context> <suite>
else
bash .ci/scripts/report-status.sh failure "<kuvaus>" <context> <suite>
fi
```
**Malli:** `example-bats-tests.yml` (tapa B).
## 5. Raporttitasot
Testi tuottaa raportin `reports/${GITHUB_SHA:0:8}/<suite>/`-hakemistoon. `publish-git-pages.sh` julkaisee sen,
`report-status.sh` linkittää commit-statusin siihen. Molemmat `if: always()`.
### Taso 1: Pelkkä teksti
Kun testi tuottaa vain stdout/stderr — tallennetaan `results.txt`:
```yaml
- name: Run tests
shell: bash
run: |
mkdir -p "reports/${GITHUB_SHA:0:8}/<suite>"
<testikomento> > "reports/${GITHUB_SHA:0:8}/<suite>/results.txt" 2>&1
EXIT=$?
echo "EXIT=${EXIT}" >> "${GITHUB_ENV}"
exit ${EXIT}
- name: Publish reports
if: always()
shell: bash
run: bash .ci/scripts/publish-git-pages.sh <suite>
- name: Report status
if: always()
shell: bash
run: |
if [ "${EXIT}" = "0" ]; then
bash .ci/scripts/report-status.sh success "<kuvaus>" <context> <suite>
else
bash .ci/scripts/report-status.sh failure "<kuvaus>" <context> <suite>
fi
```
### Taso 2: HTML-raportti
Kun testi tuottaa strukturoitua dataa (JUnit XML, coverage, tms.) — generoidaan HTML ja `index.html`:
```
reports/<sha8>/<suite>/
├── index.html ← generoitu: linkit alla oleviin
├── results.txt ← testin stdout
├── junit.xml ← testin JUnit XML -output
└── junit.html ← generoitu HTML (xsltproc, tms.)
```
`index.html` linkittää kaikkiin raporttitiedostoihin. Selain avaa sen ja navigoi sieltä
yksittäisiin raportteihin.
## 6. 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.
## 7. 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 |
|---|---|
| `report-status.sh` | POSTaa commit-statuksen linkillä |
| `publish-git-pages.sh` | Julkaisee raporttihakemiston git-pagesiin |
| `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)
`report-status.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'); const MOCK_SCRIPT = path.join(PROJECT_ROOT, 'tests', 'helpers', 'mock-api.sh');
Before({ tags: '@mock' }, function () { 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, cwd: PROJECT_ROOT,
encoding: 'utf-8', encoding: 'utf-8',
stdio: ['pipe', 'pipe', 'pipe'], stdio: ['pipe', 'pipe', 'pipe'],
+9 -1
View File
@@ -24,6 +24,14 @@ _wait_port_free() {
done 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_set_sequence() {
MOCK_SEQUENCE_FILE=$(mktemp) MOCK_SEQUENCE_FILE=$(mktemp)
echo "$1" | jq -c '.' > "$MOCK_SEQUENCE_FILE" 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" \ nohup python3 "$(dirname "${BASH_SOURCE[0]}")/mock-server.py" "$MOCK_PORT" "$MOCK_CONFIG_FILE" "$MOCK_REQUEST_FILE" \
</dev/null >/dev/null 2>&1 & </dev/null >/dev/null 2>&1 &
MOCK_PID=$! MOCK_PID=$!
sleep 0.5 _wait_port_ready
} }
mock_stop() { mock_stop() {