CI: joburile de producție rulează pe runner-ul de producție

Pe 18 august producția a fost mutată pe mașina ei, iar deploy:production a trecut pe runner-ul hyperice-prod-shell. Celelalte două joburi care ating stiva de producție au rămas pe hyperice-shell:

• smtp:config:production — scrie blocul SMTP în /mnt/hyperice-prod/backend/.env și repornește backendul;
• seed:production — populează baza live.

hyperice-shell e acum altă mașină. Verificat prin API-ul de runnere: hyperice-shell = 194.60.201.231, hyperice-prod-shell = 167.86.114.109. Adică butoanele alea ar fi rulat pe hostul de develop, unde /mnt/hyperice-prod nu e producția.

Niciunul dintre ele nu a fost apăsat de la separare, deci nu s-a scris nimic unde nu trebuia. Etichetele se corectează înainte să apese cineva.

Ce se schimbă

Cele două joburi trec pe hyperice-prod-shell. În plus, deploy:production primește pe develop aceeași etichetă pe care o are deja pe main, așa că după MR-ul ăsta .gitlab-ci.yml e identic pe cele două ramuri — verificat, git diff origin/develop -- .gitlab-ci.yml e gol.

Comentariile care încă descriau o singură mașină comună sunt aduse la zi: explică separarea și de ce fiecare job care atinge /mnt/hyperice-prod poartă eticheta de producție.

Verificat

Validat cu CI lint-ul propriu al proiectului: valid: true, fără erori și fără avertismente.

De știut la merge

Pipeline-ul NU pornește: workflow.rules sare pipeline-ul când .gitlab-ci.yml e în diff. Butoanele corectate apar abia în pipeline-ul următor de pe main. Nimic de apăsat acum.

Refs #2