Watch 1

Star 0

HTTPS

Download ZIP Download TAR.GZ Download BUNDLE Open with VS Code Open with VSCodium Open with Intellij IDEA

Agentic Team

Containerized development environment for role-based containers and local Forgejo using rootless Podman.

Overview

Two Python tools manage the system:

• devagents.py: Creates isolated containers for each development role (developer, QA, release engineer, etc.)
• forgejo.py: Manages local Forgejo instance with Forgejo Actions runner support

Both use TOML configuration and share a Podman network for inter-container communication.

New: Forgejo Actions support for automated CI/CD workflows! Run workflows triggered by pushes, pull requests, and other events.

Architecture

Isolated container environments for each development role:

• Role Containers: Fedora-based with role-specific tooling
• Forgejo Server: Local Git server with web UI, issues, PRs
• Actions Runner: Podman-in-podman for automated workflow execution
• Shared Network: All containers communicate via devagents-network
• GPU Support: Optional /dev/dri passthrough
• Persistent Storage: Each role gets a persistent home directory
• Shared Tools: Common /usr/local directory for shared binaries and scripts

System Diagram

┌──────────────────────────────────────────────────────────────┐
│ Host System │
│ Network: devagents-network │
│ │
│ ├─ Agent Containers (devagents.py) │
│ │ ├─ architect │
│ │ ├─ product_owner │
│ │ ├─ software_developer │
│ │ ├─ quality_engineer │
│ │ ├─ release_engineer │
│ │ └─ technical_writer │
│ │ │
│ ├─ forgejo (forgejo.py) │
│ │ └─ Forgejo v13 Server │
│ │ http://localhost:8080 (from host) │
│ │ http://forgejo.internal:8080 (from containers) │
│ │ │
│ └─ forgejo-runner (forgejo.py) │
│ └─ Podman-in-Podman Runner │
│ ├─ Forgejo Runner Daemon │
│ ├─ Job Containers (on-demand) │
│ └─ Auto-cleanup every 6 hours │
└──────────────────────────────────────────────────────────────┘

The Plan

AI agents collaborate through Forgejo to transform specifications into working software. Uses continuous Kanban flow instead of sprints.

Workflow Overview

1. Architect (architect)

   • Receives high-level product specifications
   • Creates architectural designs and ADRs
   • Posts designs as Forgejo issues or repository documents

2. Product Owner (product_owner)

   • Reviews architectural designs
   • Creates actionable tickets in Forgejo
   • Maintains Kanban board and prioritizes backlog
   • Defines acceptance criteria
   • Moves tickets through workflow states

3. Software Developer (software_developer)

   • Pulls tasks from Kanban board
   • Implements in small, incremental commits
   • Creates PRs for each task
   • Responds to review feedback
   • Works multiple tasks in parallel

4. Quality Engineer (quality_engineer)

   • Maintains test suite
   • Reviews PRs for coverage and quality
   • Runs automated tests
   • Files issues for bugs found
   • Validates acceptance criteria

5. Release Engineer (release_engineer)

   • Reviews PRs for release readiness
   • Gates releases on quality metrics
   • Manages versioning and release branches
   • Creates release notes
   • Handles deployment automation

6. Compliance (compliance, optional)

   • Oversees development process
   • Reviews for security, licensing, policy compliance
   • Audits workflow adherence
   • Blocks non-compliant changes
   • Generates compliance reports

7. Technical Writer (technical_writer)

   • Documents features from merged PRs
   • Updates user docs and API references
   • Creates tutorials
   • Reviews documentation PRs
   • Maintains changelog

Key Principles

All Communication Through Forgejo: Every interaction uses Forgejo features—issues, PRs, comments, labels, milestones. No out-of-band communication. This ensures:

• Complete traceability
• Auditable history
• Transparent collaboration
• Asynchronous coordination

Continuous Kanban Flow: Work flows continuously, not in sprints:

• Tasks pulled when capacity exists
• No sprint boundaries or ceremonies
• WIP limits maintain sustainable pace
• Cycle time and throughput measured
• Blockers addressed immediately

Autonomous Agent Operation: Agents work independently within their role:

• Decisions based on expertise and Forgejo data
• No central coordinator
• Self-organizing around Kanban board
• Emergent coordination through interactions

Creates an asynchronous, distributed AI development team using standard software practices.

Agent Orchestration

Forgejo Actions (Now Implemented): Built-in CI/CD for workflow automation:

