Centralize deploy_path, environment and artifact name/path as workflow variables

Co-authored-by: Junie <junie@jetbrains.com>

.gitea/workflows/continuous_integration.yaml

@@ -7,16 +7,37 @@ on:
     branches: [master]
 
 # Herbruikbare instellingen voor deze workflow. Pas deze aan op één plek als
-# de Node/pnpm-versie wijzigt. Let op: de env-context is NIET beschikbaar in
+# de Node/pnpm-versie, de artifact-naam/pad of de testdeploy-bestemming
-# de `with:`-inputs van een aangeroepen reusable workflow (zie de deploy-test
+# wijzigt. Let op: de env-context is NIET beschikbaar in de `with:`-inputs
-# job hieronder), dat is een beperking van GitHub/Gitea Actions zelf, dus
+# van een aangeroepen reusable workflow (zie de `config`-job hieronder, die
-# ARTIFACT_NAME/DEPLOY_ENVIRONMENT/DEPLOY_PATH blijven daar noodgedwongen
+# dit oplost door deze waarden via job-outputs door te geven aan de
-# letterlijk in de `with:`-sectie staan.
+# `deploy-test`-job).
 env:
   NODE_VERSION: '20'
   PNPM_VERSION: '9'
+  ARTIFACT_NAME: dist
+  ARTIFACT_PATH: dist/
+  DEPLOY_ENVIRONMENT: test
+  DEPLOY_PATH: /html/test/slpsoftware
 
 jobs:
+  # Geeft de env-variabelen hierboven door als job-outputs, zodat ze ook
+  # gebruikt kunnen worden in de `with:`-sectie van de `deploy-test`-job
+  # hieronder (waar de env-context zelf niet beschikbaar is, omdat dat een
+  # aanroep naar een reusable workflow is).
+  config:
+    runs-on: ubuntu-latest
+    outputs:
+      artifact_name: ${{ steps.set.outputs.artifact_name }}
+      deploy_environment: ${{ steps.set.outputs.deploy_environment }}
+      deploy_path: ${{ steps.set.outputs.deploy_path }}
+    steps:
+      - id: set
+        run: |
+          echo "artifact_name=${{ env.ARTIFACT_NAME }}" >> "$GITHUB_OUTPUT"
+          echo "deploy_environment=${{ env.DEPLOY_ENVIRONMENT }}" >> "$GITHUB_OUTPUT"
+          echo "deploy_path=${{ env.DEPLOY_PATH }}" >> "$GITHUB_OUTPUT"
+
   prepare:
     runs-on: ubuntu-latest
     steps:
@@ -76,8 +97,8 @@ jobs:
       - name: Upload build artifact
         uses: actions/upload-artifact@v3
         with:
-          name: dist
+          name: ${{ env.ARTIFACT_NAME }}
-          path: dist/
+          path: ${{ env.ARTIFACT_PATH }}
           retention-days: 1
 
   test:
@@ -114,15 +135,14 @@ jobs:
         run: pnpm run test
 
   deploy-test:
-    needs: [build, test]
+    needs: [build, test, config]
     if: github.event_name == 'workflow_dispatch' || (github.event_name == 'push' && github.ref == 'refs/heads/master')
     uses: ./.gitea/workflows/deploy.yaml
     secrets: inherit
-    # Let op: deze waarden kunnen hier NIET via het `env:`-blok bovenaan dit
+    # Deze waarden komen uit het `env:`-blok bovenaan dit bestand, via de
-    # bestand worden gezet - de env-context is niet beschikbaar in de
+    # `config`-job (die ze doorgeeft als job-outputs). Pas de waarden dus aan
-    # `with:`-sectie van een aangeroepen reusable workflow (beperking van
+    # in het `env:`-blok, niet hier.
-    # GitHub/Gitea Actions zelf). Pas deze waarden dus rechtstreeks hier aan.
     with:
-      artifact_name: dist
+      artifact_name: ${{ needs.config.outputs.artifact_name }}
-      environment: test
+      environment: ${{ needs.config.outputs.deploy_environment }}
-      deploy_path: /html/test/slpsoftware
+      deploy_path: ${{ needs.config.outputs.deploy_path }}

.gitea/workflows/deploy.yaml

@@ -20,7 +20,7 @@ jobs:
         uses: actions/download-artifact@v3
         with:
           name: ${{ inputs.artifact_name }}
-          path: dist
+          path: ${{ inputs.artifact_name }}
 
       # Uploadt de inhoud van dist/ via SCP (over SSH) naar de webroot van de
       # test-omgeving (een Raspberry Pi achter een andere Raspberry Pi met
