Come usare Codex Cloud con GitHub e rivedere una pull request

Per portare un progetto da GitHub a una pull request con Codex Cloud, collega il repository, prepara e pubblica un ambiente, assegna un’attività circoscritta e controlla modifiche e test prima della revisione. L’accesso dipende dal piano e dai permessi dell’area di lavoro; il branch proposto va comunque esaminato da una persona.

Prima di collegare GitHub

OpenAI elenca Codex Cloud per i piani Plus, Pro, Business ed Enterprise/Education. L’accesso tramite API key non è supportato e possono valere anche i permessi dell’area di lavoro. Le chat cloud condividono il limite di utilizzo del piano con i messaggi locali; le attività cloud possono consumarne di più, in misura variabile secondo il modello e il compito, come indica la tabella ufficiale di disponibilità e utilizzo.

Scegli un repository che conosci e individua in anticipo le dipendenze, i servizi e i comandi di test necessari. Se il progetto usa registri privati o credenziali, prepara anche le autorizzazioni per quei servizi: consentire una destinazione di rete, da solo, non concede l’accesso né fornisce le credenziali.

Prepara e pubblica l’ambiente

1. Crea un ambiente cloud e seleziona il repository GitHub. Nel flusso web o desktop, apri Work in → Cloud → Select environment → Create environment. Collega GitHub se richiesto e scegli il repository da usare.
2. Esamina la preparazione proposta da Codex. Codex può ispezionare il progetto, installare dipendenze e strumenti e provare la configurazione. Controlla il resoconto, le versioni dei runtime e i comandi; risolvi eventuali problemi di accesso o informazioni mancanti prima di proseguire.
3. Verifica la configurazione e pubblica l’ambiente. La pubblicazione crea una base riutilizzabile per le nuove attività; non distribuisce l’applicazione. Per usare una configurazione modificata, aggiornala, provala e pubblicala di nuovo. Le nuove attività partono da una copia isolata dell’ambiente pubblicato, mentre quelle già avviate conservano il proprio stato. OpenAI descrive preparazione, pubblicazione e gestione dello stato.

Assegna un’attività circoscritta

Chiedi prima una spiegazione del repository, poi formula un compito con il comportamento atteso, i casi di regressione da controllare, i comandi utili e i confini della modifica. Specificare che non vuoi cambiamenti estranei o nuove dipendenze aiuta a rendere più leggibile la revisione.

Nel suo walkthrough su HackerNoon, proflead parte da un piccolo progetto JavaScript, chiede a Codex di spiegarne il funzionamento e poi affronta un problema ai limiti della ricerca. L’autore consiglia di iniziare da un cambiamento che si possa verificare e di esaminare modifiche e test, non di considerare il risultato un via libera automatico. Il suo percorso completo è un esempio pratico, non una garanzia che ogni attività produca una modifica corretta.

Controlla modifiche, test e pull request

Esamina i file cambiati e il diff, cioè il confronto riga per riga con il codice precedente. Controlla anche gli input dei test e i risultati, quindi verifica che siano stati eseguiti i controlli previsti dal progetto.

Quando Codex propone una pull request, apri il collegamento GitHub e controlla branch di origine e destinazione, diff, descrizione e risultati CI, i controlli automatici eseguiti sul codice. Un branch senza conflitti può essere integrato sul piano tecnico, ma questo non dimostra che la modifica funzioni come previsto. Valuta il comportamento con i test pertinenti prima di approvarla.

Porta il branch sul computer locale

Se vuoi esaminare o provare la modifica nella tua copia del progetto, controlla prima di non avere cambiamenti locali non salvati. proflead indica questi comandi per recuperare il branch della pull request:

git status
git remote -v
git fetch origin
git switch --track origin/your-task-branch

Sostituisci your-task-branch con il nome effettivo del branch della pull request, poi esegui localmente i test del progetto.

Risorse e stato delle attività

Le risorse predefinite della VM cloud cambiano secondo il gruppo di piani indicato da OpenAI:

Un progetto con dipendenze pesanti può risentire delle risorse assegnate; tienine conto anche quando confronti tempi di esecuzione fra piani. OpenAI afferma inoltre che lo stato salvato della VM è recuperabile fino a sette giorni dall’avvio dell’ultimo turno dell’attività o dalla sua ripresa. Non sostituisce il controllo versione: conserva le modifiche importanti in Git.

Configura credenziali e accesso alla rete

OpenAI distingue le variabili d’ambiente dai segreti di rete. Le prime vengono passate direttamente ai programmi; per i secondi, i programmi ricevono un segnaposto e un proxy inserisce la credenziale reale nelle richieste verso destinazioni HTTPS autorizzate sulla porta 443.

Autorizzare un host non conferisce permessi sul servizio e non fornisce le credenziali necessarie. Configura separatamente destinazioni e autenticazione. Se il progetto deve raggiungere una rete privata, Codex Cloud non eredita automaticamente la connessione VPN del computer: OpenAI documenta l’accesso VPN configurato separatamente con Tailscale, insieme alle relative regole di accesso e alle impostazioni di rete dell’ambiente.

Gli ambienti cloud non supportano l’uso di computer o browser, né GitLab o GitHub Enterprise Server autogestito. Per attività che richiedono un browser, uno di questi servizi o risorse locali, verifica prima che il flusso cloud sia adatto al progetto.