Το git clone λειτουργεί μέσω του proxy, αλλά το Git LFS αποτυγχάνει
Παρακολουθήστε τα μεταδεδομένα και τις λήψεις αντικειμένων του Git LFS ξεχωριστά από το git clone πριν αλλάξετε έναν proxy που κατά τα άλλα λειτουργεί.
Ένα clone μπορεί να ολοκληρώσει τη μεταφορά των αντικειμένων Git ενώ το περιεχόμενό του LFS εξακολουθεί να λείπει. Το Git αποθηκεύει αρχεία δεικτών· ο πελάτης LFS κάνει ξεχωριστά αιτήματα για τα μεγάλα αντικείμενα.
Στο επηρεαζόμενο checkout με εγκατεστημένο το Git LFS, εξετάστε το endpoint του και την τελευταία αποτυχία:
git -C project lfs env
git -C project lfs logs last
Ελέγξτε την έξοδο τοπικά· τα URL και τα αρχεία καταγραφής του αποθετηρίου μπορούν να εκθέσουν πληροφορίες ταυτοποίησης ή πιστοποίησης. Προσδιορίστε το πρώτο στάδιο που απέτυχε:
- Επικοινωνία με το API του LFS.
- Λήψη της ενέργειας λήψης του Batch API.
- Πρόσβαση στο URL λήψης αυτής της ενέργειας, το οποίο μπορεί να χρησιμοποιεί διαφορετικό κεντρικό υπολογιστή αποθήκευσης αντικειμένων και παρεχόμενες κεφαλίδες.
- Μεταφορά του σώματος του αντικειμένου.
Ελέγξτε τις παρακάμψεις του endpoint LFS του αποθετηρίου καθώς και το πραγματικό URL. Το LFS έχει τη δική του υλοποίηση HTTP, διαμόρφωση και κληρονομημένο περιβάλλον proxy. Για το Git LFS 3.7.0, ακολουθήστε τη σειρά επιλογής proxy για το πραγματικό URL του αιτήματος. Η πρόσβαση στον συνηθισμένο κεντρικό υπολογιστή HTTPS του Git δεν δοκιμάζει κάθε μεταγενέστερη διαδρομή αντικειμένου. Μια αποτυχία πιστοποίησης στον κεντρικό υπολογιστή αντικειμένων διαφέρει επίσης από το proxy 407.
Όταν σκοπεύετε τις λήψεις, μια ξεχωριστή fetch σε ένα ελεγχόμενο αποθετήριο μπορεί να αποκαλύψει την αποτυχία χωρίς άλλο clone:
git -C project lfs fetch
Αυτό μεταφέρει αντικείμενα· δεν είναι ερώτημα ρυθμίσεων μόνο για ανάγνωση. Επιβεβαιώστε ότι το απαιτούμενο περιεχόμενο είναι διαθέσιμο μετά. Ένας μικρός δείκτης που παραμένει σε ένα μερικό checkout δεν είναι το μεγάλο αρχείο, και μια προηγούμενη επιτυχημένη εντολή Git δεν μπορεί να αποδείξει ότι η μεταφορά LFS ολοκληρώθηκε.