Panoramica dei pacchetti - CodeArtifact

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Panoramica dei pacchetti

Un pacchetto è un insieme di software e metadati necessari per risolvere le dipendenze e installare il software. In CodeArtifact, un pacchetto è costituito da un nome di pacchetto, uno spazio dei nomi opzionale come @types in@types/node, un set di versioni del pacchetto e metadati a livello di pacchetto come i tag npm.

Formati di pacchetto supportati

AWS CodeArtifact supporta npm, PyPI, Maven, Swift, Ruby NuGet, formati di pacchetti generici.

Pubblicazione di pacchetti

È possibile pubblicare nuove versioni di qualsiasi formato di pacchetto supportato in un CodeArtifact repository utilizzando strumenti comenpm,twine,Maven, Gradlenuget, edotnet.

Autorizzazioni di pubblicazione

L'utente o il ruolo AWS Identity and Access Management (IAM) deve disporre delle autorizzazioni per la pubblicazione nell'archivio di destinazione. Per pubblicare i pacchetti sono necessarie le seguenti autorizzazioni:

  • Maven: e codeartifact:PublishPackageVersion codeartifact:PutPackageMetadata

  • npm: codeartifact:PublishPackageVersion

  • NuGet: codeartifact:PublishPackageVersion e codeartifact:ReadFromRepository

  • Python: codeartifact:PublishPackageVersion

  • generico: codeartifact:PublishPackageVersion

  • Rapido: codeartifact:PublishPackageVersion

  • Rubino: codeartifact:PublishPackageVersion

Nell'elenco precedente di autorizzazioni, la policy IAM deve specificare la package risorsa per le codeartifact:PublishPackageVersion autorizzazioni and. codeartifact:PutPackageMetadata Deve inoltre specificare la repository risorsa per l'autorizzazione. codeartifact:ReadFromRepository

Per ulteriori informazioni sulle autorizzazioni in CodeArtifact, vedereAWS CodeArtifact riferimento alle autorizzazioni.

Sovrascrivere le risorse del

Non è possibile ripubblicare una risorsa del pacchetto già esistente con contenuti diversi. Ad esempio, supponete di aver già pubblicato un pacchetto Maven con una risorsa JAR. mypackage-1.0.jar Puoi pubblicare nuovamente quella risorsa solo se il checksum delle risorse vecchie e nuove è identico. Per ripubblicare la stessa risorsa con nuovi contenuti, eliminate prima la versione del pacchetto utilizzando il delete-package-versions comando. Il tentativo di ripubblicare lo stesso nome di risorsa con contenuti diversi genererà un errore di conflitto HTTP 409.

Per i formati di pacchetto che supportano più risorse (generico, PyPI e Maven), puoi aggiungere nuove risorse con nomi diversi a una versione del pacchetto esistente, supponendo che tu disponga delle autorizzazioni richieste. Per i pacchetti generici, potete aggiungere nuove risorse purché la versione del pacchetto sia nello stato. Unfinished Poiché npm supporta solo una singola risorsa per versione del pacchetto, per modificare in qualsiasi modo una versione del pacchetto pubblicata, devi prima eliminarla utilizzandodelete-package-versions.

Se provate a ripubblicare una risorsa già esistente (ad esempiomypackage-1.0.jar) e il contenuto della risorsa pubblicata e della nuova risorsa sono identici, l'operazione avrà successo perché l'operazione è idempotente.

Pacchetti privati e archivi pubblici

CodeArtifact non pubblica i pacchetti archiviati negli CodeArtifact archivi in archivi pubblici come npmjs.com o Maven Central. CodeArtifact importa pacchetti da repository pubblici a un CodeArtifact repository, ma non sposta mai i pacchetti nella direzione opposta. I pacchetti pubblicati CodeArtifact negli archivi rimangono privati e sono disponibili solo per AWS gli account, i ruoli e gli utenti a cui hai concesso l'accesso.

Pubblicazione di versioni di pacchetti con patch

