From 9a59cbc185166bf24eecb0d3bf0eddc613b9ea19 Mon Sep 17 00:00:00 2001 From: moilanik Date: Mon, 8 Jun 2026 09:34:47 +0300 Subject: [PATCH] tiketit ja featuret vaihe 1 --- .gitea/workflows/ci.yml | 33 ++++ docs/tickets/0001-report-status-sh.md | 110 +++++++++++++ docs/tickets/0002-dispatch-workflow-sh.md | 95 ++++++++++++ docs/tickets/0003-push-reports-sh.md | 104 +++++++++++++ docs/tickets/0004-tag-commit-sh.md | 98 ++++++++++++ .../0005-report-service-index-generation.md | 112 ++++++++++++++ docs/tickets/0006-ci-feature-yml.md | 108 +++++++++++++ docs/tickets/0007-deploy-yml.md | 112 ++++++++++++++ docs/tickets/0008-test-yml.md | 117 ++++++++++++++ docs/tickets/0009-ci-master-yml.md | 144 ++++++++++++++++++ .../0010-report-service-retention-cronjob.md | 130 ++++++++++++++++ docs/tickets/0011-check-version-sh.md | 103 +++++++++++++ docs/tickets/0012-integration-testing.md | 45 ++++++ tests/features/ci-pipeline.feature | 70 +++++++++ tests/features/commit-status.feature | 72 +++++++++ tests/features/deployment.feature | 45 ++++++ tests/features/report-browsing.feature | 76 +++++++++ tests/features/test-execution.feature | 92 +++++++++++ 18 files changed, 1666 insertions(+) create mode 100644 .gitea/workflows/ci.yml create mode 100644 docs/tickets/0001-report-status-sh.md create mode 100644 docs/tickets/0002-dispatch-workflow-sh.md create mode 100644 docs/tickets/0003-push-reports-sh.md create mode 100644 docs/tickets/0004-tag-commit-sh.md create mode 100644 docs/tickets/0005-report-service-index-generation.md create mode 100644 docs/tickets/0006-ci-feature-yml.md create mode 100644 docs/tickets/0007-deploy-yml.md create mode 100644 docs/tickets/0008-test-yml.md create mode 100644 docs/tickets/0009-ci-master-yml.md create mode 100644 docs/tickets/0010-report-service-retention-cronjob.md create mode 100644 docs/tickets/0011-check-version-sh.md create mode 100644 docs/tickets/0012-integration-testing.md create mode 100644 tests/features/ci-pipeline.feature create mode 100644 tests/features/commit-status.feature create mode 100644 tests/features/deployment.feature create mode 100644 tests/features/report-browsing.feature create mode 100644 tests/features/test-execution.feature diff --git a/.gitea/workflows/ci.yml b/.gitea/workflows/ci.yml new file mode 100644 index 0000000..a93f88b --- /dev/null +++ b/.gitea/workflows/ci.yml @@ -0,0 +1,33 @@ +# .gitea/workflows/ci.yml — Kirjaston oma CI (eat your own dogfood) +# +# Tämä workflow on kirjaston ENSIMMÄINEN kuluttaja. +# Jokainen push ajaa kirjaston omat reusable workflowt: +# - feature-branch → ci-feature.yml +# - master-branch → ci-master.yml +# +# Näin kirjasto testaa itse itsensä — sama mekanismi +# kuin mitä mikropalvelut käyttävät. + +name: CI — gitea-ci-library + +on: + push: + branches: ["**"] + workflow_dispatch: + +jobs: + # --- Feature-branch: testit + raportit, ei konttia --- + feature: + if: github.ref != 'refs/heads/master' + uses: ./.gitea/workflows/ci-feature.yml + secrets: inherit + with: + config-file: ci-flow-values.yaml + + # --- Master-branch: build + kontti + test flow --- + master: + if: github.ref == 'refs/heads/master' + uses: ./.gitea/workflows/ci-master.yml + secrets: inherit + with: + config-file: ci-flow-values.yaml diff --git a/docs/tickets/0001-report-status-sh.md b/docs/tickets/0001-report-status-sh.md new file mode 100644 index 0000000..fefd1e9 --- /dev/null +++ b/docs/tickets/0001-report-status-sh.md @@ -0,0 +1,110 @@ +# Ticket 0001: `report-status.sh` + +**Vaihe:** 1/12 +**Status:** pending +**Feature branch:** `feature/0001-report-status-sh` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0001-report-status.feature` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/report-status.bats` ennen implementaatiota. Testi käyttää `tests/helpers/mock-api.sh` mock-Gitea API:a. Varmista: +- `pending`-status POSTautuu oikein +- `success`-status + `url` + `key` +- `failure`-status +- Cross-repo: `root_commit` + `root_repo` → status menee root-committiin +- Virhetilanne: API palauttaa 500 → exit 1 +- Puuttuva `GITEA_API_URL` → exit 1 + virheviesti + +```bash +bats tests/report-status.bats +# Kaikki testit FAIL: skriptiä ei ole vielä +``` + +### Green +Toteuta `scripts/report-status.sh`. Minimiversio: vain curl POST + virheenkäsittely. + +```bash +bats tests/report-status.bats +# Kaikki testit PASS +``` + +### Refactor +Poista duplikaatio, paranna virheviestejä. Testit pysyvät vihreänä. + +## DoD (Definition of Done) +- [ ] Cucumber: `@ticket-0001 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/report-status.bats` kaikki testit menevät läpi +- [ ] `tests/helpers/mock-api.sh` palvelee mock-vastaukset +- [ ] `scripts/report-status.sh` toteuttaa kaikki parametrit +- [ ] Cross-repo-statusraportointi toimii + +--- + +## Toiminto + +POSTaa build-statuksen Gitea REST APIin. Jokainen workflow-steppi kutsuu tätä skriptiä raportoidakseen tilansa Git-committiin. + +## Rajapinta + +```bash +report-status.sh [key] [root_commit] [root_repo] +``` + +| Parametri | Pakollinen | Kuvaus | +|-----------|------------|--------| +| `state` | Kyllä | `pending`, `success`, `failure`, `error` | +| `description` | Kyllä | Ihmisluettava kuvaus | +| `url` | Kyllä | Linkki buildiin tai raporttiin | +| `key` | Ei | Uniikki avain. Oletus: `commit-{sha_short}` | +| `root_commit` | Ei | Root-buildin commit (cross-repo-raportointi) | +| `root_repo` | Ei | Root-buildin repo (cross-repo-raportointi) | + +## Gitea API -kutsu + +``` +POST /api/v1/repos/{owner}/{repo}/statuses/{sha} +Authorization: token {GITEA_TOKEN} + +{ + "state": "{state}", + "target_url": "{url}", + "description": "{description}", + "context": "{key}" +} +``` + +## Ympäristömuuttujat + +- `GITEA_API_URL` — Org variable +- `GITEA_TOKEN` — Org secret +- `GITHUB_REPOSITORY` — Automaattinen +- `GITHUB_SHA` — Automaattinen +- `GITHUB_SERVER_URL` — Automaattinen +- `GITHUB_RUN_ID` — Automaattinen + +## Verifiointi + +`bash scripts/report-status.sh success "Test OK" "https://example.com"` → mock-API palauttaa 201 + +Kutsu cross-repo-parametreilla: + +```bash +report-status.sh success "Deployed to staging" "https://gitea.example.com/helm-repo/commit/def456" "deploy-staging" "abc123" "services/temperature-store" +``` + +→ statusviesti ilmestyy root-committiin `abc123` + +## Viitteet + +- `docs/shared-scripts.md` — Rajapinnan määrittely +- `docs/architecture.md` — Tietovuo 1: Commit-statusraportointi +- `docs/design-rationale.md` — Periaate 1: Git-commit on universaali statusnäkymä diff --git a/docs/tickets/0002-dispatch-workflow-sh.md b/docs/tickets/0002-dispatch-workflow-sh.md new file mode 100644 index 0000000..2397586 --- /dev/null +++ b/docs/tickets/0002-dispatch-workflow-sh.md @@ -0,0 +1,95 @@ +# Ticket 0002: `dispatch-workflow.sh` + +**Vaihe:** 2/12 +**Status:** pending +**Feature branch:** `feature/0002-dispatch-workflow-sh` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0002-dispatch-workflow.feature` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/dispatch-workflow.bats` mock-Gitea API:a vasten: +- Dispatch → API palauttaa 201 +- Poll: API palauttaa `running` 3 kertaa, sitten `completed` + `success` → exit 0 +- Poll: API palauttaa `completed` + `failure` → exit 1 +- Timeout: ylittää `timeout_minutes` → exit 124 +- Virheellinen target_repo → exit 1 + +```bash +bats tests/dispatch-workflow.bats +# FAIL +``` + +### Green +`scripts/dispatch-workflow.sh` — dispatch + poll-silmukka 10s välein. + +```bash +bats tests/dispatch-workflow.bats +# PASS +``` + +### Refactor +Poista duplikaatio, tarkista edge caset. Testit vihreänä. + +## DoD +- [ ] Cucumber: `@ticket-0002 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/dispatch-workflow.bats` — kaikki testit läpi +- [ ] Dispatch, poll, ja timeout toimivat mock-API:a vasten +- [ ] Exit-koodit: 0 (success), 1 (failure), 124 (timeout) + +--- + +## Toiminto + +Dispatchaa workflow toisessa repossa ja pollaa sen valmistumista synkronisesti. Vastaa Jenkinsin `buildJob()`-semantiikkaa — kutsuja jää odottamaan kunnes dispatchattu workflow on valmis. + +## Rajapinta + +```bash +dispatch-workflow.sh [timeout_minutes] +``` + +| Parametri | Pakollinen | Kuvaus | +|-----------|------------|--------| +| `target_repo` | Kyllä | `owner/repo` | +| `workflow_file` | Kyllä | Workflow-tiedosto (esim. `test.yml`) | +| `ref` | Kyllä | Branch | +| `inputs_json` | Kyllä | JSON-objekti input-parametreina | +| `timeout_minutes` | Ei | Oletus: 360 | + +## API-kutsut + +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` +3. **Poll:** `GET /api/v1/repos/{target_repo}/actions/runs/{run_id}` (10s välein) +4. **Lopetus:** `conclusion == "success"` → exit 0, muuten exit 1 +5. **Timeout:** `> timeout_minutes` → exit 124 + +## Esimerkkikutsu + +```bash +dispatch-workflow.sh "tests/integration" "test.yml" "main" \ + '{"version":"1.2.3","tags":"@smoke","root_commit":"abc123","root_repo":"services/temperature-store"}' +``` + +## Verifiointi + +Mock-Gitea API, jossa: +- `POST dispatches` → palauttaa 201 +- `GET runs` → palauttaa `status: running` 3 kertaa, sitten `status: completed, conclusion: success` + +Skripti pollaa ja palauttaa exit 0. + +## Viitteet + +- `docs/shared-scripts.md` — Rajapinnan määrittely +- `docs/design-rationale.md` — Periaate 4: Deterministinen testigraafi +- `docs/architecture.md` — Tietovuo 4: Test flow -ketjutus diff --git a/docs/tickets/0003-push-reports-sh.md b/docs/tickets/0003-push-reports-sh.md new file mode 100644 index 0000000..65b25ac --- /dev/null +++ b/docs/tickets/0003-push-reports-sh.md @@ -0,0 +1,104 @@ +# Ticket 0003: `push-reports.sh` + +**Vaihe:** 3/12 +**Status:** pending +**Feature branch:** `feature/0003-push-reports-sh` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0003-push-reports.feature` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/push-reports.bats` mock-MinIO:a vasten: +- `mc cp --recursive` kopioi oikeaan polkuun +- URL-tulostus: `{MINIO_BASE}/{repo}/{commit_short}/{report_type}/index.html` +- Raporttityypit: `cucumber`, `jacoco`, `junit`, `site` +- `index_title`-parametri välittyy oikein +- Lähdehakemistoa ei ole → exit 1 + +```bash +bats tests/push-reports.bats +# FAIL +``` + +### Green +`scripts/push-reports.sh` — mc cp + URL-tulostus + indeksipäivitys (`report-service/generate-index.sh`). + +```bash +bats tests/push-reports.bats +# PASS +``` + +### Refactor +Poista duplikaatio, varmista mc-alias-konfigurointi. + +## DoD +- [ ] Cucumber: `@ticket-0003 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/push-reports.bats` — kaikki testit läpi +- [ ] Raportit kopioituvat oikeaan MinIO-polkuun +- [ ] URL-tulostus deterministinen +- [ ] Indeksisivut päivittyvät (`report-service/generate-index.sh`) + +--- + +## Toiminto + +Puskaa testiraporttihakemiston MinIO:hon ja päivittää indeksisivut. Palauttaa URL:n, joka syötetään `report-status.sh`:lle commit-statusviestin `url`-kenttään. + +## Rajapinta + +```bash +push-reports.sh [index_title] +``` + +| Parametri | Pakollinen | Kuvaus | +|-----------|------------|--------| +| `report_type` | Kyllä | `cucumber`, `jacoco`, `junit`, `site` | +| `source_dir` | Kyllä | Paikallinen hakemisto | +| `index_title` | Ei | Näkyvä nimi indeksisivulla | + +## Toiminta + +1. `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ä build on listalla +4. Tulosta URL: `{MINIO_BASE_URL}/{repo}/{commit_short}/{report_type}/index.html` + +## URL-rakenne + +``` +{MINIO_BASE}/{repo_slug}/{commit_short}/{report_type}/index.html +``` + +## Ympäristömuuttujat + +- `MINIO_BASE_URL` — Org variable +- `MINIO_ACCESS_KEY` — Org secret (alias: `mc`) +- `MINIO_SECRET_KEY` — Org secret (alias: `mc`) +- `GITHUB_REPOSITORY` — Automaattinen +- `GITHUB_SHA` — Automaattinen (8 merkkiä) + +## Verifiointi + +```bash +bash scripts/push-reports.sh cucumber target/cucumber-report "Cucumber Reports" +# → https://reports.example.com/temperature-store/abc12345/cucumber/overview-features.html +``` + +Tarkista: +- MinIO-bucketissa raportit oikeassa polussa +- `/reports/temperature-store/abc12345/index.html` sisältää linkin +- `/reports/temperature-store/index.html` sisältää buildin + +## Viitteet + +- `docs/shared-scripts.md` — Rajapinnan määrittely +- `docs/report-hosting.md` — MinIO-konfiguraatio ja URL-rakenne +- `docs/design-rationale.md` — Periaate 5: Raportit ovat selailtavia URL:n takana diff --git a/docs/tickets/0004-tag-commit-sh.md b/docs/tickets/0004-tag-commit-sh.md new file mode 100644 index 0000000..4bcd5ba --- /dev/null +++ b/docs/tickets/0004-tag-commit-sh.md @@ -0,0 +1,98 @@ +# Ticket 0004: `tag-commit.sh` + +**Vaihe:** 4/12 +**Status:** pending +**Feature branch:** `feature/0004-tag-commit-sh` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0004-tag-commit.feature` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/tag-commit.bats` mock-Gitea API:a vasten: +- `tag-commit.sh "1.2.3.42"` → POST `/api/v1/repos/{repo}/tags` palauttaa 201 +- Tagi-muoto sisältää `$GITHUB_RUN_NUMBER` +- API palauttaa 409 (tag jo olemassa) → exit 1 +- Tyhjä versio → exit 1 + +```bash +bats tests/tag-commit.bats +# FAIL +``` + +### Green +`scripts/tag-commit.sh` — curl POST + virheenkäsittely. + +```bash +bats tests/tag-commit.bats +# PASS +``` + +### Refactor +Varmista tagin oikeellisuus, virheilmoitukset. + +## DoD +- [ ] Cucumber: `@ticket-0004 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/tag-commit.bats` — kaikki testit läpi +- [ ] POST `/api/v1/repos/{repo}/tags` onnistuu +- [ ] Virhetilanteet käsitellään (409, tyhjä versio) + +--- + +## Toiminto + +Tagittaa commitin versiolla Gitea REST API:n kautta. Kutsutaan `ci-master.yml`:n docker-pushin onnistuttua. Tämän jälkeen `isContainerBuilt()` palauttaa `true` samalle commitille. + +## Rajapinta + +```bash +tag-commit.sh +``` + +## Gitea API -kutsu + +``` +POST /api/v1/repos/{owner}/{repo}/tags +Authorization: token {GITEA_TOKEN} + +{ + "tag_name": "{version}", + "message": "Build #{GITHUB_RUN_NUMBER}", + "target": "{GITHUB_SHA}" +} +``` + +## Kutsuesimerkki + +```bash +tag-commit.sh "1.2.3.$GITHUB_RUN_NUMBER" +``` + +## Ympäristömuuttujat + +- `GITEA_API_URL` — Org variable +- `GITEA_TOKEN` — Org secret +- `GITHUB_REPOSITORY` — Automaattinen +- `GITHUB_SHA` — Automaattinen +- `GITHUB_RUN_NUMBER` — Automaattinen + +## Verifiointi + +```bash +bash scripts/tag-commit.sh "1.2.3.42" +``` + +→ `git tag` näyttää tagin commitilla (tai mock-API palauttaa 201) + +## Viitteet + +- `docs/shared-scripts.md` — Rajapinnan määrittely +- `docs/config-model.md` — `isContainerBuild()`-mekanismi +- `docs/design-rationale.md` — Periaate 1: Statusviestit committiin diff --git a/docs/tickets/0005-report-service-index-generation.md b/docs/tickets/0005-report-service-index-generation.md new file mode 100644 index 0000000..0fea06e --- /dev/null +++ b/docs/tickets/0005-report-service-index-generation.md @@ -0,0 +1,112 @@ +# Ticket 0005: `report-service/` — indeksigenerointi + +**Vaihe:** 5/12 +**Status:** pending +**Feature branch:** `feature/0005-report-service-index-generation` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0005-report-index.feature` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/generate-index.bats`: +- Projektin indeksi: `generate-index.sh temperature-store abc12345 "2024-06-08 14:30" "master" "success"` → HTML sisältää rivin `abc12345` +- Buildin indeksi: sisältää linkit raportteihin + "Back to builds" +- Useampi build: uusin ensin listassa +- Status: `success` → ✅, `failure` → ❌ +- Tyhjä status → ei generoida riviä + +```bash +bats tests/generate-index.bats +# FAIL +``` + +### Green +`report-service/generate-index.sh` — staattinen HTML-generaattori. + +```bash +bats tests/generate-index.bats +# PASS +``` + +### Refactor +Varmista HTML-valiidius, edge-caset (puuttuvat parametrit). + +## DoD +- [ ] Cucumber: `@ticket-0005 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/generate-index.bats` — kaikki testit läpi +- [ ] Projektin indeksi lista buildit aikajärjestyksessä +- [ ] Buildin indeksi lista raportit linkkeinä +- [ ] "Back to builds" -navigaatio +- [ ] Status-emoji ✅/❌ + +--- + +## Toiminto + +Staattisten HTML-indeksisivujen generointi MinIO:hon. Kaksi tasoa: + +1. **Projektin build-indeksi** (`/reports/{repo}/index.html`): lista buildeista aikajärjestyksessä +2. **Buildin raportti-indeksi** (`/reports/{repo}/{commit_short}/index.html`): lista raporteista linkkeinä + +## Build-indeksin sisältö + +```html + + + + + {repo_slug} — Build Reports + + + +

