refactor: parametric llama bots via LLAMA_BOTS env list #831

New issue

Closed

opened 2026-04-16 07:52:57 +00:00 by dev-bot · 1 comment

dev-bot commented

2026-04-16 07:52:57 +00:00

Collaborator

Problem

lib/forge-setup.sh:362-367 hardcodes the llama bot registry:

[dev-qwen]="FORGE_TOKEN_LLAMA"
[dev-qwen-nightly]="FORGE_TOKEN_LLAMA_NIGHTLY"

Adding a new llama-backed dev agent (dev-qwen2, dev-qwen3, ...) currently requires editing lib/forge-setup.sh for each new entry. Cumbersome and invites drift with .env, docker-compose.yml, and bin/disinto:813.

Planned follow-up: scale dev throughput with additional llama containers (GPU <1% utilized on current single llama dev, so parallelism is the lever). Parametric setup is the foundation.

Proposed solution

Introduce LLAMA_BOTS env var in .env — a space-separated list:

LLAMA_BOTS="dev-qwen dev-qwen-nightly"   # default preserves current behavior

Replace hardcoded arrays with a loop that derives env var names by convention:

for bot in $LLAMA_BOTS; do
  suffix=$(echo "$bot" | tr 'a-z-' 'A-Z_')   # dev-qwen → DEV_QWEN
  token_var="FORGE_TOKEN_${suffix}"
  pass_var="FORGE_PASS_${suffix}"
  ensure_bot_user "$bot" "$token_var" "$pass_var"
done

Migration: current .env has FORGE_TOKEN_LLAMA / FORGE_TOKEN_LLAMA_NIGHTLY. Rename in-place during disinto init to FORGE_TOKEN_DEV_QWEN / FORGE_TOKEN_DEV_QWEN_NIGHTLY so values (and existing Forgejo tokens) are preserved — no rotation. Alternative: maintain a legacy-alias map in forge-setup; migration is simpler.

Acceptance criteria

LLAMA_BOTS env var controls which llama bots are provisioned
Default LLAMA_BOTS="dev-qwen dev-qwen-nightly" preserves current behavior
Running forge-setup with LLAMA_BOTS="dev-qwen dev-qwen2" creates dev-qwen2 user + token + password idempotently
.env.example updated to document LLAMA_BOTS and FORGE_TOKEN_<SUFFIX> / FORGE_PASS_<SUFFIX> convention
Existing dev-qwen Forgejo token preserved across migration (no unnecessary rotation)
disinto init remains idempotent (per #800)
bin/disinto:813 summary message derives from LLAMA_BOTS instead of hardcoded count

Affected files

lib/forge-setup.sh — replace lines 362-367 and callers with loop
bin/disinto:813 — derive ensure-message from list
.env.example — document LLAMA_BOTS

Non-goals

Compose service generation (see companion issue filed after this one — follow-up)
Anthropic-backed dev-bot is unchanged; it continues to use shared FORGE_TOKEN

Dependencies

Depends on: #830 (issue_claim race fix) — must land first so multi-bot parallel poll is safe.

Context

Second of three issues to enable operational scaling of llama dev agents. Sequence: #830 → this → compose generator refactor. After all three land, adding dev-qwen2 is an .env edit + disinto up, no code change.

## Problem `lib/forge-setup.sh:362-367` hardcodes the llama bot registry: ```bash [dev-qwen]="FORGE_TOKEN_LLAMA" [dev-qwen-nightly]="FORGE_TOKEN_LLAMA_NIGHTLY" ``` Adding a new llama-backed dev agent (dev-qwen2, dev-qwen3, ...) currently requires editing `lib/forge-setup.sh` for each new entry. Cumbersome and invites drift with `.env`, `docker-compose.yml`, and `bin/disinto:813`. Planned follow-up: scale dev throughput with additional llama containers (GPU <1% utilized on current single llama dev, so parallelism is the lever). Parametric setup is the foundation. ## Proposed solution Introduce `LLAMA_BOTS` env var in `.env` — a space-separated list: ```bash LLAMA_BOTS="dev-qwen dev-qwen-nightly" # default preserves current behavior ``` Replace hardcoded arrays with a loop that derives env var names by convention: ```bash for bot in $LLAMA_BOTS; do suffix=$(echo "$bot" | tr 'a-z-' 'A-Z_') # dev-qwen → DEV_QWEN token_var="FORGE_TOKEN_${suffix}" pass_var="FORGE_PASS_${suffix}" ensure_bot_user "$bot" "$token_var" "$pass_var" done ``` Migration: current `.env` has `FORGE_TOKEN_LLAMA` / `FORGE_TOKEN_LLAMA_NIGHTLY`. Rename in-place during `disinto init` to `FORGE_TOKEN_DEV_QWEN` / `FORGE_TOKEN_DEV_QWEN_NIGHTLY` so values (and existing Forgejo tokens) are preserved — no rotation. Alternative: maintain a legacy-alias map in forge-setup; migration is simpler. ## Acceptance criteria - [ ] `LLAMA_BOTS` env var controls which llama bots are provisioned - [ ] Default `LLAMA_BOTS="dev-qwen dev-qwen-nightly"` preserves current behavior - [ ] Running forge-setup with `LLAMA_BOTS="dev-qwen dev-qwen2"` creates dev-qwen2 user + token + password idempotently - [ ] `.env.example` updated to document `LLAMA_BOTS` and `FORGE_TOKEN_<SUFFIX>` / `FORGE_PASS_<SUFFIX>` convention - [ ] Existing dev-qwen Forgejo token preserved across migration (no unnecessary rotation) - [ ] `disinto init` remains idempotent (per #800) - [ ] `bin/disinto:813` summary message derives from `LLAMA_BOTS` instead of hardcoded count ## Affected files - `lib/forge-setup.sh` — replace lines 362-367 and callers with loop - `bin/disinto:813` — derive ensure-message from list - `.env.example` — document `LLAMA_BOTS` ## Non-goals - Compose service generation (see companion issue filed after this one — follow-up) - Anthropic-backed `dev-bot` is unchanged; it continues to use shared `FORGE_TOKEN` ## Dependencies Depends on: #830 (issue_claim race fix) — must land first so multi-bot parallel poll is safe. ## Context Second of three issues to enable operational scaling of llama dev agents. Sequence: #830 → this → compose generator refactor. After all three land, adding dev-qwen2 is an `.env` edit + `disinto up`, no code change.

dev-bot added the

backlog

priority

labels 2026-04-16 07:52:57 +00:00

dev-bot referenced this issue

2026-04-16 07:53:27 +00:00

refactor: generate one agents-llama compose service per LLAMA_BOTS entry #832

dev-bot referenced this issue

2026-04-16 08:10:13 +00:00

fix: disinto hire-an-agent + compose generator defects blocking multi-llama-dev parallel operation #834

dev-bot commented

2026-04-16 08:10:22 +00:00

Author

Collaborator

Superseded by #834. The existing disinto hire-an-agent + project-TOML [agents.*] pattern already provides the parametric structure proposed here; #834 addresses the actual narrow defects (token var naming, FORGE_PASS persistence, per-agent compose token lookup, per-agent project-repos volume). Closing unpicked.

Superseded by #834. The existing `disinto hire-an-agent` + project-TOML `[agents.*]` pattern already provides the parametric structure proposed here; #834 addresses the actual narrow defects (token var naming, FORGE_PASS persistence, per-agent compose token lookup, per-agent project-repos volume). Closing unpicked.

dev-bot closed this issue

2026-04-16 08:10:22 +00:00