A volte potresti voler pubblicare una versione modificata del pacchetto, potenzialmente disponibile in un archivio pubblico. Ad esempio, potreste aver trovato un bug in una dipendenza critica dell'applicazione chiamata mydep 1.1 e dovete correggerlo prima che il fornitore del pacchetto possa esaminare e accettare la modifica. Come descritto in precedenza, CodeArtifact impedisce la pubblicazione mydep 1.1 nel CodeArtifact repository se l'archivio pubblico è raggiungibile dal repository tramite repository upstream e una CodeArtifact connessione esterna.

Per ovviare a questo problema, pubblica la versione del pacchetto in un CodeArtifact repository diverso in cui l'archivio pubblico non è raggiungibile. Quindi usa l'copy-package-versionsAPI per copiare la versione con patch nel CodeArtifact repository mydep 1.1 da cui la consumerai.

Limiti di dimensione degli asset per la pubblicazione

La dimensione massima di una risorsa del pacchetto che può essere pubblicata è limitata dalla quota massima per le dimensioni del file Asset mostrata inQuote in AWS CodeArtifact. Ad esempio, non potete pubblicare una ruota Maven JAR o Python più grande della dimensione massima del file di asset corrente. Se devi archiviare risorse più grandi in CodeArtifact, richiedi un aumento della quota.

Oltre alla quota massima per la dimensione del file di asset, la dimensione massima di una richiesta di pubblicazione per i pacchetti npm è di 2 GB. Questo limite è indipendente dalla quota massima per la dimensione del file di asset e non può essere aumentato con un aumento della quota. In una richiesta di pubblicazione npm (HTTP PUT), i metadati del pacchetto e il contenuto dell'archivio tar del pacchetto npm sono raggruppati insieme. Per questo motivo, la dimensione massima effettiva di un pacchetto npm che può essere pubblicato varia e dipende dalla dimensione dei metadati inclusi.

Nota

I pacchetti npm pubblicati sono limitati a una dimensione massima inferiore a 2 GB.

Latenza di pubblicazione

Le versioni dei pacchetti pubblicate in un CodeArtifact repository sono spesso disponibili per il download in meno di un secondo. Ad esempio, se si pubblica una versione del pacchetto npm su CodeArtifact withnpm publish, tale versione dovrebbe essere disponibile per un npm install comando in meno di un secondo. Tuttavia, la pubblicazione può essere incoerente e talvolta può richiedere più tempo. Se dovete utilizzare una versione del pacchetto subito dopo la pubblicazione, utilizzate nuovi tentativi per assicurarvi che il download sia affidabile. Ad esempio, dopo aver pubblicato la versione del pacchetto, ripeti il download fino a tre volte se la versione del pacchetto appena pubblicata non è inizialmente disponibile al primo tentativo di download.

Nota

L'importazione di una versione del pacchetto da un archivio pubblico richiede in genere più tempo della pubblicazione. Per ulteriori informazioni, consulta More latenza di connessione.

Stato della versione del pacchetto

Ogni versione del pacchetto in CodeArtifact ha uno stato che descrive lo stato corrente e la disponibilità della versione del pacchetto. È possibile modificare lo stato della versione del pacchetto in AWS CLI and SDK. Per ulteriori informazioni, consulta Aggiorna lo stato della versione del pacchetto.

