\n
... more content ... \n",
"versionRevision": "REVISION-SAMPLE-55C752BEE9B772FC"
}
```
# Aggiorna lo 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 utilizzando AWS CLI sia la console che la console.
**Nota**
Per ulteriori informazioni sullo stato della versione del pacchetto, incluso un elenco degli stati disponibili, vedere[Stato della versione del pacchetto](packages-overview.md#package-version-status).
## Aggiornamento dello stato della versione del pacchetto
L'impostazione dello stato di una versione del pacchetto consente di controllare come una versione del pacchetto può essere utilizzata senza eliminarla completamente dal repository. Ad esempio, quando la versione di un pacchetto ha lo stato di`Unlisted`, può comunque essere scaricata normalmente, ma non verrà visualizzata negli elenchi delle versioni del pacchetto restituiti a comandi come. `npm view` L'[UpdatePackageVersionsStatus API](https://docs.aws.amazon.com/codeartifact/latest/APIReference/API_UpdatePackageVersionsStatus.html) consente di impostare lo stato della versione del pacchetto di più versioni dello stesso pacchetto in un'unica chiamata API. Per una descrizione dei diversi stati, vedere[Panoramica dei pacchetti](packages-overview.md).
Utilizzate il `update-package-versions-status` comando per modificare lo stato di una versione del pacchetto in `Published``Unlisted`, o`Archived`. Per visualizzare le autorizzazioni IAM necessarie per utilizzare il comando, consulta[Autorizzazioni IAM richieste per aggiornare lo stato della versione di un pacchetto](#update-package-version-status-iam). L'esempio seguente imposta lo stato della versione 4.1.0 del pacchetto npm su. `chalk` `Archived`
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 --target-status Archived
```
Output di esempio:
```
{
"successfulVersions": {
"4.1.0": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
Questo esempio utilizza un pacchetto npm, ma il comando funziona in modo identico per altri formati. È possibile spostare più versioni allo stesso stato di destinazione utilizzando un singolo comando, vedi l'esempio seguente.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 4.1.1 --target-status Archived
```
Output di esempio:
```
{
"successfulVersions": {
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Archived"
},
"4.1.1": {
"revision": "+Oz8skWbwY3k8M6SrNIqNj6bVH/ax+CxvkJx+No5j8I=",
"status": "Archived"
}
},
"failedVersions": {}
}
```
Nota che una volta pubblicata, una versione del pacchetto non può essere riportata allo `Unfinished` stato, quindi questo stato non è consentito come valore per il `--target-status` parametro. Per spostare la versione del pacchetto nello `Disposed` stato, utilizzate invece il `dispose-package-versions` comando come descritto di seguito.
## Autorizzazioni IAM richieste per aggiornare lo stato della versione di un pacchetto
`update-package-versions-status`Per richiedere un pacchetto, è necessario disporre dell'`codeartifact:UpdatePackageVersionsStatus`autorizzazione sulla risorsa del pacchetto. Ciò significa che è possibile concedere l'autorizzazione alla chiamata `update-package-versions-status` in base al pacchetto. Ad esempio, una policy IAM che conceda il permesso di chiamare `update-package-versions-status` il pacchetto npm *chalk* includerebbe un'istruzione come la seguente.
```
{
"Action": [
"codeartifact:UpdatePackageVersionsStatus"
],
"Effect": "Allow",
"Resource": "arn:aws:codeartifact:us-east-1:111122223333:package/my_domain/my_repo/npm//chalk"
}
```
## Aggiornamento dello stato di un pacchetto npm con ambito
Per aggiornare lo stato della versione del pacchetto di una versione del pacchetto npm con un ambito, usa il parametro. `--namespace` Ad esempio, per rimuovere la versione 8.0.0 di`@nestjs/core`, utilizzate il comando seguente.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --namespace nestjs
--package core --versions 8.0.0 --target-status Unlisted
```
## Aggiornamento dello stato di un pacchetto Maven
I pacchetti Maven hanno sempre un ID di gruppo, che viene chiamato namespace in. CodeArtifact Usa il `--namespace` parametro per specificare l'ID del gruppo Maven durante la chiamata. `update-package-versions-status` Ad esempio, per archiviare la versione 2.13.1 del pacchetto `org.apache.logging.log4j:log4j` Maven, utilizzare il comando seguente.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format maven
--namespace org.apache.logging.log4j --package log4j
--versions 2.13.1 --target-status Archived
```
## Specificare una revisione della versione del pacchetto
Una revisione della versione del pacchetto è una stringa che specifica un insieme specifico di risorse e metadati per una versione del pacchetto. È possibile specificare una revisione della versione del pacchetto per aggiornare lo stato delle versioni del pacchetto che si trovano in uno stato specifico. Per specificare una revisione della versione del pacchetto, utilizzate il `--version-revisions` parametro per passare una o più versioni del pacchetto separate da virgole e le coppie di revisione delle versioni del pacchetto. Lo stato di una versione del pacchetto verrà aggiornato solo se la revisione corrente della versione del pacchetto corrisponde al valore specificato.
**Nota**
Il `—-versions` parametro deve essere definito anche quando si utilizza il `--version-revisions` parametro.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8bzVMJ4="
--versions 4.1.0 --target-status Archived
```
Per aggiornare più versioni con un solo comando, passate un elenco separato da virgole di coppie di versioni e revisioni di versione alle opzioni. `--version-revisions` Il comando di esempio seguente definisce due diverse coppie di versione del pacchetto e di revisione della versione del pacchetto.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm
--package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=,4.0.0=E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc="
--versions 4.1.0 4.0.0 --target-status Published
```
Output di esempio:
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Published"
},
"4.1.0": {
"revision": "25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=",
"status": "Published"
}
},
"failedVersions": {}
}
```
Quando si aggiornano più versioni del pacchetto, le versioni passate `--version-revisions` devono essere le stesse a `--versions` cui è stato passato. Se una revisione viene specificata in modo errato, lo stato di quella versione non verrà aggiornato.
## Utilizzo del parametro di stato previsto
Il `update-package-versions-status` comando fornisce il `--expected-status` parametro che supporta la specificazione dello stato corrente previsto di una versione del pacchetto. Se lo stato corrente non corrisponde al valore passato`--expected-status`, lo stato di quella versione del pacchetto non verrà aggiornato.
Ad esempio*my\$1repo*, nelle versioni 4.0.0 e 4.1.0 del pacchetto npm `chalk` attualmente hanno uno stato di. `Published` Una chiamata a `update-package-versions-status` ciò specifica uno stato previsto di non `Unlisted` riuscirà ad aggiornare entrambe le versioni del pacchetto a causa della mancata corrispondenza dello stato.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo --format npm --package chalk
--versions 4.1.0 4.0.0 --target-status Archived --expected-status Unlisted
```
Output di esempio:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
},
"4.1.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
## Errori con le singole versioni del pacchetto
Esistono diversi motivi per cui lo stato di una versione del pacchetto non viene aggiornato durante la chiamata`update-package-versions-status`. Ad esempio, la revisione della versione del pacchetto potrebbe essere stata specificata in modo errato o lo stato previsto non corrisponde allo stato corrente. In questi casi, la versione verrà inclusa nella `failedVersions` mappa nella risposta dell'API. Se una versione fallisce, è possibile che le altre versioni specificate nella stessa chiamata a `update-package-versions-status` vengano ignorate e il loro stato non sia aggiornato. Tali versioni verranno incluse anche nella `failedVersions` mappa con un `errorCode` di`SKIPPED`.
Nell'attuale implementazione di`update-package-versions-status`, se non è possibile modificare lo stato di una o più versioni, tutte le altre versioni verranno ignorate. Cioè, tutte le versioni vengono aggiornate correttamente o nessuna versione viene aggiornata. Questo comportamento non è garantito nel contratto API; in futuro, alcune versioni potrebbero avere successo mentre altre versioni falliranno in una singola chiamata a`update-package-versions-status`.
Il comando di esempio seguente include un errore di aggiornamento dello stato della versione causato da una mancata corrispondenza della versione della versione del pacchetto. Questo errore di aggiornamento fa sì che un'altra chiamata di aggiornamento dello stato della versione venga ignorata.
```
aws codeartifact update-package-versions-status --domain my_domain
--domain-owner 111122223333 --repository my_repo
--format npm --package chalk
--version-revisions "4.1.0=25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ=,4.0.0=E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc="
--versions 4.1.0 4.0.0 --target-status Archived
```
Output di esempio:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "SKIPPED",
"errorMessage": "version 4.0.0 is skipped"
},
"4.1.0": {
"errorCode": "MISMATCHED_REVISION",
"errorMessage": "current revision: 25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ4=, expected revision: 25/UjBleHs1DZewk+zozoeqH/R80Rc9gL1P8vbzVMJ="
}
}
}
```
## Eliminazione delle versioni dei pacchetti
Lo stato del `Disposed` pacchetto ha un comportamento simile a`Archived`, tranne per il fatto che gli asset del pacchetto verranno eliminati definitivamente, CodeArtifact in modo che all'account del proprietario del dominio non venga più addebitato lo spazio di archiviazione degli asset. Per ulteriori informazioni sullo stato di ogni versione del pacchetto, consulta[Stato della versione del pacchetto](packages-overview.md#package-version-status). Per modificare lo stato di una versione del pacchetto in`Disposed`, usa il `dispose-package-versions` comando. Questa funzionalità è distinta dal `update-package-versions-status` fatto che lo smaltimento di una versione del pacchetto non è reversibile. Poiché le risorse del pacchetto verranno eliminate, lo stato della versione non può essere ripristinato in `Archived``Unlisted`, o. `Published` L'unica azione che può essere eseguita su una versione del pacchetto che è stata eliminata è eliminarla utilizzando il `delete-package-versions` comando.
Per chiamare `dispose-package-versions` correttamente, il principale IAM chiamante deve disporre dell'`codeartifact:DisposePackageVersions`autorizzazione sulla risorsa del pacchetto.
Il comportamento del `dispose-package-versions` comando è simile`update-package-versions-status`, incluso il comportamento delle `--expected-status` opzioni `--version-revisions ` e descritte nelle sezioni sulla [revisione della versione](#update-status-specify-package-version-revision) e [sullo stato previsto](#using-expected-status). Ad esempio, il comando seguente tenta di eliminare una versione del pacchetto ma fallisce a causa di uno stato previsto non corrispondente.
```
aws codeartifact dispose-package-versions —domain my_domain --domain-owner 111122223333
--repository my_repo --format npm --package chalk --versions 4.0.0
--expected-status Unlisted
```
Output di esempio:
```
{
"successfulVersions": {},
"failedVersions": {
"4.0.0": {
"errorCode": "MISMATCHED_STATUS",
"errorMessage": "current status: Published, expected status: Unlisted"
}
}
}
```
Se lo stesso comando viene eseguito nuovamente con un `--expected-status` of`Published`, l'eliminazione avrà esito positivo.
```
aws codeartifact dispose-package-versions —domain my_domain --domain-owner 111122223333
--repository my_repo --format npm --package chalk --versions 4.0.0
--expected-status Published
```
Output di esempio:
```
{
"successfulVersions": {
"4.0.0": {
"revision": "E3lhBp0RObRTut4pkjV5c1AQGkgSA7Oxtil6hMMzelc=",
"status": "Disposed"
}
},
"failedVersions": {}
}
```
# Modifica dei controlli di origine dei pacchetti
In AWS CodeArtifact, le versioni dei pacchetti possono essere aggiunte a un repository pubblicandole direttamente, estraendole da un repository upstream o importandole da un archivio pubblico esterno. Consentire l'aggiunta di versioni di pacchetto di un pacchetto sia mediante la pubblicazione diretta che l'importazione da archivi pubblici rende vulnerabili a un attacco di sostituzione delle dipendenze. Per ulteriori informazioni, consulta [Attacchi di sostituzione delle dipendenze](dependency-substitution-attacks.md). Per proteggersi da un attacco di sostituzione delle dipendenze, è possibile configurare i controlli di origine dei pacchetti su un pacchetto in un repository per limitare il modo in cui le versioni di quel pacchetto possono essere aggiunte al repository.
La configurazione dei controlli di origine dei pacchetti dovrebbe essere presa in considerazione da qualsiasi team che desideri consentire alle nuove versioni di pacchetti diversi di provenire sia da fonti interne, come la pubblicazione diretta, sia da fonti esterne, come gli archivi pubblici. Per impostazione predefinita, i controlli di origine dei pacchetti verranno configurati in base al modo in cui la prima versione di un pacchetto viene aggiunta all'archivio. Per informazioni sulle impostazioni del controllo dell'origine del pacchetto e sui relativi valori predefiniti, vedere[Impostazioni di controllo dell'origine del pacchetto](#package-origin-control-settings).
Per rimuovere il record del pacchetto dopo aver utilizzato l'operazione `put-package-origin-configuration` API, utilizzare `delete-package` (vedi[Eliminare un pacchetto o una versione del pacchetto](delete-package.md)).
## Scenari comuni di controllo dell'accesso ai pacchetti
Questa sezione include alcuni scenari comuni in cui una versione del pacchetto viene aggiunta a un CodeArtifact repository. Le impostazioni di controllo dell'origine dei pacchetti verranno impostate per i nuovi pacchetti a seconda di come viene aggiunta la prima versione del pacchetto.
Negli scenari seguenti, un *pacchetto interno* è un pacchetto pubblicato direttamente da un gestore di pacchetti nel repository, ad esempio un pacchetto creato e gestito dall'utente o dal suo team. Un *pacchetto esterno* è un pacchetto esistente in un archivio pubblico che può essere inserito nel tuo repository con una connessione esterna.
**Viene pubblicata una versione esterna del pacchetto per un pacchetto interno esistente**
In questo scenario, si consideri un pacchetto interno, *PackageA*. Il tuo team pubblica la prima versione del pacchetto per *PackageA* in un repository. CodeArtifact **Poiché questa è la prima versione del pacchetto, le impostazioni di controllo dell'origine del pacchetto vengono impostate automaticamente su **Pubblica: Consenti e Upstream:** Block.** Dopo che il pacchetto è presente nel repository, un pacchetto con lo stesso nome viene pubblicato in un archivio pubblico collegato al repository. CodeArtifact Potrebbe trattarsi di un tentativo di attacco di sostituzione delle dipendenze contro il pacchetto interno o potrebbe essere solo una coincidenza. Indipendentemente da ciò, i controlli di origine dei pacchetti sono configurati per bloccare l'ingestione della nuova versione esterna per proteggersi da un potenziale attacco.
Nell'immagine seguente, *RePoA è il tuo CodeArtifact repository con una* connessione esterna a un repository pubblico. Il tuo repository contiene le versioni 1.1 e 2.1 di *PackageA*, ma la versione 3.0 è pubblicata nell'archivio pubblico. Normalmente, *RePoA* ingerisce la versione 3.0 dopo che il pacchetto è stato richiesto da un gestore di pacchetti. Poiché l'ingestione dei pacchetti è impostata su **Block**, la versione 3.0 non viene inserita nel CodeArtifact repository e non è disponibile per i gestori di pacchetti ad esso collegati.
![\[Grafica semplice che mostra una nuova versione del pacchetto esterno bloccata da un archivio pubblico.\]](http://docs.aws.amazon.com/it_it/codeartifact/latest/ug/images/package-origin-controls-one.png)
**Viene pubblicata una versione interna del pacchetto per un pacchetto esterno esistente**
In questo scenario, un pacchetto, *packageB*, esiste esternamente in un repository pubblico collegato al repository. Quando un gestore di pacchetti connesso al tuo repository richiede *PackageB, la versione del pacchetto* viene inserita nel tuo repository dal repository pubblico. ****Poiché questa è la prima versione del pacchetto di *PackageB* aggiunta al repository, le impostazioni di origine del pacchetto sono configurate su Publish: BLOCK e Upstream: ALLOW.**** Successivamente, si tenta di pubblicare una versione con lo stesso nome di pacchetto nel repository. O non siete a conoscenza del pacchetto pubblico e state cercando di pubblicare un pacchetto non correlato con lo stesso nome, oppure state cercando di pubblicare una versione con patch, oppure state cercando di pubblicare direttamente la versione esatta del pacchetto che già esiste esternamente. CodeArtifact rifiuterà la versione che state tentando di pubblicare, ma vi permetterà di ignorare esplicitamente il rifiuto e di pubblicare la versione se necessario.
Nell'immagine seguente, *RePoA è il tuo CodeArtifact repository con una* connessione esterna a un archivio pubblico. Il tuo repository contiene la versione 3.0 che ha importato dal repository pubblico. Vuoi pubblicare la versione 1.1 nel tuo repository. Normalmente, è possibile pubblicare la versione 1.2 su *RePoA*, ma poiché la pubblicazione è impostata su **Block**, la versione 1.2 non può essere pubblicata.
![\[Grafica semplice che mostra una nuova versione del pacchetto esterno bloccata da un archivio pubblico.\]](http://docs.aws.amazon.com/it_it/codeartifact/latest/ug/images/package-origin-controls-two.png)
**Pubblicazione di una versione patchata di un pacchetto esterno esistente**
In questo scenario, un pacchetto, *packageB*, esiste esternamente in un repository pubblico collegato al repository. Quando un gestore di pacchetti connesso al tuo repository richiede *PackageB, la versione del pacchetto* viene inserita nel tuo repository dal repository pubblico. ****Poiché questa è la prima versione del pacchetto di *PackageB* aggiunta al repository, le impostazioni di origine del pacchetto sono configurate su Publish: BLOCK e Upstream: ALLOW.**** Il tuo team decide che deve pubblicare le versioni del pacchetto con patch di questo pacchetto nel repository. Per poter pubblicare direttamente le versioni dei pacchetti, il team modifica le impostazioni di controllo dell'origine del pacchetto in **Publish: ALLOW e **Upstream**:** BLOCK. Le versioni di questo pacchetto possono ora essere pubblicate direttamente nel repository e importate da archivi pubblici. **Dopo che il team ha pubblicato le versioni del pacchetto con patch, ripristina le impostazioni di origine del pacchetto su **Publish**: BLOCK e Upstream: ALLOW.**
## Impostazioni di controllo dell'origine del pacchetto
Con i controlli sull'origine dei pacchetti, è possibile configurare il modo in cui le versioni dei pacchetti possono essere aggiunte a un repository. Gli elenchi seguenti includono le impostazioni e i valori disponibili per il controllo dell'origine dei pacchetti.
**Nota**
Le impostazioni e i valori disponibili sono diversi quando si configurano i controlli di origine sui gruppi di pacchetti. Per ulteriori informazioni, consulta [Controlli dell'origine dei gruppi di pacchetti](package-group-origin-controls.md).
**Pubblicare**
Questa impostazione configura se le versioni dei pacchetti possono essere pubblicate direttamente nel repository utilizzando gestori di pacchetti o strumenti simili.
+ **ALLOW**: le versioni dei Package possono essere pubblicate direttamente.
+ **BLOCK**: Le versioni dei pacchetti non possono essere pubblicate direttamente.
**A monte**
Questa impostazione configura se le versioni dei pacchetti possono essere importate da archivi pubblici esterni o conservate dagli archivi upstream quando richiesto da un gestore di pacchetti.
+ **CONSENTI**: qualsiasi versione del pacchetto può essere conservata da altri CodeArtifact repository configurati come archivi upstream o importata da una fonte pubblica con una connessione esterna.
+ **BLOCK**: le versioni dei pacchetti non possono essere conservate da altri CodeArtifact repository configurati come repository upstream o importate da una fonte pubblica con una connessione esterna.
## Impostazioni predefinite per il controllo dell'origine dei pacchetti
Le impostazioni di controllo dell'origine dei pacchetti predefinite sono configurate in base alle impostazioni di controllo dell'origine del gruppo di pacchetti associato al pacchetto. Per ulteriori informazioni sui gruppi di pacchetti e sui controlli di origine dei gruppi di pacchetti, vedere [Lavorare con i gruppi di pacchetti in CodeArtifact](package-groups.md) e[Controlli dell'origine dei gruppi di pacchetti](package-group-origin-controls.md).
Se un pacchetto è associato a un gruppo di pacchetti con impostazioni di restrizione `ALLOW` per ogni tipo di restrizione, i controlli di origine dei pacchetti predefiniti per un pacchetto si baseranno su come la prima versione di quel pacchetto viene aggiunta all'archivio.
+ **Se la prima versione del pacchetto viene pubblicata direttamente da un gestore di pacchetti, le impostazioni saranno **Publish: ALLOW e Upstream: BLOCK**.**
+ **Se la prima versione del pacchetto viene importata da una fonte pubblica, le impostazioni saranno **Publish: BLOCK e Upstream:** ALLOW.**
**Nota**
**I pacchetti che esistevano nei CodeArtifact repository prima di maggio 2022 circa avranno i controlli di origine dei pacchetti predefiniti **Publish: ALLOW e Upstream: ALLOW**.** I controlli di origine dei pacchetti devono essere impostati manualmente per tali pacchetti. Gli attuali valori predefiniti sono stati impostati su nuovi pacchetti da quel momento e hanno iniziato a essere applicati quando la funzionalità è stata lanciata il 14 luglio 2022. Per ulteriori informazioni sull'impostazione dei controlli di origine dei pacchetti, consulta[Modifica dei controlli di origine dei pacchetti](#edit-package-origin-controls).
Altrimenti, se un pacchetto è associato a un gruppo di pacchetti con almeno un'impostazione di restrizione pari a `BLOCK` o`ALLOW_SPECIFIC_REPOSITORIES`, le impostazioni di controllo dell'origine predefinite per quel pacchetto saranno impostate su **Publish: ALLOW e **Upstream:** ALLOW**.
## In che modo i controlli di origine dei pacchetti interagiscono con i controlli di origine dei gruppi di pacchetti
Poiché i pacchetti hanno impostazioni di controllo dell'origine e i gruppi di pacchetti associati hanno impostazioni di controllo dell'origine, è importante capire come queste due diverse impostazioni interagiscono tra loro.
L'interazione tra le due impostazioni è che un'impostazione di `BLOCK` sempre vince su un'impostazione di`ALLOW`. La tabella seguente elenca alcuni esempi di configurazioni e le relative impostazioni di controllo dell'origine effettive.
| Impostazione del controllo dell'origine del pacchetto | Impostazione del controllo dell'origine del gruppo di pacchetti | Impostazione efficace del controllo dell'origine |
| --- | --- | --- |
| PUBBLICA: CONSENTIUPSTREAM: CONSENTI | PUBBLICA: CONSENTIUPSTREAM: CONSENTI | PUBBLICA: CONSENTIUPSTREAM: CONSENTI |
| PUBBLICA: BLOCCAUPSTREAM: CONSENTI | PUBBLICA: CONSENTIUPSTREAM: CONSENTI | PUBBLICA: BLOCCAUPSTREAM: CONSENTI |
| PUBBLICA: CONSENTIUPSTREAM: CONSENTI | PUBBLICA: CONSENTIUPSTREAM: BLOCCA | PUBBLICA: CONSENTIUPSTREAM: BLOCCA |
Ciò significa che un pacchetto con le impostazioni di origine di **Publish: ALLOW** e **Upstream: ALLOW** viene effettivamente rimandato alle impostazioni di controllo dell'origine del gruppo di pacchetti associato.
## Modifica dei controlli di origine dei pacchetti
I controlli di origine dei pacchetti vengono configurati automaticamente in base al modo in cui la prima versione del pacchetto di un pacchetto viene aggiunta al repository, per ulteriori informazioni, vedere[Impostazioni predefinite per il controllo dell'origine dei pacchetti](#default-package-origin-control-settings). Per aggiungere o modificare i controlli di origine del pacchetto per un pacchetto in un CodeArtifact repository, effettuate i passaggi indicati nella procedura seguente.
**Per aggiungere o modificare i controlli di origine del pacchetto (console)**
1. Apri la AWS CodeArtifact console su [https://console.aws.amazon.com/codesuite/codeartifact/home](https://console.aws.amazon.com/codesuite/codeartifact/home).
1. Nel pannello di navigazione, scegli **Repository e scegli il repository** che contiene il pacchetto che desideri modificare.
1. Nella tabella **Pacchetti**, cerca e seleziona il pacchetto che desideri modificare.
1. Nella pagina di riepilogo del pacchetto, in **Origin controls**, scegli **Modifica**.
1. In **Modifica controlli di origine**, scegli i controlli di origine del pacchetto che desideri impostare per questo pacchetto. Entrambe le impostazioni di controllo dell'origine del pacchetto, Publish e Upstream, devono essere impostate contemporaneamente.
+ Per consentire la pubblicazione diretta delle versioni dei pacchetti, in **Pubblica**, scegli **Consenti**. Per bloccare la pubblicazione delle versioni dei pacchetti, scegli **Blocca**.
+ ****Per consentire l'inserimento di pacchetti da repository esterni e l'estrazione di pacchetti da repository upstream, in Origini upstream, scegli Consenti.**** **Per bloccare tutte le importazioni e l'estrazione di versioni di pacchetti da repository esterni e upstream, scegliete Blocca.**
**Per aggiungere o modificare i controlli di origine dei pacchetti ()AWS CLI**
1. In caso contrario, configurali AWS CLI seguendo la procedura riportata di seguito[Configurazione con AWS CodeArtifact](get-set-up-for-codeartifact.md).
1. Usa il `put-package-origin-configuration` comando per aggiungere o modificare i controlli di origine del pacchetto. Sostituisci i seguenti campi:
+ Sostituisci *my\$1domain* con il CodeArtifact dominio che contiene il pacchetto che desideri aggiornare.
+ Sostituisci *my\$1repo* con il CodeArtifact repository che contiene il pacchetto che desideri aggiornare.
+ Sostituisci *npm* con il formato del pacchetto che desideri aggiornare.
+ Sostituisci *my\$1package* con il nome del pacchetto che desideri aggiornare.
+ Sostituisci *ALLOW* e *BLOCK* con le impostazioni di controllo dell'origine del pacchetto desiderate.
```
aws codeartifact put-package-origin-configuration --domain my_domain \
--repository my_repo --format npm --package my_package \
--restrictions publish=ALLOW,upstream=BLOCK
```
## Repository editoriali e upstream
CodeArtifact non consente la pubblicazione di versioni di pacchetti presenti in repository upstream raggiungibili o in archivi pubblici. Ad esempio, supponiamo di voler pubblicare un pacchetto Maven in un repository e `myrepo` di disporre di un repository upstream con una `myrepo` connessione esterna `com.mycompany.mypackage:1.0` a Maven Central. Considerate i seguenti scenari.
1. Le impostazioni di controllo dell'origine del pacchetto attive `com.mycompany.mypackage` sono **Publish: ALLOW** e **Upstream: ALLOW**. Se `com.mycompany.mypackage:1.0` è presente nel repository upstream o in Maven Central, CodeArtifact rifiuta qualsiasi tentativo di pubblicazione su di esso con un errore di conflitto 409. `myrepo` È comunque possibile pubblicare una versione diversa, ad esempio. `com.mycompany.mypackage:1.1`
1. Le impostazioni di controllo dell'origine del pacchetto `com.mycompany.mypackage` sono **Publish: ALLOW** e **Upstream: BLOCK**. Puoi pubblicare nel tuo repository qualsiasi versione `com.mycompany.mypackage` di che non esista già perché le versioni del pacchetto non sono raggiungibili.
1. Le impostazioni di controllo dell'origine del pacchetto `com.mycompany.mypackage` sono **Publish: BLOCK** e **Upstream**: ALLOW. Non puoi pubblicare alcuna versione del pacchetto direttamente nel tuo repository.