OpenCode × Gitea Actions

Repo Intent

Workflow opencode.yml per filo e per segno

Il cuore del repository. Ecco ogni passo del workflow, nell'ordine esatto in cui viene eseguito.

1. Verifica autorizzazione utente

   Controlla che l'autore dell'evento sia nella whitelist (maria, nicola). Le esecuzioni manuali (workflow_dispatch) saltano questo controllo. Se l'utente non è autorizzato, il job viene interrotto con errore.

2. Reagisci al comando (👀)

   Aggiunge una reazione "eyes" all'issue o al commento che ha triggerato il workflow. Le reazioni non generano eventi issue_comment, quindi non c'è rischio di auto-trigger o loop infiniti.

3. Checkout repository

   Clona il repository con fetch-depth: 0 (storia completa) tramite actions/checkout@v4.

4. Installazione OpenCode CLI

   Scarica e installa la CLI di OpenCode via curl -fsSL https://opencode.ai/install | bash. Aggiunge $HOME/.opencode/bin al PATH.

5. Configura agent reviewer (read-only)

   Crea un agente reviewer con permessi di sola lettura: può solo leggere file ed eseguire comandi (build, lint, test). Non può mai modificare il codice. Il file viene escluso dal tracker tramite .git/info/exclude.

6. Determina contesto (issue / PR / manuale) e branch di lavoro

   Analizza il tipo di evento:

   • PR — fa il fetch e checkout del branch della PR.
   • Issue — crea un branch opencode-issue-<N> a partire da main.
   • Manuale — crea un branch opencode-manual-<run_number>.

   Genera anche una plan_key univoca per salvare il file di piano.

7. Raccogli contesto aggiuntivo (diff + commenti, se PR)

   Se si tratta di una Pull Request, scarica il diff della PR e i commenti recenti per fornire contesto completo all'agente AI.

8. Pulisci il comando dal trigger

   Rimuove i marcatori /oc e /opencode dal corpo del messaggio, lasciando solo le istruzioni utente da passare all'agente.

9. Fase 1 — Plan (analisi read-only)

   Eseguita solo per issue (non PR). L'agente plan analizza il codebase e la richiesta, poi produce un piano di lavoro in Markdown con struttura standard (Obiettivo, Task, Acceptance Criteria, Verifica). Il piano viene salvato in issue_plans/ e committato.

10. Fase 2 — Build & Review loop

    Il cuore dell'automazione: un loop che alterna Build (implementazione) e Review (verifica), fino a $MAX_ITERATIONS (4).

    • BUILD — L'agente build implementa il piano, modificando i file necessari.
    • REVIEW — L'agente reviewer (read-only) verifica se ogni Acceptance Criterion è soddisfatto e produce un VERDICT: PASS (loop termina) o FAIL (loop continua col feedback).

    Se dopo 4 iterazioni il PASS non è raggiunto, le modifiche parziali vengono comunque pushate per revisione umana.

11. Pusha modifiche e apri/aggiorna la PR

    Commatta e pusha le modifiche sul branch di lavoro. Se si lavora su un'issue (non PR), apre automaticamente una Pull Request verso main. Se la PR esiste già, ne recupera il numero.

12. Posta la review sulla PR

    Se esiste una PR, posta la review finale dell'agente usando l'API di Gitea. Se il verdetto è PASS, la review è di tipo APPROVE; altrimenti REQUEST_CHANGES. Se Gitea rifiuta (self-review del bot), ripiega su COMMENT.

13. Reazione finale 🚀 / 😕

    Se il workflow termina con success(), aggiunge una reazione 🚀 all'elemento trigger. In caso di failure(), aggiunge 😕 (confused).

Diagramma di flusso generale

flowchart LR
    A[Evento Trigger] --> B{Autorizzato?}
    B -- No --> X[❌ Interrompi]
    B -- Sì --> C[👀 Reazione eyes]
    C --> D[📦 Checkout]
    D --> E[⬇️ Installa OpenCode]
    E --> F[🔧 Configura reviewer]
    F --> G{Contesto?}
    G -- PR --> H1[Fetch & checkout PR]
    G -- Issue --> H2[Branch opencode-issue-N]
    G -- Manuale --> H3[Branch opencode-manual-RUN]
    H1 & H2 & H3 --> I[📋 Raccogli contesto]
    I --> J[🧹 Pulisci comando]
    J --> K{È issue?}
    K -- Sì --> L[📝 Fase Plan]
    L --> M
    K -- No --> M[🔄 Build & Review loop]
    M --> N{VERDICT PASS?}
    N -- Sì --> O[✅ Push & PR]
    N -- No --> P{Iterazioni < MAX?}
    P -- Sì --> M
    P -- No --> O
    O --> Q[📬 Posta review]
    Q --> R[🚀 Reazione finale]
            

Diagramma di sequenza Gitea → Runner → OpenCode

sequenceDiagram
    participant U as Utente
    participant G as Gitea
    participant R as Gitea Runner
    participant O as OpenCode CLI
    participant A as Agenti AI

    U->>G: Apre issue/commenta con /oc
    G->>R: Triggera workflow
    R->>R: Verifica autorizzazione
    R->>G: 👀 Reazione eyes
    R->>R: Checkout & installa CLI
    R->>O: opencode run --agent plan
    O->>A: Analisi codebase
    A-->>O: Piano Markdown
    O-->>R: Piano salvato
    loop Build & Review (max 4)
        R->>O: opencode run --agent build
        O->>A: Implementa piano
        A-->>O: Modifiche ai file
        O-->>R: Codice modificato
        R->>O: opencode run --agent reviewer
        O->>A: Verifica criteri
        A-->>O: VERDICT PASS/FAIL
        O-->>R: Risultato review
        alt PASS
            R->>R: Esce dal loop
        else FAIL
            R->>R: Continua iterazione
        end
    end
    R->>G: Push modifiche & PR
    R->>G: 🚀 Reazione finale
            

Diagramma del loop Build/Review con criterio di uscita VERDICT

flowchart TD
    START([🔄 Inizio loop]) --> BUILD[👷 Fase BUILD
Agente implementa il piano]
    BUILD --> REVIEW[🔍 Fase REVIEW
Agente verifica criteri]
    REVIEW --> DECIDE{VERDICT?}
    DECIDE -- PASS ✅ --> EXIT([🏁 Esci dal loop
✅ Successo])
    DECIDE -- FAIL ❌ --> CHECK{Iterazioni < MAX?}
    CHECK -- Sì --> FEEDBACK[💬 Feedback: criteri insoddisfatti]
    FEEDBACK --> BUILD
    CHECK -- No --> MAXOUT([⚠️ Raggiunto tetto MAX
Pusha modifiche parziali])
            

Trigger ed Eventi

Autorizzazione e Sicurezza