Bonjour,
Ce serait top si le runner avait accès à docker, en plus de tourner dans un container docker (cet appel de gitlab-runner register illustre ce que je veux dire).C’est un risque clair de corruption pour l’intégrité du host qui fait tourner le runner, ça revient a donner les droits root a tout les jobs. Pour ça c’est peut etre mieux de prendre une VM et de la reset de temps à autre avec un snapshot. En pratique il faudrait vraiment une attaque ciblée pour en tirer partie donc la probabilité reste hyper faible.
En cas de corruption ça ne touche pas aux repos puisque le job est en lecture seule donc les dégats sont AMHA très limités.
L’interet d’avoir accès à docker est pour moi très immédiat: je peux faire un test d’integration pour HATVP qui lance un container postgresql tout neuf pour vérifier que l’import avec cvs2sql fonctionne, par exemple. Sinon il faut que j’installe et configure postgresql dans mon container de test et c’est plus de travail.
Je pourrais avoir recours au fichier gitlab-ci.yml pour disposer du container postgresql. Mais j’aime pas ça parce que ça ne permet pas de faire tourner les tests localement. Je prefere de loin que gitlab-ci.yml lance un script run-test.sh dont la seule dépendance est docker. Ca peut tourner dans gitlab mais aussi sur n’importe quel OS qui a docker.
Des objections ?
).