Agent base: Albert through OpenCode in GitHub Actions, with a global queue

Open
  • Is something wrong?
#130 0 comments 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
12/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github-actions, julia, shell
Domain
ai-infra-agents, ci-cd, devops

Research direction

This is a design-level epic: a reusable agent.yml workflow, a single-repository queue with a global concurrency lock, and ported scripts (scaffold.sh, run-opencode.sh, finalize.sh) from ocourses/agents. Start by reading the proposal and the linked ocourses/agents repository to understand the existing protocol. Done means the design decisions are settled and the listed tasks are split into smaller issues, not that the workflow is written.

Written by the indexing model from the issue text.

Description

Part of the epic on releases without a local agent. Generic: the same base would serve other recipes (for example harmonize).

Goal

A reusable way to run an agent (OpenCode with Albert) in GitHub Actions on a control-toolbox repository, with a complete trace and a global lock, as in ocourses/agents.

Proposal

  • Reusable agent.yml in CTActions. Issue, branch, tracking file, draft PR, work, final report as a comment; the orchestration is scripts, the work is OpenCode. A role is a Markdown file (ct-agents/roles/<role>.md, with an override in the repository).
  • One queue, in one repository. The lock is global only if the queue workflow runs in a single repository (concurrency: group: agent-albert-global, cancel-in-progress: false), because a workflow_call has a lock per calling repository. The Albert budget is per minute for the whole account, so only one agent runs at a time. The queue holds the lock for the whole run of the remote workflow.
  • No cron. The queue starts on workflow_dispatch only (releases are rare and started by a person); ocourses lost time to a scheduled workflow that never fired.
  • No issue per request is needed: the dispatch carries the repository and the role; the tracking issue of the work (for a release, the [RELEASE] issue of the package) is the trace.
  • Secrets. ALBERT_API_KEY and a read token for the roles, per repository if the organization secrets do not reach it. The agent job gets a read-only token for GitHub; it never holds the powers of a release.

Tasks

  • Port agent.yml, scaffold.sh, run-opencode.sh and finalize.sh from ocourses/agents, adapted to Julia packages (no LaTeX).
  • The queue workflow with the global lock; a dispatch input for the repository, the role and the task.
  • The base instructions injected in AGENTS.md: the conventions pinned in the repository (AGENTS.md), English everywhere.
  • Token scopes of the agent job: read-only, no merge, no registration.
  • Test on a harmless role (a spell-check fix, for example) before any release role.
  • Document in docs/workflows/ and keep the local protocol as a fallback.
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.