• ✅ Automated workflow execution on push, PR, and other events
• ✅ Declarative YAML workflow definitions
• ✅ Native Forgejo integration with podman-in-podman runner
• ✅ Can invoke agent containers or run tasks in isolated environments
• ✅ Parallel job execution (up to 20 jobs on this system)

Future Options for agent triggering:

• Manager Container: Non-agentic dispatcher that:
  • Monitors Forgejo for changes (issues, PRs, comments)
  • Determines which agent(s) should respond
  • Triggers appropriate containers via Forgejo Actions or directly
  • Uses webhooks or polling
  • Acts as event router, not coordinator

Agents must interact exclusively through Forgejo features (issues, PRs, comments, Actions).

Spec-Driven Development with Spec Kit

Aligns with GitHub's spec-driven development. The Architect will likely use spec-kit.

What is Spec-Driven Development?

Shifts from "code is truth" to "intent is truth". Creates living, executable specifications that drive implementation. Powerful for AI agents—provides clear, unambiguous guidance.

The Spec Kit Workflow

Maps naturally to our agentic workflow:

1. Specify: Describe purpose, UX, and requirements
2. Plan: Define architecture, constraints, decisions
3. Tasks: Break spec into implementable chunks
4. Implement: Generate code from specification

Integration with Agentic Team

• Architect uses spec-kit to create:

  • Detailed specifications (what and why)
  • Technical plans (architecture and constraints)
  • ADRs for design decisions

• Product Owner transforms spec-kit "Tasks" into:

  • Forgejo issues
  • Acceptance criteria
  • Spec-to-implementation traceability

• Developer implements with:

  • Clear context from living spec
  • Reduced ambiguity
  • Better alignment with intent

• Quality Engineer validates:

  • Implementation matches spec
  • Tests verify intent
  • Acceptance criteria met

Key Benefits

• Reduced Ambiguity: Precise specs instead of vague requirements
• Living Documentation: Specs evolve with the project
• Traceability: Intent → architecture → tasks → code
• Better AI Output: Comprehensive context improves accuracy

Further Research

• GitHub Blog: Spec-Driven Development with AI
• Spec Kit Repository

Architect integration with spec-kit transforms product vision into actionable tasks.

Components

devagents.py

Manages role containers:

• Automated creation with role-specific configs
• Configurable UID/GID mappings
• GPU support via /dev/dri passthrough
• Per-role port forwarding
• Interactive shell access
• Skeleton file system for new agents
• Shared /usr/local directory (read-only)
• Pre-configured Claude Code MCP integration

Default Roles:

• software_developer (dev-bot) - Development toolchain
• quality_engineer (qa-bot) - Testing tools
• release_engineer (rel-bot) - Release management
• product_owner (po-bot) - Product management
• architect (arch-bot) - Architecture and design
• technical_writer (writer-bot) - Documentation

Baseline Tools (installed in all containers):

• Git for version control
• Ripgrep (rg) for fast text search
• Node.js and NPM
• Python 3 with pip

forgejo.py

Manages Forgejo instance and Actions runner:

Forgejo Server:

• Auto-setup of data and config directories
• Official releases from Codeberg (v13)
• Custom fork building (multi-stage)
• Rootless container
• Persistent Git storage

Actions Runner:

• Podman-in-podman architecture
• Single runner instance with auto-detected CPU capacity
• Fedora-based job containers only
• Automatic cleanup of old images/containers
• Systemd-managed runner daemon
• Parallel job execution (20 jobs on 20-core system)

See FORGEJO_ACTIONS_SETUP.md for detailed setup guide.

Automated Forgejo Provisioning

The system automatically provisions Forgejo users, SSH keys, and access tokens for each agent during container creation. This enables agents to interact with Forgejo immediately without manual setup.

New in v13: Enhanced automation with bootstrap, status, set-admin-token, and upgrade commands that dramatically simplify setup and maintenance.

What Gets Provisioned

For each agent, the system automatically:

1. Generates SSH key pair - Ed25519 keys in the agent's ~/.ssh/ directory
2. Creates Forgejo user - Username matches agent name (e.g., dev-bot)
3. Uploads SSH key - Public key is added to the Forgejo user account
4. Generates access token - API token with appropriate scopes for agent operations
5. Updates secrets.toml - Token is automatically saved for container environment

Setup

1. Start Forgejo and create an admin account:

   ./forgejo.py start
   # Visit http://localhost:8080 and complete initial setup
   

