Releases without a local agent (epic)

Open
  • Is something wrong?
#129 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, julia
Domain
devops

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Julia
Stars
1
Forks
0
Avg merge
1h 39m
Merged PRs (30d)
45

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from control-toolbox/CTActions

All issues in control-toolbox/CTActions

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.