Gli artefatti di GitHub Issues danno una casa stabile ai piani
Il codice è nella pull request, ma la spiegazione può perdersi in una vecchia chat. Se anche l’indagine di un agente vive altrove, chi riprende il lavoro rischia di rifarla. Il 28 ottobre GitHub ha presentato gli issue artifacts in preview pubblica per collegare questi materiali all’issue.
Conversazione e documento hanno ruoli diversi
Gli artefatti possono essere Markdown, link esterni o HTML: analisi delle cause, prototipi e discussioni Slack o Teams. Su github.com si creano e modificano conservando le versioni. Sono distinti dagli artefatti di GitHub Actions, prodotti dalle esecuzioni dei workflow.
Pensiamo a un pagamento elaborato due volte, in un esempio inventato. I commenti raccolgono osservazioni; il piano descrive la chiave dei tentativi e gli esperimenti ancora aperti. La prima immagine è stata creata per questo articolo e non è una schermata GitHub. Distinguere fatti e ipotesi evita che un sospetto diventi un requisito.
Allegare un file e mantenerne il contesto
gh issue artifact create accetta un numero o URL di issue seguito da file o link. gh issue artifact create 42 retry-plan.md -R OWNER/REPO allegherebbe il file all’issue 42. Sono segnaposto: l’esecuzione scrive nell’issue. Non abbiamo eseguito il comando per questo articolo.
Il nome può derivare dal file o da --name. --body-file legge il contenuto di un documento e --attach supporta immagini e video. gh issue artifact edit 42 1 --body-file retry-plan.md -R OWNER/REPO sostituisce il contenuto. La seconda immagine mostra la sintassi, non una sessione riuscita.
Piano corrente e storia possono convivere
edit cambia nome o contenuto, non il tipo. --restore-version salva nome e contenuto precedenti come nuova versione; view mostra la cronologia. Il piano attuale può restare chiaro senza cancellare la sua evoluzione.
Nell’esempio del pagamento, il sospetto può spostarsi da un timeout alla gestione delle chiavi duplicate. Aggiornare il piano e collegare un commento con la motivazione è un suggerimento, non un automatismo del prodotto. Il documento allegato non sostituisce le prove sul codice.
Il supporto HTML dipende dalla superficie
L’annuncio descrive il passaggio da anteprima HTML a sorgente. Creazione e visualizzazione di HTML in GitHub App sono però indicate come future. L’associazione automatica dei risultati di una sessione non implica HTML completo ovunque. Anche la CLI è in preview.
Il valore è trovare il contesto vicino al lavoro, non moltiplicare i documenti. Un piano esistente e la sua prossima revisione bastano per esplorare il flusso. Le fonti ufficiali descrivono le funzioni attuali.