2. Generate an admin access token:

   • Log in to Forgejo as admin
   • Go to Settings → Applications → Generate New Token
   • Select scopes: admin:org, write:user, write:repository
   • Copy the generated token

3. Add token to secrets.toml:

   [forgejo]
   admin_token = "your_admin_token_here"
   

4. Create agents (provisioning happens automatically):

   ./devagents.py create
   

Manual Provisioning

Provision specific agent or all agents after Forgejo setup:

# Provision a specific agent
./devagents.py provision dev-bot
# Provision all agents
./devagents.py provision
# Recreate (useful after Forgejo reinstall)
./devagents.py provision --recreate

Graceful Degradation

If Forgejo is not running or no admin token is configured, agent creation will still succeed but skip provisioning. You can provision later using the provision command.

Default Credentials

Created users have:

• Email: {username}@agentic.local
• Password: changeme-{username}
• Access Token: Automatically stored in secrets.toml

Change passwords through the Forgejo web UI after first login.

Prerequisites

• Python 3.11+ (for tomllib support)
• Podman (rootless recommended)
• Basic development tools (for building custom Forgejo fork)

Quick Start

Option A: Bootstrap (Easiest!)

# 1. Start Forgejo
./forgejo.py start
# 2. Visit http://localhost:8080, create admin account, get admin token
# 3. Configure token
./devagents.py set-admin-token <YOUR_TOKEN>
# 4. Bootstrap everything!
./devagents.py bootstrap
# Creates: network, all agent containers, SSH keys, Forgejo users, access tokens
# Done! All agents created and provisioned automatically ✨
# Optional: Rebuild agent containers (keeps Forgejo data)
./devagents.py bootstrap --recreate

Option B: Manual Setup

1. Create the shared network

podman network create devagents-network
# (Or skip - auto-created during agent creation)

2. Set up development containers

# Create all role containers (requires devagents.toml)
./devagents.py create
# Start all containers
./devagents.py start
# Enter a specific role
./devagents.py enter dev-bot
# Run a command in a role
./devagents.py run dev-bot git status

3. Set up Forgejo

# Create and start Forgejo (using official image)
./forgejo.py start
# Access web interface at http://localhost:8080
# SSH access at localhost:2200

4. Set up Forgejo Actions (Optional)

Enables automated CI/CD workflows triggered by Git events.

# 1. Get registration token from Forgejo web UI
# http://localhost:8080/admin/actions/runners → "Create new Runner"
# 2. Create secrets.toml from example and add your token
cp secrets.toml.example secrets.toml
# Edit secrets.toml: add registration_token (runners auto-enable when token is set)
# 3. Set up runner infrastructure (one-time)
./forgejo.py setup-runners
# 4. Start runner daemon
./forgejo.py start-runners
# 5. Check status
./forgejo.py runner-status

See FORGEJO_ACTIONS_SETUP.md for complete guide.

Building a Custom Forgejo Fork

# Edit forgejo.toml: set source.use = "fork"
# Configure repo_url, branch, etc.
./forgejo.py build-fork
./forgejo.py start

Upgrading Forgejo

# Automatically upgrade to the version in forgejo.toml
./forgejo.py upgrade
# Smart upgrade that:
# 1. Detects if upgrade is needed (no-op if already latest)
# 2. Creates timestamped backup using podman unshare
# 3. Stops and removes old container
# 4. Pulls new image and starts fresh container
# 5. Database migrations run automatically
# 6. Checks for runner version compatibility
# 7. Preserves all your data in volumes
# Example: Upgrade from v12 to v13
# 1. Edit forgejo.toml: change "12-rootless" to "13-rootless"
# 2. Run: ./forgejo.py upgrade
# 3. Done!

Automation Features

The system includes comprehensive automation to minimize manual steps:

Setup Automation:

• ./devagents.py bootstrap - One-command environment setup
• ./devagents.py set-admin-token <TOKEN> - Easy token configuration
• Auto-creates network, containers, SSH keys, users, and tokens

Monitoring:

• ./devagents.py status - Visual dashboard of entire system
• Shows what's configured, what's missing, suggests next steps
• Checks network, Forgejo, agents, runners, provisioning state

Upgrades:

• ./forgejo.py upgrade - Smart version upgrades with auto-backup
• Auto-detects if upgrade needed (no-op if current)
• Checks runner compatibility automatically

Provisioning:

• Auto-provisions during agent creation
• Manual re-provisioning with provision command
• --recreate flag for regenerating credentials

