Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Eine Paketversion mit Upstream-Repositorys anfordern

Das folgende Beispiel zeigt die möglichen Szenarien, wenn ein Paketmanager ein Paket aus einem CodeCatalyst Paket-Repository anfordert, das über Upstream-Repositorys verfügt.

In diesem Beispiel fordert ein Paketmanager beispielsweise eine Paketversion von einem Paket-Repository mit dem Namen annpm, downstream das mehrere Upstream-Repositorys hat. Wenn das Paket angefordert wird, kann Folgendes passieren:

Die maximale Anzahl von direkten Upstream-Repositorys, die für ein Repository zulässig sind, ist 10. Die maximale Anzahl von Repositorys, in denen CodeCatalyst gesucht wird, wenn eine Paketversion angefordert wird, ist 25.

Aufbewahrung von Paketen aus Upstream-Repositorys

Wenn eine angeforderte Paketversion in einem Upstream-Repository gefunden wird, wird ein Verweis darauf beibehalten und ist immer in dem Repository verfügbar, das sie angefordert hat. Dadurch wird sichergestellt, dass Sie Zugriff auf Ihre Pakete haben, falls es zu einem unerwarteten Ausfall des Upstream-Repositorys kommt. Die beibehaltene Paketversion ist von keinem der folgenden Faktoren betroffen:

Pakete über eine Upstream-Beziehung abrufen

CodeCatalyst kann Pakete über mehrere verknüpfte Repositorys abrufen, die als Upstream-Repositorys bezeichnet werden. Wenn ein CodeCatalyst Paket-Repository eine Upstream-Verbindung zu einem anderen CodeCatalyst Paket-Repository hat, das eine Upstream-Verbindung zu einem Gateway-Repository hat, werden Anfragen für Pakete, die sich nicht im Upstream-Repository befinden, aus dem externen Repository kopiert. Stellen Sie sich zum Beispiel die folgende Konfiguration vor: Ein Repository mit dem Namen repo-A hat eine Upstream-Verbindung zum Gateway-Repository,npm-public-registry-gateway. npm-public-registry-gatewayhat eine Upstream-Verbindung zum öffentlichen Paket-Repository, https://npmjs.com.

Wenn npm es für die Verwendung des repo-A Repositorys konfiguriert ist, npm install initiiert das Ausführen das Kopieren von Paketen aus dem https://npmjs.comnpm-public-registry-gateway Die installierten Versionen werden ebenfalls abgerufen. repo-A Das folgende Beispiel wird installiertlodash.

$ npm config get registry
https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s

repo-AEnthält nach der Ausführung npm install nur die neueste Version (lodash 4.17.20), da dies die Version ist, die npm von repo-A abgerufen wurde.

Da npm-public-registry-gateway über eine externe Upstream-Verbindung verfügt https://npmjs.com, werden alle Paketversionen, aus https://npmjs.comdenen importiert wurde, in npm-public-registry-gateway gespeichert. Diese Paketversionen könnten von jedem Downstream-Repository abgerufen worden sein, zu npm-public-registry-gateway dem eine Upstream-Verbindung führt.

Der Inhalt von npm-public-registry-gateway bietet Ihnen die Möglichkeit, alle Pakete und Paketversionen zu sehen, aus denen https://npmjs.comim Laufe der Zeit importiert wurde.

Aufbewahrung von Paketen in Zwischenrepositorien

CodeCatalyst ermöglicht es Ihnen, Upstream-Repositorys zu verketten. repo-AKann zum Beispiel repo-B als Upstream-Repository und repo-B als Upstream-Repository verwendet werden. repo-C Diese Konfiguration macht die Paketversionen in repo-B und repo-C verfügbar vonrepo-A.

Wenn ein Paketmanager eine Verbindung zum Repository herstellt repo-A und eine Paketversion aus dem Repository abruftrepo-C, wird die Paketversion nicht im Repository gespeichert. repo-B Die Paketversion wird nur im Repository gespeichert, das sich am weitesten unten befindet, was in diesem Beispiel der Fall ist. repo-A Sie wird in keinen Zwischenrepositorien aufbewahrt. Dies gilt auch für längere Ketten. Wenn es beispielsweise vier Repositorien gäbe:repo-A,, undrepo-B, repo-C und ein Paketmanagerrepo-D, der verbunden ist, um eine Paketversion repo-A abzurufenrepo-D, würde die Paketversion in oder gespeichert, repo-A aber nicht in oder. repo-B repo-C

Das Verhalten bei der Paketaufbewahrung ist ähnlich, wenn eine Paketversion aus einem öffentlichen Paket-Repository abgerufen wird, mit der Ausnahme, dass die Paketversion immer im Gateway-Repository aufbewahrt wird, das die direkte Upstream-Verbindung zum öffentlichen Repository hat. repo-AHat repo-B zum Beispiel ein Upstream-Repository. repo-Bhat npm-public-registry-gateway als Upstream-Repository, das über eine Upstream-Verbindung zum öffentlichen Repository npmjs.com verfügt; siehe Abbildung unten.

Wenn ein Paketmanager, der eine Verbindung herstellt, eine bestimmte Paketversion repo-A anfordert, zum Beispiel Lodash 4.17.20, und die Paketversion in keinem der drei Repositorys vorhanden ist, wird sie von npmjs.com abgerufen. Wenn Lodash 4.17.20 abgerufen wird, wird es beibehalten, da es das am weitesten nachgeschaltete Repository ist und repo-A npm-public-registry-gateway da es die Upstream-Verbindung zum öffentlichen externen Repository, npmjs.com, hat. lodash 4.17.20 wird nicht beibehalten, da es sich um ein Zwischenarchiv handelt. repo-B