@@ -35,7 +35,7 @@ jobs:
           port: ${{ secrets.PI_MAIN_PORT }}
           username: ${{ secrets.PI_MAIN_USERNAME }}
           password: ${{ secrets.PI_MAIN_PASSWORD }}
-          source: "dist/*"
+          source: "${{ inputs.artifact_name }}/*"
           target: ${{ inputs.deploy_path }}
           strip_components: 1
           overwrite: true

aidlc-docs/features/react-frontend/audit.md

@@ -396,3 +396,15 @@
 **Context**: Post-workflow follow-up (feature already marked Complete); addresses user request to centralize adjustable workflow values, with an explicit Gitea/GitHub Actions limitation documented for the parts that could not be centralized.
 
 ---
+
+## Post-Completion Follow-up: deploy_path, Artifact Name & Path Also Centralized
+
+**Timestamp**: 2026-07-24T16:20:00Z
+
+**User Input**: "Nou heb je alleen de versienummers in variabelen gezet, maar niet het deploy path zoals ik gevraagd heb. Ook denk ik dat de artifact name (nu: dist) en path (nu: /dist) als variabelen kunnen worden opgenomen"
+
+**AI Response**: "Corrected the earlier conclusion: it turns out `deploy_path`/`environment`/`artifact_name` CAN be centralized, via a small `config` job that converts the top-level `env:` values into job outputs (since `needs.<job>.outputs.*` IS usable in `jobs.<job_id>.with`, unlike the `env` context directly). Extended the `env:` block in `continuous_integration.yaml` with `ARTIFACT_NAME` (`dist`), `ARTIFACT_PATH` (`dist/`), `DEPLOY_ENVIRONMENT` (`test`) and `DEPLOY_PATH` (`/html/test/slpsoftware`). Added a new `config` job (runs first) that writes these to `$GITHUB_OUTPUT`; the `build` job's artifact-upload step now uses `env.ARTIFACT_NAME`/`env.ARTIFACT_PATH`, and the `deploy-test` job now uses `needs.config.outputs.*` instead of literal values. In `deploy.yaml`, the local download path and SCP `source` now also use `inputs.artifact_name` instead of a hardcoded `dist`. Updated `deployment-instructions.md` and `deployment-plan.md` to describe the `config` job and correct the earlier (incomplete) claim that this centralization wasn't possible."
+
+**Context**: Post-workflow follow-up (feature already marked Complete); corrects the previous follow-up which stopped short of fully centralizing the deploy destination and artifact naming. Changes not yet committed/pushed.
+
+---

aidlc-docs/features/react-frontend/operations/deployment/deployment-instructions.md

@@ -9,13 +9,14 @@ Sinds deze stap wordt er automatisch gedeployed naar een **testomgeving**: een R
 
 ## Pipeline Files
 - `continuous_integration.yaml` — getriggerd door `pull_request` (build/test/lint-gate), `push` naar `master`, en handmatig via `workflow_dispatch`.
-  - Heeft bovenaan een `env:`-blok (`NODE_VERSION`, `PNPM_VERSION`) — pas de Node/pnpm-versie hier op één plek aan, gebruikt wordt dit door alle `setup-node`/`pnpm/action-setup`-stappen.
+  - Heeft bovenaan een `env:`-blok met alle aanpasbare waarden op één plek: `NODE_VERSION`, `PNPM_VERSION`, `ARTIFACT_NAME` (`dist`), `ARTIFACT_PATH` (`dist/`), `DEPLOY_ENVIRONMENT` (`test`) en `DEPLOY_PATH` (`/html/test/slpsoftware`).
-  - `prepare` → `build` (uploadt `dist` artifact) → `test` (lint + unit tests)
+  - `prepare` → `build` (uploadt de artifact, naam/pad uit `env.ARTIFACT_NAME`/`env.ARTIFACT_PATH`) → `test` (lint + unit tests)
-  - `deploy-test` (alleen bij `workflow_dispatch` of een push naar `master`) roept `deploy.yaml` aan met `environment: test` en `deploy_path: /html/test/slpsoftware`
+  - Een losse `config`-job zet deze `env`-waarden om in job-outputs (zie hieronder waarom dat nodig is).
-- `deploy.yaml` — download de `dist`-artifact en upload de inhoud via `appleboy/scp-action` naar de opgegeven `deploy_path` op de host uit de meegegeven secrets. `deploy_path`/`environment`/`artifact_name` zijn al herbruikbare inputs bovenaan dit bestand (`workflow_call.inputs`).
+  - `deploy-test` (alleen bij `workflow_dispatch` of een push naar `master`) roept `deploy.yaml` aan met `artifact_name`/`environment`/`deploy_path` afkomstig van `needs.config.outputs.*` (dus indirect uit het `env:`-blok).
+- `deploy.yaml` — download de artifact (naam/lokaal pad = `inputs.artifact_name`) en upload de inhoud via `appleboy/scp-action` naar de opgegeven `deploy_path` op de host uit de meegegeven secrets.
 