See PROVISIONING.md for complete automation guide.

Command Reference

Quick Reference Card

One-Command Setup:

./devagents.py bootstrap # Complete environment setup
./devagents.py status # Check what's configured

Agent Management:

./devagents.py create [role] # Create agents
./devagents.py start/stop/rm # Manage agents
./devagents.py enter <role> # Interactive shell
./devagents.py run <role> <cmd> # Run command

Provisioning:

./devagents.py provision [role] # Provision Forgejo access
./devagents.py set-admin-token <T> # Configure admin token

Forgejo:

./forgejo.py start/stop/rm # Manage server
./forgejo.py upgrade # Upgrade version
./forgejo.py logs # View logs

Actions Runners:

./forgejo.py setup-runners # One-time setup
./forgejo.py start-runners # Start daemons
./forgejo.py runner-status # Check status

Configuration

devagents.toml

[settings]
root_dir = "~/agentic" # Base directory for role homes
base_image_name = "devagents-base" # Base image name
default_base_image = "fedora:latest" # Base container image
network_name = "devagents-network" # Shared network name
baseline_packages = [
 "sudo", "procps-ng", "which", "shadow-utils",
 "git", "ripgrep", "npm", "python3-pip", "python3-devel"
]
[roles.software_developer]
username = "dev-bot"
image = "fedora:latest"
packages = [] # Additional packages
groups = ["development-tools"] # DNF package groups
uid = 2001
gid = 2001
gpu_enabled = true
ports = ["8085:8085"] # Port mappings

forgejo.toml

[settings]
root_dir = "~/agentic/forgejo" # Data directory
container_name = "forgejo"
hostname = "forgejo.internal"
network_name = "devagents-network"
web_port = 8080
ssh_port = 2200
[images]
official = "codeberg.org/forgejo/forgejo:13-rootless"
fork_name = "forgejo-with-project-boards"
fork_containerfile = "Containerfile.forgejo"
[source]
use = "official" # "official" or "fork"
repo_url = "https://codeberg.org/mattdm/forgejo.git"
branch = "v13.0/forgejo"
go_version = "1.24"
[runners]
# NOTE: Put secrets in secrets.toml (gitignored)
# See secrets.toml.example for template
num_instances = 1 # Single runner for local dev
capacity_per_runner = 0 # 0 = auto-detect CPU cores
labels = [ # Fedora-based containers only
 "docker:docker://fedora:latest",
 "fedora:docker://fedora:latest",
 "fedora-42:docker://fedora:42",
 "fedora-43:docker://fedora:43"
]
cleanup_enabled = true
cleanup_interval_hours = 6

secrets.toml (gitignored)

Stores sensitive configuration including registration tokens and environment variables.

[runners]
registration_token = "YOUR_TOKEN_HERE"
# Runners automatically enabled when token is set
# Global environment variables (available to all agents)
[environment]
CLAUDE_CODE_USE_VERTEX="1"
ANTHROPIC_VERTEX_PROJECT_ID="your-project-id"
CLOUD_ML_REGION="us-east5"
# Per-agent environment variables
# These are merged with global vars (per-agent vars override global ones)
[environment.dev-bot]
FORGEJO_TOKEN="dev_bot_token_here"
[environment.qa-bot]
FORGEJO_TOKEN="qa_bot_token_here"
[environment.rel-bot]
FORGEJO_TOKEN="rel_bot_token_here"

Environment Variable Behavior:

• Global vars in [environment] are available to all agent containers
• Per-agent vars in [environment.AGENT_NAME] are specific to that agent
• Per-agent vars override global vars if there's a naming conflict
• Variables are mounted as podman secrets at /run/secrets/devagents-env in containers

Per-Agent Environment Variables

The system supports per-agent environment variables in addition to global environment variables. This allows you to configure different values (like authentication tokens) for each agent while maintaining shared configuration.

How It Works

Variable Merging:

1. Each agent receives all global variables from [environment]
2. Each agent also receives their specific variables from [environment.AGENT_NAME]
3. If a per-agent variable has the same name as a global variable, the per-agent value takes precedence

Example Results:

Given the configuration above:

dev-bot receives:

• CLAUDE_CODE_USE_VERTEX="1" (global)
• ANTHROPIC_VERTEX_PROJECT_ID="itpc-gcp-core-pe-eng-claude" (global)
• CLOUD_ML_REGION="us-east5" (global)
• FORGEJO_TOKEN="dev_bot_token_here" (per-agent)

