Fiecare job CI primește propriul fișier de credențiale docker

Închide #32 (closed).

Ambele joburi de imagine rulează pe același runner shell și împărțeau ~/.docker/config.json al utilizatorului. Se autentifică unul după altul, al doilea îl suprascrie pe primul, iar când al doilea job se termină GitLab îi revocă CI_JOB_TOKEN — celălalt rămâne să facă push cu credențiale moarte.

Eșecul e unauthorized: HTTP Basic: Access denied după un build care reușise, cade pe oricare job se termină al doilea, și sare deploy-ul pentru acel commit. S-a întâmplat azi: pipeline-ul 8106 a pierdut un deploy de producție exact așa.

DOCKER_CONFIG propriu pentru fiecare job, plus curățenie după. În afara lui $CI_PROJECT_DIR, deliberat: joburile de imagine construiesc cu rădăcina repo-ului drept context, deci un fișier de credențiale scris acolo ar ajunge la daemon odată cu restul.

deploy:production rulează pe alt runner (hyperice-prod-shell), deci nu putea intra în cursa asta — dar primește aceeași izolare, ca să nu depindă de care job pe care mașină.

Atenție: acest MR nu primește pipeline. workflow.rules din .gitlab-ci.yml spune changes: [.gitlab-ci.yml] → when: never, deci orice modificare a fișierului își sare propria verificare. Efectul se vede la primul pipeline de pe main de după fuziune.

Verificat local: YAML valid (yaml.safe_load), DOCKER_CONFIG într-un singur loc, patru curățenii after_script — câte una pentru fiecare job care face docker login.