Releases without a local agent (epic)

Aperta
  • Qualcosa non va?
#129 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, julia
Ambito
devops

Direzione di ricerca

This is an epic describing a two-layer release automation design: an agent-driven preparation phase and deterministic GitHub Actions workflows for the finish. Read the linked ct-agents release recipe and the sub-issues, which hold the concrete work; there is no single file or test named here to start from. Done would be the sub-issues landing, not this epic closing on its own.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Goal

Release a package without a local agent session. The release is started by a workflow_dispatch; an agent run in GitHub Actions does the decisions at the start; deterministic workflows do the rest. Seen on the release of CTModels v0.21.1 (control-toolbox/CTModels.jl#512), where a local agent spent most of its time waiting.

Design

Two layers, as in ct-agents/recipes/release.md:

  1. Preparation (phases 0 to 3), by an agent. Started by a workflow_dispatch of a queue (kind: stable or beta). The facts (status, resolution from General, gate, open PRs) are computed by release.jl, not by the model. The agent does the judgment only: what is breaking, the grouping of the changelog, the proposal. The gate (REL1 against the changelog) and the breakage report check its work, so a modest model is enough, and the agent does nothing after the proposal.
  2. Finish (phases 4 to 8), without an agent. Event-driven workflows driven by release.jl status.

The human gate. The agent posts the proposal on the tracking issue. An authorized person validates it (label or /release approve X.Y.Z). That event is the opt-in of the second layer, and it is where the authorization is checked (actor with admin or maintain, Environment with reviewers).

The agent has no power. It has neither the token of the GitHub App nor the right to merge or to register: it edits files in a worktree and writes the proposal. What it reads (PR titles, issues) may contain injected instructions. The scripts of the second layer hold the powers.

Model: Albert through OpenCode, as in ocourses/agents (reusable agent.yml, a role is a Markdown file, one global queue). The local protocol of that repository (LOCAL-QUEUE.md) stays as a fallback.

Sub-issues

See the sub-issues of this one. Order: the finish first (useful even with a local agent), then the agent base, then the release role.

Lingua principale
Julia
Stelle
1
Fork
0
Merge medio
1h 39m
PR unite (30g)
45

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di control-toolbox/CTActions

Tutte le issue di control-toolbox/CTActions

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.