Amazon CodeCatalyst ist nicht mehr offen für neue Kunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Wie migriert man von CodeCatalyst.

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 Upstream-Repositorys hat.

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

Die maximale Anzahl an direkten Upstream-Repositorys, die für ein Projektarchiv 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 Punkte 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 Verzeichnis. https://npmjs.com npm-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 von npm abgerufen wurde. repo-A

Da es eine externe Upstream-Verbindung zu npm-public-registry-gateway hat https://npmjs.com, werden alle Paketversionen, aus https://npmjs.com denen importiert wird, in npm-public-registry-gateway gespeichert. Diese Paketversionen hätten von jedem Downstream-Repository mit einer Upstream-Verbindung abgerufen werden können, die zunpm-public-registry-gateway.

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

Aufbewahrung von Paketen in zwischengeschalteten Repositorys

CodeCatalyst ermöglicht es Ihnen, Upstream-Repositorys zu verketten. repo-AKann zum Beispiel repo-B als Upstream-Repository und repo-B repo-C als Upstream-Repository haben. Diese Konfiguration macht die Paketversionen in repo-B und von repo-C dort verfügbarrepo-A.

Wenn ein Paketmanager eine Verbindung zum Projektarchiv herstellt repo-A und eine Paketversion aus dem Projektarchiv abruftrepo-C, wird die Paketversion nicht im Projektarchiv gespeichert. repo-B Die Paketversion wird nur im Repository gespeichert, das am weitesten flussabwärts liegt, was in diesem Beispiel der Fall ist. repo-A Sie wird in keinen Zwischenrepositorys aufbewahrt. Das gilt auch für längere Ketten; wenn es zum Beispiel vier Repositorys gäbe:repo-A,repo-B, repo-C und ein Paketmanagerrepo-D, der damit verbunden ist, eine Paketversion von repo-A abgerufen hatrepo-D, würde die Paketversion zwar in, repo-A aber nicht in oder gespeichert. repo-B repo-C

Das Verhalten bei der Paketspeicherung ist ähnlich, wenn eine Paketversion aus einem öffentlichen Paket-Repository abgerufen wird, mit der Ausnahme, dass die Paketversion immer in dem Gateway-Repository gespeichert wird, das die direkte Upstream-Verbindung zum öffentlichen Projektarchiv hat. Zum Beispiel repo-A hat repo-B als Upstream-Repository. repo-Bhat npm-public-registry-gateway als Upstream-Repository, das eine Upstream-Verbindung zum öffentlichen Projektarchiv hat, npmjs.com; siehe das Diagramm unten.

Wenn ein Paketmanager, mit dem verbunden ist, eine bestimmte Paketversion repo-A anfordert, beispielsweise 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 dort gespeichert, da es sich um das am weitesten flussabwärts gelegene Projektarchiv handelt und repo-A npm-public-registry-gateway da es die Upstream-Verbindung zum öffentlichen externen Projektarchiv npmjs.com hat. lodash 4.17.20 wird nicht beibehalten, da es sich um ein Zwischenrepository handelt. repo-B