Nachteile von flachem Klonen auf Travis und anderen CI-Diensten?

Question

Die meisten CI-Dienste bieten eine Möglichkeit, ein Repository flach zu klonen. Zum Beispiel auf Travis:

git: 
    depth: 1 

oder auf AppVeyor:

clone_depth: 1 
or 
shallow_clone: true 

Dies hat den offensichtlichen Vorteil der Geschwindigkeit, da Sie nicht das gesamte Repository klonen müssen.

Gibt es Nachteile für oberflächliches Klonen bei CI-Diensten? Gibt es eine Situation, in der ein oberflächlicher Klon einen CI-Build zum Scheitern bringen würde? Warum wird die Standardeinstellung für diese CI-Dienste nicht flach geklont?

Answer 1

Es gibt zwei Gründe, warum es normalerweise nicht passiert.

Erstens unterscheidet sich der Hash eines flachen Klons von jeder Version, die Sie möglicherweise im Repository haben. Daher ist es nicht möglich, einen Build, den Sie mit einem bestimmten Ergebnis erstellt haben, nachzuverfolgen.

Zweitens haben die meisten Git-Server die Möglichkeit, das optimierte 'everything.pack' zu senden, wenn Sie keine Details haben. Andernfalls muss der Server ein benutzerdefiniertes Commit-Paket bereitstellen, das nur Ihre flache Kopie enthält, die an Sie gesendet wird. Obwohl möglicherweise mehr Daten über die Leitung übertragen werden, kann dies tatsächlich zu mehr Arbeit auf dem Server führen.

Schließlich werden viele CI-Builds eine Art Tag-Operation durchführen und in das Repository hochladen, und Sie können praktisch keinen flachen Klon markieren (siehe Punkt 1).

Answer 2

zu AlBlue Antwort hinzu:

Ein weiteres Problem besteht darin, dass die Klon Tiefeneinstellung auch für git-Modul verwendet wird.

In Projekten, die git Submodul verwenden, wird Travis, etc. das Submodul Repo vom Master klonen und dann die spezifische Revision auschecken.

Wenn das Commit, auf das wir im Submodul zeigen, nicht innerhalb von n Commits des aktuellen Masters liegt (wobei n für die Tiefeneinstellung steht), wird die Überprüfung fehlschlagen.