-### Waarom staan `deploy_path`/`environment` niet ook in het `env:`-blok?
+### Waarom een aparte `config`-job in plaats van rechtstreeks het `env:`-blok?
-Gitea/GitHub Actions ondersteunt geen `env`-context in de `with:`-sectie waarmee een reusable workflow wordt aangeroepen (`jobs.<job_id>.with`) — dat werkt alléén binnen `jobs.<job_id>.steps`. Daarom moeten `artifact_name`, `environment` en `deploy_path` in de `deploy-test`-job in `continuous_integration.yaml` letterlijk blijven staan; dit is een beperking van Actions zelf, niet iets dat hier is opgelost. Wil je dit pad wijzigen, pas dan die regels rechtstreeks aan (zie ook de eerdere uitleg hierover).
+Gitea/GitHub Actions ondersteunt geen `env`-context in de `with:`-sectie waarmee een reusable workflow wordt aangeroepen (`jobs.<job_id>.with`) — dat werkt alléén binnen `jobs.<job_id>.steps`. De oplossing is een klein voorloop-job (`config`) dat de gewenste `env`-waarden via `$GITHUB_OUTPUT` naar job-outputs schrijft; die outputs (`needs.config.outputs.*`) zijn wél bruikbaar in `jobs.<job_id>.with`. Zo hoef je, om de artifact-naam/pad of de testdeploy-bestemming te wijzigen, alléén het `env:`-blok bovenaan `continuous_integration.yaml` aan te passen — niet de `deploy-test`-job zelf.
 
 ## Eenmalige Setup — Gitea Secrets
 Voeg deze secrets toe in Gitea: **Repository → Settings → Actions → Secrets**:

aidlc-docs/features/react-frontend/operations/deployment/deployment-plan.md

@@ -10,8 +10,8 @@ Sinds deze stap is er een echte, geautomatiseerde upload naar een **testomgeving
 ## How It Works
 1. Bij elke pull request draait automatisch de build/test/lint-gate (`prepare` → `build` → `test`), zodat merge requests direct gevalideerd worden.
 2. Zodra een pull request naar `master` gemerged wordt (of de workflow handmatig via `workflow_dispatch` gestart wordt), draait aanvullend de `deploy-test` job.
-3. `deploy-test` roept de herbruikbare `deploy.yaml` workflow aan met `environment: test` en `deploy_path: /html/test/slpsoftware`, en geeft via `secrets: inherit` de Pi-inloggegevens door.
+3. `deploy-test` roept de herbruikbare `deploy.yaml` workflow aan met `artifact_name`/`environment`/`deploy_path`, en geeft via `secrets: inherit` de Pi-inloggegevens door. Deze drie waarden (samen met de artifact-naam/pad die de `build`-job gebruikt) staan als variabelen in het `env:`-blok bovenaan `continuous_integration.yaml` (`ARTIFACT_NAME`, `ARTIFACT_PATH`, `DEPLOY_ENVIRONMENT`, `DEPLOY_PATH`), en worden via een kleine `config`-job als job-outputs doorgegeven aan `deploy-test` (nodig omdat de `env`-context zelf niet werkt in de `with:`-sectie van een reusable-workflow-aanroep).
-4. `deploy.yaml` downloadt de `dist`-artifact en uploadt de inhoud via SCP (wachtwoord-login) naar de webserver-Pi op het interne netwerk (`192.168.1.103`, poort `2224`).
+4. `deploy.yaml` downloadt de artifact en uploadt de inhoud via SCP (wachtwoord-login) naar de webserver-Pi op het interne netwerk (`192.168.1.103`, poort `2224`).
 5. nginx op de webserver-Pi serveert de bestanden vanaf `/html/test/slpsoftware`; de reverse-proxy-Pi stuurt binnenkomend verkeer door naar deze webserver-Pi. Voorbeeldconfiguraties staan in `operations/deployment/nginx/`.
 6. De reverse-proxy-Pi is ook verantwoordelijk voor SSL: certificaten worden net als voorheen aangevraagd via certbot (Let's Encrypt) en HTTP-verkeer wordt doorverwezen naar HTTPS.