This fixes the issue where agents-llama containers were using the main
FORGE_TOKEN (dev-bot) instead of dedicated credentials for the llama bot user.
Changes:
- forge-setup.sh: Added generation of FORGE_TOKEN_LLAMA and FORGE_PASS_LLAMA
for local-model bot users (dev-qwen, dev-qwen-nightly). These are created
as Forgejo users with their own API tokens and passwords for git push.
- generators.sh: Updated agents-llama service to use FORGE_TOKEN_LLAMA and
FORGE_PASS_LLAMA instead of falling back to dev-bot's credentials.
Fixed escaping to defer variable resolution to docker-compose runtime.
- docker-compose.yml: Updated to use FORGE_TOKEN_LLAMA and FORGE_PASS_LLAMA
(renamed from FORGE_TOKEN_DEVQWEN for consistency).
- .env.example: Added documentation for all per-bot tokens and passwords.
- projects/disinto.toml.example: Documented the auto-credential generation.
When a project TOML configures [agents.llama] with forge_user = dev-qwen:
1. disinto init creates the dev-qwen Forgejo user
2. Generates FORGE_TOKEN_LLAMA and FORGE_PASS_LLAMA
3. Adds dev-qwen as write collaborator on the project repo
4. The agents-llama container uses these credentials for all Forgejo API calls
This ensures issues and PRs created by the llama agent are correctly
attributed to dev-qwen instead of dev-bot.
Forgejo 11.x rejects API tokens for git HTTP push while accepting them
for all other operations. Store bot passwords alongside tokens during
init and use password auth for git operations consistently.
- forge-setup.sh: persist bot passwords to .env (FORGE_PASS, etc.)
- forge-push.sh: use FORGE_PASS instead of FORGE_TOKEN for git remote URL
- entrypoint.sh: configure git credential helper with password auth
- entrypoint-llama.sh: use FORGE_PASS for git clone (fallback to FORGE_TOKEN)
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
