Hi,
Ich würde gerne nochmal an das Ticket erinnern. Wenn wir dafür ein Workaround finden können wir den v0.1 Milestone abschließen.
Ich habe mir da jetzt gerade auf der Zugfahrt von Oldenburg nach Emden ein Workaround ausgedacht der denke ich einfach zu verstehen ist und dennoch die nötige Sicherheit gibt, das nicht aus versehenen ungewollte Änderungen auf die Server deployt werden.
ausgehend vom puppet repo würde ich folgendes umsetzen. Wenn niemand was dagegen hat.
Entwickelt wird im master ganz normal nach dem gitlab workflow. Wenn es fertige Änderungen gibt z.b. Milestone ist erreicht oder kleinere Features sind vollständig können diese fertigen Änderungen via git merge oder cherry-pick in Produktion gezogen werden. gibt es einen aktiven zustand der puppet-Master ausgerollen soll, so würde ich vorschlagen das die zu den o.g. zustand gehörende commit-ID entsprechend mit einem tag versehen wird. Tag style würde ich folgende Notation vorschlagen vX.X z.B. v0.1 <-- das würde dem Milestone entsprechen. gibt es kleinere änderungen die außerhalb des Milestons in aktion gehen sollen so würde ich diese einfach als Mijor version an einen neunen tag hägen z.B. v0.1.1 Das v0.1 sagt dann aus, auf welchen Milestone der Puppetmaster gerade ist und das folgende also .1 nach 0.1 zeigt die nachträgliche Änderung die auf dem Milestone setzt.
Wird ein neuer Tag gesetzt und in den Upstream gepusht, so kann irgendjemand der den nötigen rechte hat auf dem puppetmaster Server einfach ein git pull machen und anschließend mit git checkout die nächst neuerer Version auschecken. Somit sollte die Gefahr stark minimiert werden jemand aus verseht via puppet alle Server auf einmal kaputt macht.
Schönen Gruß :) Tarek