Ich habe dieses Handbuch zur Konfiguration der fortlaufenden Integration von GitLab verfolgt mit Jenkins.
Als Teil des Prozesses ist es notwendig, den Respec wie folgt zu setzen
+refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/ *
Warum dies notwendig ist, wird nicht in der Post erklärt, also begann ich online nach einer Erklärung zu suchen und schaute mir die offizielle Dokumentation sowie einige damit zusammenhängende Stack-Überlauf-Fragen so ein .
Trotzdem bin ich immer noch verwirrt -
Was genau ist refspec?
Und warum ist das oben genannte refspec notwendig - was macht es?
Eine refspec sagt git, wie man Referenzen von einem entfernten zum lokalen Repo mappt.
Der Wert, den Sie aufgelistet haben, war +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/* ; Also lasst uns das kaputt machen.
Sie haben zwei Muster mit einem Abstand zwischen ihnen; Das bedeutet nur, dass Sie mehrere Regeln angeben. (Das Pro-Git-Buch bezieht sich darauf als zwei Refspecs; das ist wahrscheinlich technisch korrekter. Allerdings haben Sie fast immer die Möglichkeit, mehrere Ref-Specs aufzulisten, wenn es nötig ist, so dass es im täglichen Leben wahrscheinlich keinen großen Unterschied macht.)
Das erste Muster ist dann +refs/heads/*:refs/remotes/origin/* , das aus drei Teilen besteht:
Das + bedeutet, dass die Regel ohne Fehler angewendet wird, selbst wenn dadurch ein Zielref in einer nicht schnellen Vorwärtsbewegung bewegt würde. Ich komme darauf zurück.
Der Teil vor dem : (aber nach dem + wenn es einen gibt) ist das "source" -Muster. Das ist refs/heads/* , was bedeutet, dass diese Regel für jede Remote-Referenz unter refs/heads (Bedeutung, Zweige) gilt.
Der Teil nach dem : ist das "Ziel" -Muster. Das ist refs/remotes/origin/* .
Wenn also der Ursprung eine Verzweigung master aufweist, die als refs/heads/master dargestellt wird, wird ein Remote-Zweigverweis origin/master erstellt, der als refs/remotes/origin/master dargestellt wird. Und so weiter für irgendeinen Zweignamen ( * ).
Also zurück zu dem + ... angenommen, der Ursprung hat
Sie holen und, wenn Sie diese Refspec anwenden, erhalten Sie
%Vor% (Wenn Sie typische Tracking-Regeln angewendet haben und pull angegeben haben, wird master auch auf B gezeigt.)
Jetzt passieren einige Dinge auf der Fernbedienung. Jemand hat vielleicht eine reset erstellt, die B gelöscht hat, dann C committed und dann einen Push erzwungen. So sagt die Fernbedienung
Wenn Sie holen, erhalten Sie
%Vor% und git müssen entscheiden, ob die Verschiebung von origin/master von B nach C erlaubt wird. Standardmäßig würde dies dies nicht erlauben, da es sich nicht um einen Schnellvorlauf handelt (es würde Ihnen sagen, dass es den Pull für diese Referenz abgelehnt hat), aber da die Regel mit + beginnt, wird sie akzeptiert.
(Ein Pull führt in diesem Fall zu einem Zusammenführungs-Commit.)
Das zweite Muster ist ähnlich, aber für merge-requests refs (von dem ich annehme, dass es mit der Implementierung von PRs auf Ihrem Server zusammenhängt; mir ist das nicht vertraut).
Mehr über refspecs: Ссылка
Tags und Links git jenkins gitlab git-refspec