qa-bot receives:

• All 3 global variables
• FORGEJO_TOKEN="qa_bot_token_here" (per-agent)

writer-bot receives (no per-agent vars defined):

• Only the 3 global variables

Implementation Details

Podman Secrets:

• Each agent gets a dedicated podman secret: devagents-env-AGENT_NAME
• The secret is automatically created/updated when you create or recreate the container
• Variables are mounted at /run/secrets/devagents-env inside the container

Accessing Variables in Containers:

Inside a container, source the environment file:

# Source the environment variables
source /run/secrets/devagents-env
# Now you can use them
echo $FORGEJO_TOKEN

Or in your shell profile (.bashrc, .bash_profile):

if [ -f /run/secrets/devagents-env ]; then
 source /run/secrets/devagents-env
fi

Use Cases

Individual Forgejo Tokens:

Each agent can have their own Forgejo authentication token:

[environment.dev-bot]
FORGEJO_TOKEN="dev_bot_personal_token"
[environment.qa-bot]
FORGEJO_TOKEN="qa_bot_personal_token"

Role-Specific API Keys:

Different agents can use different service credentials:

[environment.dev-bot]
DATABASE_URL="postgresql://dev_user:pass@db/dev_db"
[environment.qa-bot]
DATABASE_URL="postgresql://qa_user:pass@db/qa_db"

Override Global Settings:

Override global configuration for specific agents:

[environment]
LOG_LEVEL="info" # Default for all agents
[environment.dev-bot]
LOG_LEVEL="debug" # More verbose logging for dev-bot

Updating Environment Variables

When you modify secrets.toml:

1. Recreate the affected container(s):

   ./devagents.py create dev-bot --recreate
   

2. Or recreate all containers:

   ./devagents.py create --recreate
   

The secrets are automatically synchronized during container creation.

Security

• secrets.toml is gitignored and never committed to version control
• Podman secrets are stored securely on the host system
• Variables are only accessible inside the containers that mount them
• Each agent only sees their own environment secret

Troubleshooting

Check what variables an agent would receive:

python3 -c "
import tomllib
with open('secrets.toml', 'rb') as f:
 secrets = tomllib.load(f)
env = secrets.get('environment', {})
print('Global vars:')
for k, v in env.items():
 if not isinstance(v, dict):
 print(f' {k}={v}')
print('\nPer-agent vars:')
for agent, vars in env.items():
 if isinstance(vars, dict):
 print(f' [{agent}]:')
 for k, v in vars.items():
 print(f' {k}={v}')
"

List podman secrets:

podman secret ls | grep devagents-env

Remove all environment secrets:

podman secret ls --format '{{.Name}}' | grep '^devagents-env-' | xargs -r podman secret rm

Usage Examples

Quick Setup

# Check what's configured and what's missing
./devagents.py status
# One-command setup (after Forgejo running and admin token set)
./devagents.py bootstrap
# Rebuild agent containers from scratch (keeps Forgejo/runners)
./devagents.py bootstrap --recreate

Development Workflow

# List available roles
./devagents.py list
# Create a specific role container
./devagents.py create dev-bot
# Provision Forgejo access for an agent
./devagents.py provision dev-bot
# Enter the development container
./devagents.py enter dev-bot
# Run tests in QA container
./devagents.py run qa-bot pytest tests/
# Stop all containers when done
./devagents.py stop

Forgejo Management

# Forgejo server commands
./forgejo.py logs # View server logs
./forgejo.py enter # Enter server container
./forgejo.py stop # Stop server
./forgejo.py rm # Remove server container (keeps data)
./forgejo.py upgrade # Upgrade to latest version (auto-detects, creates backup)
# Actions runner commands
./forgejo.py setup-runners # One-time runner setup
./forgejo.py start-runners # Start runner daemon
./forgejo.py stop-runners # Stop runner daemon
./forgejo.py runner-status # Check runner health
./forgejo.py runner-logs # View runner logs
./forgejo.py rm-runners # Remove runner container

Using Forgejo Actions

Create .forgejo/workflows/test.yaml in your repository:

name:Test Workflowon:[push, pull_request]jobs:test:runs-on: fedora # or:docker, fedora-42, fedora-43steps:- name:Checkout codeuses:actions/checkout@v4- name:Run testsrun:| dnf install -y python3-pip
 pip3 install pytest
 pytest tests/

Push to your repo and the workflow runs automatically!