Di seguito sono riportati i valori possibili per lo stato della versione del pacchetto:

  • Pubblicato: la versione del pacchetto è stata pubblicata correttamente e può essere richiesta utilizzando un gestore di pacchetti. La versione del pacchetto verrà inclusa negli elenchi delle versioni dei pacchetti restituiti ai gestori di pacchetti, ad esempio, nell'output dinpm view <package-name> versions. Tutte le risorse della versione del pacchetto sono disponibili nel repository.

  • Incompiuto: il client ha caricato una o più risorse per una versione del pacchetto, ma non l'ha finalizzata spostandola nello stato. Published Attualmente solo le versioni generiche e del pacchetto Maven possono avere lo stato di. Unfinished Per i pacchetti Maven, ciò può verificarsi quando il client carica una o più risorse per una versione del pacchetto ma non pubblica un maven-metadata.xml file per il pacchetto che include quella versione. Quando una versione del pacchetto Maven è incompleta, non verrà inclusa negli elenchi di versioni restituiti ai client di questo tipo mvn ogradle, quindi non può essere utilizzata come parte di una build. I pacchetti generici possono essere mantenuti deliberatamente Unfinished nello stato fornendo il unfinished flag quando si chiama l'API. PublishPackageVersion Un pacchetto generico può essere modificato in Published stato omettendo il unfinished flag o chiamando l'UpdatePackageVersionsStatusAPI.

  • Non in elenco: le risorse della versione del pacchetto possono essere scaricate dal repository, ma la versione del pacchetto non è inclusa nell'elenco delle versioni restituite ai gestori di pacchetti. Ad esempio, per un pacchetto npm, l'output di non npm view <package-name> versions includerà la versione del pacchetto. Ciò significa che la logica di risoluzione delle dipendenze di npm non selezionerà la versione del pacchetto perché la versione non appare nell'elenco delle versioni disponibili. Tuttavia, se la versione del pacchetto Unlisted è già referenziata in un npm package-lock.json file, può comunque essere scaricata e installata, ad esempio, durante l'esecuzione. npm ci

  • Archiviata: le risorse della versione del pacchetto non possono più essere scaricate. La versione del pacchetto non verrà inclusa nell'elenco delle versioni restituite ai gestori di pacchetti. Poiché gli asset non sono disponibili, il consumo della versione del pacchetto da parte dei client è bloccato. Se la build dell'applicazione dipende da una versione aggiornata a Archived, la build si interromperà, supponendo che la versione del pacchetto non sia stata memorizzata nella cache locale. Non è possibile utilizzare un gestore di pacchetti o uno strumento di compilazione per ripubblicare una versione del pacchetto archiviata perché è ancora presente nel repository, ma è possibile modificare lo stato della versione del pacchetto riportandola a Non elencata o Pubblicata con l'API. UpdatePackageVersionsStatus

  • Eliminata: la versione del pacchetto non viene visualizzata negli elenchi e le risorse non possono essere scaricate dall'archivio. La differenza fondamentale tra Disposed e Archived è che con lo stato Disposed, le risorse della versione del pacchetto verranno eliminate definitivamente da. CodeArtifact Per questo motivo, non è possibile spostare una versione del pacchetto da Disposed a Archiviata, Non elencata o Pubblicata. La versione del pacchetto non può più essere utilizzata perché le risorse sono state eliminate. Dopo che una versione del pacchetto è stata contrassegnata come Disposta, non ti verrà più addebitato alcun costo per l'archiviazione delle risorse del pacchetto.

Le versioni del pacchetto di tutti gli stati verranno restituite per impostazione predefinita quando si chiama list-package-versions senza --status parametri.

Oltre agli stati elencati in precedenza, è possibile eliminare anche una versione del pacchetto con l'DeletePackageVersionsAPI. Dopo l'eliminazione, una versione del pacchetto non è più presente nell'archivio ed è possibile ripubblicare liberamente quella versione del pacchetto utilizzando un gestore di pacchetti o uno strumento di compilazione. Dopo l'eliminazione di una versione del pacchetto, non ti verrà più addebitato alcun costo per l'archiviazione delle risorse di quella versione del pacchetto.

Nome del pacchetto, versione del pacchetto e normalizzazione del nome dell'asset

CodeArtifact normalizza i nomi dei pacchetti, le versioni dei pacchetti e i nomi delle risorse prima di archiviarli, il che significa che i nomi o le versioni CodeArtifact possono essere diversi dal nome o dalla versione forniti al momento della pubblicazione del pacchetto. Per ulteriori informazioni su come vengono normalizzati i nomi e le versioni CodeArtifact per ogni tipo di pacchetto, consultate la seguente documentazione:

CodeArtifact non esegue la normalizzazione su altri formati di pacchetti.