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

Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
2026-07-24 16:24:20 +02:00
co-authored by Junie
parent 3e537162c0
commit f47aed55c7
5 changed files with 58 additions and 25 deletions
@@ -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.
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`).
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 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.