Directory Structure

~/agentic/
├── devagents.toml # Agent container configuration
├── forgejo.toml # Forgejo configuration (tracked)
├── secrets.toml # Secrets (gitignored, create from .example)
├── secrets.toml.example # Template for secrets
├── local/ # Shared tools (mounted as /usr/local in containers)
├── software_developer/ # Developer home directory (pre-populated from skel/)
├── quality_engineer/ # QA home directory (pre-populated from skel/)
├── release_engineer/ # Release engineer home directory (pre-populated from skel/)
├── product_owner/ # Product owner home directory (pre-populated from skel/)
├── architect/ # Architect home directory (pre-populated from skel/)
├── technical_writer/ # Technical writer home directory (pre-populated from skel/)
├── skel/ # Skeleton templates for new agent directories
│ ├── .bashrc # Shell configuration with aliases
│ ├── .bash_profile # Login shell setup
│ ├── .gitconfig # Git configuration with bot identity
│ ├── .claude.json # Claude Code MCP server config (Forgejo integration)
│ ├── .config/ # Config subdirectories (recursively copied)
│ └── README.md # Role-specific documentation template
├── forgejo/ # Forgejo server data (gitignored)
│ ├── data/ # Repositories and database
│ └── conf/ # Server configuration
└── forgejo-runner/ # Actions runner data (gitignored)
 └── runner/ # Runner registration and config
 ├── .runner # Registration info (auto-generated)
 └── config.yaml # Runner configuration

Skeleton File System

New agent directories are automatically populated from skel/ templates with:

• Pre-configured .bashrc with useful aliases and PATH setup
• .gitconfig with bot identity (e.g., dev-bot@agentic.local)
• .bash_profile for login shell initialization
• .claude.json with Forgejo MCP server configuration
• Role-specific README.md documentation
• Any subdirectories (e.g., .config/) are recursively copied with their contents

Templates use variable substitution ({username}, {role}, {uid}, etc.) for customization. Text files have placeholders replaced; binary files are copied as-is.

Additional Tools

Shared Local Directory

The ~/agentic/local/ directory is mounted as read-only /usr/local in all containers. Use this for:

• Shared shell scripts and tools
• Common binaries accessible to all agents
• Deployment automation scripts

Example: Place local/bin/install-claude-code.sh to make it available at /usr/local/bin/install-claude-code.sh in all containers.

Claude Code MCP Integration

Agent containers come pre-configured with Forgejo MCP server integration:

• .claude.json includes Forgejo MCP server configuration
• Agents can interact with Forgejo repositories through Claude Code
• Server URL: http://forgejo.internal:8080
• Token configured via FORGEJO_TOKEN environment variable

Forgejo Actions

The system includes full support for Forgejo Actions (CI/CD automation):

Features

• Automated Workflows: Trigger on push, PR, issues, schedules, etc.
• Parallel Execution: Run up to 20 jobs simultaneously (auto-detected from CPU cores)
• Podman-in-Podman: Runner manages its own job containers
• Fedora-Based: All job containers use Fedora (latest, 40, 41)
• Auto-Cleanup: Removes old images and containers every 6 hours
• Simple Management: Easy setup via forgejo.py commands

Quick Setup

# 1. Start Forgejo
./forgejo.py start
# 2. Get token from http://localhost:8080/admin/actions/runners
# 3. Create secrets.toml and add token
cp secrets.toml.example secrets.toml
# Edit secrets.toml: add registration_token (auto-enables runners)
# 4. Set up runner
./forgejo.py setup-runners
./forgejo.py start-runners

Example Workflow

# .forgejo/workflows/ci.yamlname:CIon:[push, pull_request]jobs:test:runs-on:fedorasteps:- uses:actions/checkout@v4- run:dnf install -y python3-pip- run:pip3 install pytest && pytest

For complete documentation, see FORGEJO_ACTIONS_SETUP.md.

Use Cases for Agentic Team

• Quality Engineer: Automated test runs on every PR
• Release Engineer: Build and tag releases on version bumps
• Software Developer: Linting and formatting checks
• Technical Writer: Doc generation and validation
• All Agents: Trigger agent actions via workflow dispatch events

Documentation

• FORGEJO_ACTIONS_SETUP.md - Complete Forgejo Actions guide
• Forgejo Actions Documentation
• Forgejo Actions Admin Guide

License

See LICENSE.md for license information.

Contributing

Experimental development environment. Contributions welcome.