{repo_slug}

+
    +
  • abc12345 — 2024-06-08 14:30 — master
  • +
  • def67890 — 2024-06-07 10:15 — feature/xyz
  • +
+ + +``` + +## Raportti-indeksin sisältö + +```html +← Back to builds +

Build abc12345

+ +``` + +## Sijainti + +- `report-service/generate-index.sh` — generoi tai päivittää indeksit +- Kutsutaan `push-reports.sh`:sta (Ticket 0003) + +## Verifiointi + +```bash +bash report-service/generate-index.sh temperature-store abc12345 "2024-06-08 14:30" "master" "success" +``` + +→ `/reports/temperature-store/index.html` sisältää rivin `abc12345` +→ `/reports/temperature-store/abc12345/index.html` validi HTML + +## Viitteet + +- `docs/report-hosting.md` — Indeksisivujen määrittely +- `docs/requirements.md` — UC3: Kehittäjä selaa projektin build-historiaa diff --git a/docs/tickets/0006-ci-feature-yml.md b/docs/tickets/0006-ci-feature-yml.md new file mode 100644 index 0000000..7cf264b --- /dev/null +++ b/docs/tickets/0006-ci-feature-yml.md @@ -0,0 +1,108 @@ +# Ticket 0006: `ci-feature.yml` (reusable workflow) + +**Vaihe:** 6/12 +**Status:** pending +**Feature branch:** `feature/0006-ci-feature-yml` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0006-ci-feature.feature` +- Skills: `tdd`, `implementation`, `clean-code` + +--- + +## TDD — Red-Green-Refactor + Dogfood + +### Red +Ennen workflow'ta, kirjoita validointitestit (`tests/workflows.bats`): +- YAML-skeema: kaikki vaaditut `inputs` määritelty +- `concurrency`-ryhmä estää rinnakkaiset ajot +- `uses:`-viittaukset oikeisiin skripteihin + +```bash +bats tests/workflows.bats +# FAIL: workflow-tiedostoa ei ole +``` + +### Green +Toteuta `gitea/workflows/ci-feature.yml`. + +```bash +bats tests/workflows.bats +# PASS: YAML validi, skeema täsmää +``` + +### Dogfood +Lisää kutsu `gitea/workflows/ci.yml`:stä: + +```yaml +feature: + if: github.ref != 'refs/heads/master' + uses: ./gitea/workflows/ci-feature.yml@main +``` + +Jokainen push feature-branchiin ajaa `ci-feature.yml`:n. + +## DoD +- [ ] Cucumber: `@ticket-0006 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/workflows.bats` — YAML-validointi läpi +- [ ] Kaikki stepit määritelty: start → unit-test → code-coverage → publish-html → end +- [ ] `concurrency` estää rinnakkaiset ajot samalle branchille +- [ ] Dogfood: kirjaston oma CI käyttää tätä workflow'ta +- [ ] Statusviestit raportoivat jokaisen stepin tilan + +--- + +## Toiminto + +Feature-branchin CI-workflow. Kutsuu `report-status.sh` ja `push-reports.sh` (Ticket 0001 ja 0003). + +## Trigger + +`workflow_call` (reusable workflow) + +## Inputs + +| Parametri | Pakollinen | Kuvaus | +|-----------|------------|--------| +| `config-file` | Kyllä | Polku `ci-flow-values.yaml`:aan | +| `maven-image` | Ei | Maven-kontti (esim. `maven:3.9-eclipse-temurin-21`) | +| `node-image` | Ei | Node-kontti (npm-projektit) | + +## Steppit + +``` +start → unit-test → code-coverage → publish-html → end +``` + +| Steppi | Skripti | Status | +|--------|---------|--------| +| `start` | `report-status.sh pending "Building..."` | INPROGRESS | +| `unit-test` | Projektin oma testiajo | — | +| `code-coverage` | JaCoCo / vastaava | — | +| `publish-html` | `push-reports.sh cucumber; push-reports.sh jacoco` | — | +| `end` | `report-status.sh success/failure` | Lopullinen status | +| `fail` (catch) | `report-status.sh failure` | FAILURE | + +## Concurrency + +```yaml +concurrency: + group: feature-${{ github.ref }} + cancel-in-progress: false +``` + +## Verifiointi + +Simuloi paikallisesti (act-runner tai manuaalinen steppien ajo): +1. `report-status.sh pending` → commitin status = pending +2. Testit ajetaan +3. `push-reports.sh` → raportit MinIO:ssa +4. `report-status.sh success` → statusviesti + URL + +## Viitteet + +- `docs/workflows.md` — `ci-feature.yml` — Feature-branch +- `docs/architecture.md` — Järjestelmäkaavio diff --git a/docs/tickets/0007-deploy-yml.md b/docs/tickets/0007-deploy-yml.md new file mode 100644 index 0000000..53ce3af --- /dev/null +++ b/docs/tickets/0007-deploy-yml.md @@ -0,0 +1,112 @@ +# Ticket 0007: `deploy.yml` (reusable workflow) + +**Vaihe:** 7/12 +**Status:** pending +**Feature branch:** `feature/0007-deploy-yml` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0007-deploy.feature` +- Skills: `tdd`, `implementation`, `clean-code` + +--- + +## TDD — Red-Green-Refactor + Dogfood + +### Red +Validointitesti (`tests/workflows.bats`): +- `workflow_dispatch`-inputit määritelty: `environment`, `version`, `root_commit`, `root_repo`, `root_build_url` +- YAML-päivityksen testi: `yq` muuttaa `container.version`-arvon +- Cross-repo-statusraportoinnin testi + +```bash +bats tests/workflows.bats +# FAIL +``` + +### Green +Toteuta `gitea/workflows/deploy.yml`. + +```bash +bats tests/workflows.bats +# PASS +``` + +### Dogfood +Lisää kutsu `gitea/workflows/ci.yml`:stä (käytetään master-flow'n test flow -ketjussa). + +## DoD +- [ ] Cucumber: `@ticket-0007 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/workflows.bats` — workflow-validointi läpi +- [ ] YAML-arvo päivittyy `yq`:lla: `container.version: ` +- [ ] `git commit` + `git push` Helm-repoon +- [ ] Cross-repo-status: Helm-commit + root-commit molemmat raportoitu +- [ ] Dogfood: oma CI voi dispatchata tämän + +--- + +## Toiminto + +GitOps-deployment: lukee Helm-values-YAML:n, päivittää `container.version`-arvon, committaa ja pushaa. Raportoi cross-repo-statuksen. + +## Trigger + +`workflow_dispatch` (aina dispatchataan toisesta workflow'sta) + +## Inputs (dispatch-parametrit) + +| Parametri | Kuvaus | +|-----------|--------| +| `environment` | Ympäristön nimi (korvaa `{.environment}`) | +| `version` | Uusi konttiversio | +| `root_commit` | Mikropalvelun commit josta deploy käynnistyi | +| `root_repo` | Mikropalvelun repo | +| `root_build_url` | URL mikropalvelun buildiin | + +## Steppit + +``` +start → read-yaml → update-value → commit → push → report-cross-repo → end +``` + +| Steppi | Toiminto | +|--------|----------| +| `read-yaml` | Lue `{projectFolder}/{fileName}` (korvaa `{.environment}`) | +| `update-value` | `yq` tai vastaava: aseta `{property}` = `{version}` | +| `commit` | `git add` + `git commit -m "deploy {version} to {environment}"` | +| `push` | `git push origin HEAD:master` | +| `report-cross-repo` | `report-status.sh` — raportoi molempiin suuntiin | + +## Cross-repo-raportointi + +```bash +# Helm-repon committiin: mistä deploy tuli +report-status.sh success "from {root_commit}" "{root_build_url}" "from" "$GITHUB_SHA" "$GITHUB_REPOSITORY" + +# Mikropalvelun committiin: deployattu +report-status.sh success "deployed to {environment}" "{helm_commit_url}" "deploy-{environment}" "$ROOT_COMMIT" "$ROOT_REPO" +``` + +## Concurrency + +```yaml +concurrency: + group: deploy-${{ github.repository }}-${{ inputs.environment }} + cancel-in-progress: false +``` + +## Verifiointi + +Dispatchaa mock-inputeilla: +1. YAML-arvo päivittyy oikein (esim. `container.version: 1.2.3.42` → `1.2.3.43`) +2. Commit ja push onnistuvat +3. Statusviesti ilmestyy Helm-repon commitille: "from abc123" +4. Statusviesti ilmestyy mikropalvelun commitille: "deployed to staging" + +## Viitteet + +- `docs/workflows.md` — `deploy.yml` — GitOps-deployment +- `docs/architecture.md` — Tietovuo 2: Cross-repo traceability +- `docs/config-model.md` — Deployment-konfiguraatio diff --git a/docs/tickets/0008-test-yml.md b/docs/tickets/0008-test-yml.md new file mode 100644 index 0000000..f26f4ce --- /dev/null +++ b/docs/tickets/0008-test-yml.md @@ -0,0 +1,117 @@ +# Ticket 0008: `test.yml` (reusable workflow) + +**Vaihe:** 8/12 +**Status:** pending +**Feature branch:** `feature/0008-test-yml` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0008-test-flow.feature` +- Skills: `tdd`, `implementation`, `clean-code` + +--- + +## TDD — Red-Green-Refactor + Dogfood + +### Red +Validointitesti (`tests/workflows.bats`): +- Kaikki `workflow_dispatch`-inputit: `environment`, `version`, `tags`, `root_commit`, `root_repo`, `deploy_commit`, `deploy_repo` +- `version-check` käyttää `check-version.sh` (Ticket 0011) +- Cross-repo-raportointi: 3 suuntaa (test → test-repo, test → root, test → deploy) + +```bash +bats tests/workflows.bats +# FAIL +``` + +### Green +Toteuta `gitea/workflows/test.yml`. + +```bash +bats tests/workflows.bats +# PASS +``` + +### Dogfood +Lisää kutsu `gitea/workflows/ci.yml`:stä. + +## DoD +- [ ] Cucumber: `@ticket-0008 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/workflows.bats` — workflow-validointi läpi +- [ ] Version check -steppi kytketty (`check-version.sh`) +- [ ] Cross-repo-statusraportointi 3 suuntaan +- [ ] Dogfood: kirjaston CI käyttää tätä test flow'ssa + +--- + +## Toiminto + +Test flow -steppi. Dispatchataan deploy-workflow'n jälkeen. Ajaa testit, puskaa raportit MinIO:hon ja raportoi statuksen kolmeen committiin. + +## Trigger + +`workflow_dispatch` (dispatchataan `ci-master.yml`:stä) + +## Inputs (dispatch-parametrit) + +| Parametri | Kuvaus | +|-----------|--------| +| `environment` | Testiympäristö | +| `version` | Testattava konttiversio | +| `tags` | Cucumber-tagit | +| `versionApiUrl` | URL version tarkistukseen | +| `versionCheckScript` | Polku version check -skriptiin | +| `root_commit` | Mikropalvelun commit | +| `root_repo` | Mikropalvelun repo | +| `deploy_commit` | Helm-repon commit | +| `deploy_repo` | Helm-repo | + +## Steppit + +``` +start → version-check → run-tests → push-reports → report-cross-repo → end +``` + +| Steppi | Toiminto | +|--------|----------| +| `version-check` | `check-version.sh` — varmista oikea versio ympäristössä | +| `run-tests` | Projektin oma testiajo | +| `push-reports` | `push-reports.sh` — raportit MinIO:hon | +| `report-cross-repo` | `report-status.sh` — kolmeen committiin | + +## Cross-repo-raportointi (3 suuntaa) + +```bash +# 1. Testi-repon oma commit +report-status.sh success "Tests OK" "$REPORT_URL" "test-{name}" "$GITHUB_SHA" "$GITHUB_REPOSITORY" + +# 2. Mikropalvelun commit (root) +report-status.sh success "Tests OK ({name})" "$REPORT_URL" "test-{name}" "$ROOT_COMMIT" "$ROOT_REPO" + +# 3. Helm-repon commit +report-status.sh success "tested v{version}" "$REPORT_URL" "tested-{name}" "$DEPLOY_COMMIT" "$DEPLOY_REPO" +``` + +## Concurrency + +```yaml +concurrency: + group: test-${{ inputs.environment }} + cancel-in-progress: false +``` + +## Verifiointi + +Dispatchaa mock-inputeilla: +1. `version-check` epäonnistuu → exit 1, status = "Version mismatch" +2. Testit ajetaan onnistuneesti +3. Raportit MinIO:ssa, URL:t oikein +4. Statusviestit kaikissa kolmessa commitissa + +## Viitteet + +- `docs/workflows.md` — `test.yml` — Test flow -steppi +- `docs/config-model.md` — Test flow -konfiguraatio, version check +- `docs/requirements.md` — UC6: Testi-insinööri näkee mitä konttia testattiin diff --git a/docs/tickets/0009-ci-master-yml.md b/docs/tickets/0009-ci-master-yml.md new file mode 100644 index 0000000..e460153 --- /dev/null +++ b/docs/tickets/0009-ci-master-yml.md @@ -0,0 +1,144 @@ +# Ticket 0009: `ci-master.yml` (reusable workflow) + +**Vaihe:** 9/12 +**Status:** pending +**Feature branch:** `feature/0009-ci-master-yml` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0009-ci-master.feature` +- Skills: `tdd`, `implementation`, `clean-code` + +--- + +## TDD — Red-Green-Refactor + Dogfood + +### Red +Validointitesti (`tests/workflows.bats`): +- Kaikki `workflow_call`-inputit: `config-file`, `maven-image`, `docker-image` +- `isContainerBuilt`-check: git-tagin mukaan +- Docker-labelien injektointi +- Test flow -ketjutus: `dispatch-workflow.sh` kutsutaan jokaiselle `test-flow`-stepille +- `continueToTestFlow`-steppi skip-vaihtoehdolla + +```bash +bats tests/workflows.bats +# FAIL +``` + +### Green +Toteuta `gitea/workflows/ci-master.yml`. + +```bash +bats tests/workflows.bats +# PASS +``` + +### Dogfood +Kirjaston oma `ci.yml` kutsuu `ci-master.yml`:ä master-branchille. + +## DoD +- [ ] Cucumber: `@ticket-0009 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/workflows.bats` — workflow-validointi läpi +- [ ] `isContainerBuilt`-check toimii: `git tag --points-at HEAD` +- [ ] Docker-labelit injektoitu: `git.commit`, `build.date`, `version` +- [ ] Test flow -ketju dispatchaa jokaisen stepin järjestyksessä +- [ ] Dogfood: kirjaston oma master-build käyttää tätä +- [ ] Kaikki skriptit (0001–0004) integroitu workflow'hun + +--- + +## Toiminto + +Master-branchin CI-workflow. Orkestroi koko build-test-deploy -ketjun: buildaa kontin, tagittaa commitin, ketjuttaa test flow'n `ci-flow-values.yaml`-konfiguraation mukaan. + +## Trigger + +`workflow_call` (reusable workflow) + +## Inputs + +| Parametri | Pakollinen | Kuvaus | +|-----------|------------|--------| +| `config-file` | Kyllä | Polku `ci-flow-values.yaml`:aan | +| `maven-image` | Ei | Maven-kontti | +| `docker-image` | Ei | Docker-in-Docker image | + +## Steppit + +``` +start + → isContainerBuilt? ──kyllä──→ skip build, continueToTestFlow + → ei + → unit-test → quality-gate → build-jar → build-docker → push-docker + → tag-commit → continueToTestFlow → publish-html → end +``` + +| Steppi | Skripti / Toiminto | +|--------|-------------------| +| `start` | `report-status.sh pending "Building..."` | +| `isContainerBuilt` | `git tag --points-at HEAD` — onko jo buildattu? | +| `unit-test` | Projektin oma testiajo | +| `quality-gate` | SonarQube quality gate -pollaus | +| `build-jar` | `mvn package` / `gradle build` | +| `build-docker` | `docker build` + Docker-labelit | +| `push-docker` | `docker push` → Gitea Packages | +| `tag-commit` | `tag-commit.sh {version}` | +| `continueToTestFlow` | `dispatch-workflow.sh` jokaiselle test-flow -stepille | +| `publish-html` | `push-reports.sh` — Maven Site + muut | +| `end` | `report-status.sh success/failure` | + +## Test flow -ketjutus + +```yaml +# ci-flow-values.yaml — test-flow-taulu +test-flow: + - deploy: development + wait: true + - test: + name: "integration fast" + repo: tests/integration + workflow: test.yml + ref: main + tags: "@temperature and not @slow" + - deploy: staging + wait: true + - test: + name: e2e + repo: tests/e2e + workflow: test.yml + ref: main +``` + +Workflow iteroi `test-flow`-taulun ja kutsuu `dispatch-workflow.sh` jokaiselle stepille: + +```bash +for step in test-flow; do + dispatch-workflow.sh {step.repo} {step.workflow} {step.ref} '{...inputs...}' +done +``` + +## Concurrency + +```yaml +concurrency: + group: master-${{ github.repository }} + cancel-in-progress: false +``` + +## Verifiointi + +Simuloi koko master flow paikallisesti: +1. `isContainerBuilt` = false → build kontti +2. `tag-commit.sh` → tagi ilmestyy commitille +3. `isContainerBuilt` = true uusinta-ajossa → build skipataan +4. `dispatch-workflow.sh` kutsuu deploy → test → e2e ketjun +5. Kaikki statusviestit näkyvät oikeissa commiteissa + +## Viitteet + +- `docs/workflows.md` — `ci-master.yml` — Master / release-branch +- `docs/config-model.md` — `isContainerBuild()`, Docker-labelit, test-flow-taulukko +- `docs/design-rationale.md` — Periaate 7: Cross-repo commit traceability diff --git a/docs/tickets/0010-report-service-retention-cronjob.md b/docs/tickets/0010-report-service-retention-cronjob.md new file mode 100644 index 0000000..15b7b6f --- /dev/null +++ b/docs/tickets/0010-report-service-retention-cronjob.md @@ -0,0 +1,130 @@ +# Ticket 0010: `report-service/` — retention CronJob + +**Vaihe:** 10/12 +**Status:** pending +**Feature branch:** `feature/0010-report-service-retention-cronjob` +**TDD required:** Yes +**Feature file required:** No + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/retention-cleanup.bats` mock-MinIO:a ja mock-Gitea API:a vasten: +- `retention-cleanup.sh --dry-run` listaa poistettavat objektit +- Yli 90 vrk vanha feature-build → merkitään poistettavaksi +- Tagattu commit → ei merkitä poistettavaksi +- `keepMin`: 3 uusinta säilyy branchista +- ConfigMap-pohjainen retention: `retention.yaml` luetaan oikein + +```bash +bats tests/retention-cleanup.bats +# FAIL +``` + +### Green +Toteuta `report-service/retention-cleanup.sh` + `CronJob.yaml` + `ConfigMap.yaml`. + +```bash +bats tests/retention-cleanup.bats +# PASS +``` + +### Refactor +Parametrisoi retention-säännöt, paranna lokitusta. + +## DoD +- [ ] `tests/retention-cleanup.bats` — kaikki testit läpi +- [ ] `report-service/retention-cleanup.sh` toimii --dry-run-tilassa +- [ ] `report-service/CronJob.yaml` — schedule `0 3 * * *` +- [ ] `report-service/ConfigMap.yaml` — retention.yaml oikea muoto +- [ ] Aika-, branch-, tagi- ja keepMin-säännöt toimivat + +--- + +## Toiminto + +Kubernetes CronJob, joka ajaa siivousskriptin päivittäin. Skripti lukee ConfigMap-pohjaisen retention policyn ja poistaa vanhentuneet raportit MinIO:sta. + +## Artefaktit + +### `report-service/retention-cleanup.sh` + +Skripti joka: +1. Listaa kaikki bucketin objektit (`mc ls --recursive`) +2. Parsii polusta `repo_slug` ja `commit_short` +3. Hakee Gitea API:sta commitin metadata (`GET /api/v1/repos/{owner}/{repo}/commits/{sha}` → branch, onko tagattu) +4. Soveltaa ConfigMapin retention-sääntöjä +5. Poistaa vanhentuneet (`mc rm`) + +### ConfigMap + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: minio-report-retention +data: + retention.yaml: | + rules: + - branch: "master" + maxAgeDays: 365 + keepMin: 20 + - branch: "feature/*" + maxAgeDays: 90 + keepMin: 5 + - tagged: true + maxAgeDays: -1 # ei koskaan + keepMin: -1 + - default: + maxAgeDays: 90 + keepMin: 3 +``` + +### CronJob + +```yaml +apiVersion: batch/v1 +kind: CronJob +metadata: + name: minio-report-cleanup +spec: + schedule: "0 3 * * *" # kerran päivässä klo 03:00 + jobTemplate: + spec: + template: + spec: + containers: + - name: cleanup + image: minio/mc:latest + command: ["/scripts/retention-cleanup.sh"] + volumeMounts: + - name: config + mountPath: /etc/retention + - name: script + mountPath: /scripts + volumes: + - name: config + configMap: + name: minio-report-retention + - name: script + configMap: + name: minio-cleanup-script +``` + +## Verifiointi + +1. Aja `retention-cleanup.sh` --dry-run → listaa poistettavat objektit +2. Tarkista: yli 90 vrk vanha feature-build → merkitään poistettavaksi +3. Tarkista: tagattu commit → ei merkitä poistettavaksi +4. Tarkista: `keepMin`-säännön tuorein 3 säilyy + +## Viitteet + +- `docs/report-hosting.md` — Retention policy +- `docs/architecture.md` — `report-service/`-moduuli diff --git a/docs/tickets/0011-check-version-sh.md b/docs/tickets/0011-check-version-sh.md new file mode 100644 index 0000000..77a53d4 --- /dev/null +++ b/docs/tickets/0011-check-version-sh.md @@ -0,0 +1,103 @@ +# Ticket 0011: `check-version.sh` (Fibonacci-backoff) + +**Vaihe:** 11/12 +**Status:** pending +**Feature branch:** `feature/0011-check-version-sh` +**TDD required:** Yes +**Feature file required:** Yes + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- `tests/features/0011-check-version.feature` +- Skills: `tdd`, `implementation`, `clean-code`, `bash-script` + +--- + +## TDD — Red-Green-Refactor + +### Red +Kirjoita `tests/check-version.bats` mock-API:a vasten: +- Mock palauttaa oikean version 5. yrityksellä → exit 0 +- Mock ei koskaan palauta oikeaa versiota → exit 1 (MAX_RETRIES täyttyy) +- Fibonacci-välit: 1 2 3 5 8 13 ... (tarkista sleep-kutsut) +- API ei vastaa (timeout) → exit 1 +- Tyhjä URL → exit 1 + +```bash +bats tests/check-version.bats +# FAIL +``` + +### Green +Toteuta `scripts/check-version.sh` Fibonacci-backoffilla. + +```bash +bats tests/check-version.bats +# PASS +``` + +### Refactor +Varmista curl-aikakatkaisu, paranna lokitusta. + +## DoD +- [ ] Cucumber: `@ticket-0011 and @mock` → kaikki skenaariot GREEN +- [ ] `tests/check-version.bats` — kaikki testit läpi +- [ ] Fibonacci-sekvenssi: 1 2 3 5 8 13 21 34 55 89 +- [ ] Maksimiaika ~231 s, MAX_RETRIES=10 +- [ ] Exit 0: versio löytyi, exit 1: ei löytynyt + +--- + +## Toiminto + +Pollaa ympäristössä deployatun konttiversion API:a Fibonacci-backoffilla, kunnes haluttu versio on havaittu. Kutsutaan `test.yml`:n `version-check`-stepistä ennen testien ajoa. + +## Rajapinta + +```bash +check-version.sh +``` + +- Exit 0: versiot täsmäävät +- Exit 1: versiota ei löytynyt `MAX_RETRIES` yrityksen jälkeen + +## Fibonacci-sekvenssi + +``` +1s → 2s → 3s → 5s → 8s → 13s → 21s → 34s → 55s → 89s +``` + +Maksimiaika: ~231 sekuntia (1+2+3+5+8+13+21+34+55+89). + +## Pseudokoodi + +```bash +MAX_RETRIES=10 +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 +``` + +## Verifiointi + +Mock-API, jossa: +1. Pyyntö 1–4 → `{"version": "1.2.3.41"}` (vanha versio) +2. Pyyntö 5 → `{"version": "1.2.3.42"}` (odotettu versio) + +Skripti pollaa ja löytää oikean version 5. yrityksellä → exit 0. + +## Viitteet + +- `docs/config-model.md` — Version check (Fibonacci-backoff) +- `docs/workflows.md` — `test.yml` version-check-steppi diff --git a/docs/tickets/0012-integration-testing.md b/docs/tickets/0012-integration-testing.md new file mode 100644 index 0000000..346f44c --- /dev/null +++ b/docs/tickets/0012-integration-testing.md @@ -0,0 +1,45 @@ +# Ticket 0012: Integraatiotestaus koko ketjulle + +**Vaihe:** 12/12 +**Status:** pending +**Feature branch:** `feature/0012-integration-testing` +**TDD required:** Yes +**Feature file required:** Yes (kaikki tikettien 0001–0011 feature filet, `@real`-skenaariot) + +**Required context:** +- `docs/test-plan/tdd-guide.md` +- Kaikki `tests/features/0001–0011-*.feature` — tikettien 0001–0011 feature filet +- Skills: `tdd`, `implementation`, `clean-code` + +--- + +## TDD — E2E `@real` -verifiointi + +Tiketti 0012 ajaa tikettien 0001–0011 feature filejen `@real`-skenaariot oikeaa testiympäristöä vasten. Se ei luo uusia skenaarioita — se verifioi jo määritellyt skenaariot todellisessa ympäristössä. + +Feature filet: `tests/features/0001–0011-*.feature` (luotu tiketeissä 0001–0011). + +### Toiminto + +1. Vaihda mock-URL:t oikean testiympäristön URL:eihin +2. Aja kaikki `@real`-skenaariot: + +```bash +cucumber tests/features/ --tags @real +``` + +Skenaariot jotka eivät ole `@real`-tägättyjä skipataan automaattisesti. + +### DoD + +- [ ] Cucumber: kaikki `@real`-skenaariot GREEN oikeaa ympäristöä vasten +- [ ] Bats: kaikki aiemmat testit edelleen GREEN +- [ ] Toteutus: mock→real -konfiguraatio olemassa +- [ ] Refactor: ei duplikaatiota, virheenkäsittely kunnossa + +## Viitteet + +- `docs/tickets/0001–0011` — Tiketit joiden featuret ajetaan +- `docs/requirements.md` — UC1–UC7 +- `docs/architecture.md` — Järjestelmäkaavio + tietovuot +- `docs/test-plan/tdd-guide.md` diff --git a/tests/features/ci-pipeline.feature b/tests/features/ci-pipeline.feature new file mode 100644 index 0000000..da7298c --- /dev/null +++ b/tests/features/ci-pipeline.feature @@ -0,0 +1,70 @@ +Feature: CI pipeline + As a developer + I want automated CI pipelines for feature and master branches + So that every commit is tested and master builds produce deployable artifacts + + # --------------------------------------------------------------------------- + # Ticket 0006: ci-feature.yml — Feature branch CI workflow + # --------------------------------------------------------------------------- + + Background: + Given the project has a CI configuration file in its repository + + @ticket-0006 @mock @wip @real + Scenario: Feature branch runs unit tests and publishes reports + When a commit is pushed to a feature branch + Then the unit tests are executed + And the test reports are published + And each step reports its status to the commit + + @ticket-0006 @mock @wip @real + Scenario: Feature branch reports failure when tests do not pass + When tests fail on a feature branch + Then the commit shows a failure status with a link to the test results + + @ticket-0006 @mock @wip @real + Scenario: Feature branch does not build a container image + Given a commit is pushed to a feature branch + When the CI pipeline runs + Then no container image is built or pushed + + @ticket-0006 @mock @wip + Scenario: Only one pipeline runs at a time for the same feature branch + When a new commit is pushed to a feature branch while a pipeline is already running + Then the existing pipeline continues and the new one waits + + # --------------------------------------------------------------------------- + # Ticket 0009: ci-master.yml — Master branch CI workflow + # --------------------------------------------------------------------------- + + @ticket-0009 @mock @wip @real + Scenario: Master branch builds and pushes a container image + When a commit is pushed to the master branch + Then the container image is built with version labels + And the image is pushed to the container registry + And the commit is tagged with the build version + + @ticket-0009 @mock @wip @real + Scenario: Master branch skips container build if already built + When a commit on the master branch is already tagged with a build version + And a new pipeline is triggered for the same commit + Then the container build is skipped + And the pipeline proceeds to reporting and test flow + + @ticket-0009 @mock @wip @real + Scenario: Master branch runs the full test flow chain after a successful build + When the container build and push succeed on the master branch + Then the deployment to the first environment is dispatched + And after deployment succeeds the integration tests are dispatched + And the end-to-end tests run as the final step in the chain + + @ticket-0009 @mock @wip @real + Scenario: Master branch stops the test flow chain when a step fails + When a step in the test flow chain fails + Then the remaining steps are not executed + And the commit shows a failure status pointing to the failed step + + @ticket-0009 @mock @wip + Scenario: Only one master pipeline runs at a time for the same project + When a new commit is pushed to master while a pipeline is already running + Then the existing pipeline continues and the new one waits diff --git a/tests/features/commit-status.feature b/tests/features/commit-status.feature new file mode 100644 index 0000000..1bf1dd2 --- /dev/null +++ b/tests/features/commit-status.feature @@ -0,0 +1,72 @@ +Feature: Commit status visibility + As a developer + I want to see build and deployment statuses on commits + So that I know the state of each commit at a glance + + Background: + Given a project repository exists in Gitea + And a commit has been pushed to the repository + + # --------------------------------------------------------------------------- + # Ticket 0001: report-status.sh — Build status reporting to commits + # --------------------------------------------------------------------------- + + @ticket-0001 @mock @wip @real + Scenario: Build step reports pending status to commit + When a build step starts executing + Then the commit shows a pending status with a description of the step + + @ticket-0001 @mock @wip @real + Scenario: Build step reports successful completion with a result link + When a build step completes successfully and reports its results + Then the commit shows a success status with a clickable link to the results + + @ticket-0001 @mock @wip @real + Scenario: Build step reports failure when tests do not pass + When a build step fails + Then the commit shows a failure status with a description of what went wrong + + @ticket-0001 @mock @wip @real + Scenario: Multiple build steps report distinct statuses on the same commit + When several build steps each report their own status to the same commit + Then each status appears under a unique label on the commit + + @ticket-0001 @mock @wip @real + Scenario: Deployment step reports status back to the source commit + When a deployment finishes for a commit that originated from another repository + Then the source commit shows the deployment status alongside the build status + + @ticket-0001 @mock @wip + Scenario: Status reporting is interrupted when the build system cannot be reached + When a build step tries to report status but the build system is unavailable + Then the pipeline fails with a clear error message + + # --------------------------------------------------------------------------- + # Ticket 0004: tag-commit.sh — Version tagging on commits + # --------------------------------------------------------------------------- + + @ticket-0004 @mock @wip @real + Scenario: Build tags a commit with a version number after a successful docker push + When a container image is built and pushed successfully + Then the commit receives a version tag that includes the build number + + @ticket-0004 @mock @wip @real + Scenario Outline: Tagging a commit with a specific version + When a build completes with version "" + Then the commit is tagged with "" + + Examples: + | version | + | 1.2.3.42 | + | 2.0.0.1 | + | 0.1.0.15 | + + @ticket-0004 @mock @wip + Scenario: Tagging fails when the same version tag already exists on the commit + When a build tries to tag a commit with a version that is already tagged + Then the tagging fails with a notification that the tag already exists + + @ticket-0004 @mock @wip + Scenario: Tagging fails when no version is provided + When a build tries to tag a commit without specifying a version + Then the tagging fails with an error diff --git a/tests/features/deployment.feature b/tests/features/deployment.feature new file mode 100644 index 0000000..17d4938 --- /dev/null +++ b/tests/features/deployment.feature @@ -0,0 +1,45 @@ +Feature: Deployment + As a developer + I want automated GitOps deployments to environments + So that container versions are deployed consistently and the chain is traceable + + Background: + Given a container image has been built and pushed + And a Helm configuration repository exists + + # --------------------------------------------------------------------------- + # Ticket 0007: deploy.yml — GitOps deployment workflow + # --------------------------------------------------------------------------- + + @ticket-0007 @mock @wip @real + Scenario: Deploy a container version to a staging environment + When a deployment is dispatched to the staging environment with a new version + Then the Helm configuration is updated with the new container version + And the change is committed and pushed to the configuration repository + + @ticket-0007 @mock @wip @real + Scenario: Deploy a container version to the production environment + When a deployment is dispatched to the production environment with a new version + Then the Helm configuration is updated with the new container version + And the change is committed and pushed to the configuration repository + + @ticket-0007 @mock @wip @real + Scenario: Deployment reports its source back to the originating commit + When a deployment completes successfully + Then the originating commit shows a deployed status with a link to the deployment commit + + @ticket-0007 @mock @wip @real + Scenario: Deployment configuration commit shows where the deploy came from + When a deployment commit is created in the configuration repository + Then the configuration commit shows a trace status linking back to the source commit + + @ticket-0007 @mock @wip @real + Scenario: Developer navigates from source commit to deployment commit and back + When a developer views the source commit + Then they can click a deploy status to navigate to the deployment commit + And from the deployment commit they can navigate back to the source commit + + @ticket-0007 @mock @wip + Scenario: Only one deployment runs at a time for the same environment + When a new deployment is dispatched to an environment that already has one in progress + Then the existing deployment continues and the new one waits diff --git a/tests/features/report-browsing.feature b/tests/features/report-browsing.feature new file mode 100644 index 0000000..707bbda --- /dev/null +++ b/tests/features/report-browsing.feature @@ -0,0 +1,76 @@ +Feature: Report browsing + As a developer + I want to browse test reports and build history in a web browser + So that I can review test results, compare builds, and navigate between reports + + Background: + Given a project has completed at least one build + And the build reports are accessible through the report storage + + # --------------------------------------------------------------------------- + # Ticket 0003: push-reports.sh — Pushing test reports to storage + # --------------------------------------------------------------------------- + + @ticket-0003 @mock @wip @real + Scenario: Push Cucumber test report after a successful test run + When a test run produces a Cucumber report + Then the report is stored and accessible at a permanent web address + + @ticket-0003 @mock @wip @real + Scenario: Push code coverage report after analysis + When a build generates a code coverage report + Then the coverage report is stored and accessible at a permanent web address + + @ticket-0003 @mock @wip @real + Scenario Outline: Push different types of test artifacts + When a build produces a "" report + Then the report is stored under its own section in the build's report listing + + Examples: + | report_type | + | Cucumber | + | JaCoCo | + | JUnit | + | Maven Site | + + @ticket-0003 @mock @wip @real + Scenario: Report push updates the build report index + When a report is pushed to storage + Then the build's report listing includes a link to the new report with its display name + + @ticket-0003 @mock @wip + Scenario: Report push fails when the source report directory does not exist + When a build tries to push a report but the report directory is missing + Then the pipeline fails with a clear error + + # --------------------------------------------------------------------------- + # Ticket 0005: report-service/ — HTML index generation for report browsing + # --------------------------------------------------------------------------- + + @ticket-0005 @mock @wip @real + Scenario: Developer sees a list of all builds for a project + When a developer opens the project build history page + Then all builds are listed in chronological order with the newest first + And each build shows its short commit identifier, date, branch, and status + + @ticket-0005 @mock @wip @real + Scenario: Developer navigates into a specific build to see its reports + When a developer clicks on a build in the project build history + Then a page opens showing all reports available for that build as clickable links + + @ticket-0005 @mock @wip @real + Scenario: Build listing shows success or failure status with a clear indicator + When a build has completed + Then the build listing shows a success indicator for passing builds + And a failure indicator for failing builds + + @ticket-0005 @mock @wip @real + Scenario: Developer can navigate back from a build report listing to the project build history + When a developer is viewing the reports of a specific build + Then a navigation link leads back to the project build history page + + @ticket-0005 @mock @wip @real + Scenario: Developer opens two builds side by side to compare reports + When a developer views two different builds in separate browser tabs + Then both builds show their respective report listings + And the developer can compare which tests passed or failed between the builds diff --git a/tests/features/test-execution.feature b/tests/features/test-execution.feature new file mode 100644 index 0000000..39fb044 --- /dev/null +++ b/tests/features/test-execution.feature @@ -0,0 +1,92 @@ +Feature: Test execution + As a test engineer + I want integration and end-to-end tests to run automatically after deployment + So that I can verify the deployed version works correctly + + Background: + Given a deployment has completed in the target environment + And the test project repository exists with test definitions + + # --------------------------------------------------------------------------- + # Ticket 0002: dispatch-workflow.sh — Dispatching and polling workflows + # --------------------------------------------------------------------------- + + @ticket-0002 @mock @wip @real + Scenario: Dispatch a test workflow and wait for its completion + When a test workflow is dispatched to a test project + Then the pipeline waits until the test workflow finishes + And the pipeline continues only after receiving a success result + + @ticket-0002 @mock @wip @real + Scenario: Dispatch fails when the dispatched test workflow fails + When a test workflow is dispatched and the tests fail + Then the calling pipeline reports failure + + @ticket-0002 @mock @wip + Scenario: Dispatch times out when the test workflow takes too long + When a test workflow is dispatched but does not finish within the allowed time + Then the calling pipeline reports a timeout error + + # --------------------------------------------------------------------------- + # Ticket 0011: check-version.sh — Version polling with Fibonacci backoff + # --------------------------------------------------------------------------- + + @ticket-0011 @mock @wip @real + Scenario: Target version is eventually found after a few retries + When the deployed version in the environment does not match the expected version initially + And the version check is retried with increasing wait times + Then the version eventually matches and the test flow proceeds + + @ticket-0011 @mock @wip + Scenario: Target version is never found within the maximum retries + When the deployed version keeps returning a different version than expected + And the maximum number of retries is reached + Then the version check fails with a version mismatch error + + @ticket-0011 @mock @wip + Scenario: Version check fails when the version endpoint cannot be reached + When the version API endpoint is not responding + Then the version check fails with an error + + # --------------------------------------------------------------------------- + # Ticket 0008: test.yml — Test flow execution and cross-repo reporting + # --------------------------------------------------------------------------- + + @ticket-0008 @mock @wip @real + Scenario: Test flow verifies the deployed version before running tests + When a test flow is triggered + Then the version of the running container is checked against the expected version + And tests proceed only after the version matches + + @ticket-0008 @mock @wip @real + Scenario: Test flow executes tests and publishes reports + When tests are executed as part of the test flow + Then the test reports are published to the report storage + And the reports are accessible through the browse interface + + @ticket-0008 @mock @wip @real + Scenario: Test flow reports results to the test project commit + When tests complete + Then the test project commit shows a test status with a link to the report + + @ticket-0008 @mock @wip @real + Scenario: Test flow reports results back to the source commit + When tests complete for a source commit + Then the source commit shows which tests were run and a link to the results + + @ticket-0008 @mock @wip @real + Scenario: Test flow reports the tested version on the deployment commit + When tests complete + Then the deployment commit shows which version was tested and a link to the test results + + @ticket-0008 @mock @wip @real + Scenario: Developer traces the full chain from source commit through deployment to test results + When a developer views the source commit + Then they can follow the deployment status to the deployment commit + And from the deployment commit they can follow the test status to the test results + And from the test results they can navigate back to the source commit + + @ticket-0008 @mock @wip @real + Scenario: Developer sees which container version was tested on the test project commit + When a developer views the test project commit + Then the commit shows the tested container version and the source commit it originated from