Welcome to Dodo

Dodo is a privacy-first tool that automates and optimizes GitHub workflows.
Instead of manually writing and managing .github/workflows/*.yml files, Dodo analyzes your project, understands its structure, and generates efficient workflows—while keeping everything local and secure.

Born out of frustration with repetitive CI/CD setup, Dodo simplifies the process by:

  • Detecting tools and dependencies like Clippy, Ruff, and Cargo.
  • Generating GitHub Actions workflows tailored to your project.
  • Scanning for exposed secrets and vulnerabilities.
  • Integrating with raphus.io for fetching and adapting workflow templates.

Why Dodo?

  • No more manual .yml files—Dodo takes care of it.
  • Local-first AI for privacy and speed.
  • Optimized performance with caching and parallel execution.
  • Scalable for both small projects and large codebases.

Dodo is still in development, focusing on core features first.

Stay tuned for updates or contribute to the project! 🚀

About Dodo

Hi, I’m Tanvi—the creator behind Dodo.
I built Dodo out of my own frustration with the endless cycle of manually editing and debugging GitHub Actions workflows. I was tired of copy-pasting YAML files, only to have small mistakes derail my deployments. So, I decided to create a tool that would take care of all that for me.

Why Dodo?

Make CI/CD workflows effortless!

I believe developers should spend their time building and innovating, not wrestling with configuration files.

With Dodo, my goal is simple: automate the creation and optimization of CI/CD workflows so that you can focus on what really matters—writing great code.

My Journey

Dodo started as a personal project born out of necessity. While working on various projects, I kept running into the same problem: manually setting up and maintaining GitHub Actions workflows was repetitive, error-prone, and just plain annoying. I wanted a tool that could analyze a project’s structure and automatically generate reliable workflows, tailored to the project’s needs.

What Dodo Does

  • Automates Workflow Generation: No more manual YAML tweaks.
  • Ensures Reliability: Validates configurations to catch errors before they cause issues.
  • Customizes Workflows: Uses a simple dodo.toml and dodo.lock files to adapt to your project’s specific setup.

Looking Ahead

Dodo is still a work in progress, and I’m excited to see where it goes. I’m building it for developers who, like me, want to streamline their workflow setup and avoid the tedious parts of CI/CD configuration.
I welcome your feedback, ideas, and contributions—let’s build something awesome together.

License

Dodo is released under the MIT License. All contributions are covered under the same license unless stated otherwise.

Thanks for checking out Dodo.
Here’s to smoother workflows and more time for coding!

Overview

Kurajo is an integrated suite of tools designed to streamline CI/CD workflow management for developers.
The system is composed of several interlocking components that work together to automate the creation, validation, publishing, and maintenance of workflow templates.

Here’s a high-level view of each component and how they interact:

1. Dodo CLI Tool

  • Purpose:
    Dodo is the command-line interface that developers interact with. Its primary functions include initializing project configurations, generating CI/CD workflows, and managing updates.

  • See commands and configs for additional information.

2. raphus.io Registry

  • Purpose:
    raphus.io is the centralized, community-driven registry for CI/CD workflow templates, plugins, and AI extensions. Think of it as a “marketplace” for composable automation logic—similar to how crates.io serves Rust packages.

  • Structure:

    • Internal Templates: Pre-vetted, high-quality workflow templates for major languages (e.g., Rust, Python, Go, Node.js), maintained by the core Dodomatic team.
    • Plugin System: Raphus.io will support a wide range of plugins—not just workflow templates, but also integrations for alternative CI/CD tools, locally and/or cloud hosted AI models, and even custom template transformers.
    • raphus.io-index:
      A dedicated repository (raphus.io-index) acts as the authoritative index for all templates and plugins. It contains version information, metadata, descriptions, and compatibility tags.

  • Future Vision:
    As the ecosystem matures, raphus.io will evolve into a full plugin platform. Key features include:

    • Fine-grained search and filtering
    • Version pinning and upgrade paths
    • Quality-gated community contributions
    • Support for AI plugin discovery and updates
    • Toolchain-specific extensions (e.g., Bazel, Nix, custom GitLab runners)

raphus.io ensures that Dodo can stay modular, adaptable, and open to a wide range of automation setups—from basic GitHub Actions to advanced, custom pipelines and local/cloud model integrations.

3. Test Repositories (dodo-tests & raphus-tests)

  • Purpose:
    Dedicated repositories that serve as automated test beds for verifying that generated workflows run correctly in real GitHub Actions environments.
  • Workflow:
    • When a PR is submitted to either the Dodo or raphus.io repositories, a bot (Dox) creates a corresponding test branch in the test repo.
    • The generated workflow is committed and executed using GitHub Actions and locally with tools like act.
    • The bot monitors test results and posts feedback (success or detailed error logs) on the original PR.
    • Test branches are retained for debugging and then cleaned up after a set period.

4. Automation & Bot (Dox)

  • Purpose:
    Dox is the automation bot responsible for managing test workflows, verifying PRs, and handling routine maintenance tasks. It ensures that any workflow changes are validated before being merged.
  • Key Functions:
    • Create trigger commits and test branches for new or updated workflows.
    • Run CI/CD tests in a sandboxed environment.
    • Post automated feedback on PRs regarding workflow success or failure.
    • Clean up stale test branches after PRs are merged or closed.

5. Integration & Workflow

  • Initialization:
    A developer starts by running dodo init in their project, which auto-generates a configuration file (dodo.toml) based on the detected project structure.
  • Workflow Generation:
    When dodo build is executed, Dodo pulls the base workflow template from raphus.io, adapts it to the project-specific details (e.g., selecting the right test, lint, build, and deploy commands), and writes the final workflow to the repository's .github/workflows/ folder.
  • Continuous Updates:
    dodo update periodically checks for newer versions of the actions used within the workflow, ensuring that the CI/CD process stays current.
  • External Contributions:
    In later phases, additional workflows can be added to raphus.io through a controlled publishing process (using dodo publish), but for the MVP, contributions are limited to issues and PRs to ensure stability.

6. Scalability & Future Enhancements

  • Modular Design:
    Each component is designed to work independently but also integrate seamlessly. This allows the system to scale as more templates and languages are added.
  • AI Integration (Future Phase):
    Future enhancements might include AI-driven optimization for workflow generation and intelligent debugging of CI/CD pipelines.
  • Community-Driven Growth:
    Once the core system is stable, Dodomatic plans to open up community publishing to make raphus.io a thriving marketplace of CI/CD templates.

Conclusion

From a developer’s point of view, Kurajo's architecture is built to automate and simplify the often tedious process of managing CI/CD workflows. The integration of Dodo, raphus.io, automated testing repositories, and an intelligent bot (Dox) ensures that workflows are not only generated dynamically but are also kept up-to-date and thoroughly validated. This modular, scalable design sets the stage for long-term growth, community involvement, and a robust, open-source ecosystem that will empower developers for years to come.

Feel free to dive into each component’s documentation for more detailed insights.

Happy coding!

Installation

Quickstart

Dodo Commands

🚀 Key Commands:

dodo init

  • Scans the project directory, detecting relevant files while skipping unnecessary ones (.github/, .git/, and test directories specified by the user).
  • Uses Magika to identify file types and sends them to Phi-3 Mini for classification.
  • If a file is a config file, Phi-3 extracts tool versions, dependencies, and relevant settings, then caches it.
  • Non-config files are marked accordingly to avoid redundant processing.
  • Builds dodo.toml incrementally as new configurations are detected.

dodo build

  • Reads dodo.toml and dodo.lock, ensuring an up-to-date understanding of the project.
  • Fetches appropriate templates from raphus.io.
  • Uses Phi-3 and cached data to adapt templates and generate optimized workflows in .github/workflows/.
  • Updates dodo.lock incrementally, recording file paths and ensuring consistency across runs.

dodo add <external-ci>

  • Allows users to integrate external workflow snippets like security scans, Dependabot, or pre-commit hooks.
  • Fetches predefined snippets from raphus.io or user-defined sources.
  • Updates dodo.toml and .github/workflows/*.yml accordingly.

dodo update

  • Checks for changes in cached config files, such as version updates or dependency modifications.
  • Since everything is incremental, only modified files are reprocessed.
  • Ensures minimal overhead by avoiding a full project scan.

dodo sync

  • Detects new configuration files that weren’t previously included in dodo.toml.
  • If a new file (like ruff.toml) is found, Magika identifies it, Phi-3 classifies it, and the file is added to the cache.
  • Users can also remove stale configuration files that no longer exist in the project.
  • Offers an interactive CLI prompt to confirm additions and removals.

dodo upgrade

  • Combines dodo update and dodo build in a single command.
  • Ensures that workflows are fully up-to-date with the latest project changes.

dodo clean [tool]

  • Removes a specific tool (like ruff, clippy, etc.) from CI/CD while keeping its config file intact.
  • Running without arguments removes tools not backed by existing config files.
  • External integrations such as security checks remain untouched.

🛠 Configuration Files:

dodo.toml

  • Incrementally built during dodo init and dodo sync.
  • Defines project-specific CI/CD settings based on detected tools.
  • Updated only when new configurations are detected.

dodo.lock

  • Stores resolved tool versions, workflow template sources, and config file paths.
  • Ensures that workflows remain consistent over time.
  • Built incrementally to maintain efficiency.

Dodo keeps things fast and efficient by working incrementally—only scanning and updating what's necessary. No redundant processing, no unnecessary slowdowns. Whether you're setting up workflows for the first time or keeping them updated, Dodo ensures everything runs smoothly with minimal effort.

dodo.toml Configuration

dodo.toml is the configuration file for Dodo. It lets you customize your CI/CD workflows, defining build steps, linting, testing, deployment, and more in a simple, readable format.

Default Configuration (dodo init)

Running dodo init creates a default dodo.toml file. Here’s a basic example:

[project]
name = "my-awesome-project"
language = "your-language"
ci_provider = "github-actions"

[ci]
auto_update = true
workflow_file = ".github/workflows/ci.yml"
branch_protection = true

[build]
enabled = true
tools = ["build_tool"]
build_tool = { version = "x.x.x", options = ["option1", "option2"] }

[lint]
enabled = true
tools = ["lint_tool"]
lint_tool = { version = "x.x.x", args = "--your-args" }

[test]
enabled = true
tools = ["test_tool"]
test_tool = { args = "--your-args" }

[deploy]
enabled = false
tools = ["deploy_tool"]
deploy_tool = { image = "your-registry/your-project", tag = "latest", branch = "deploy-branch" }

[env]
VAR_1 = "value1"
VAR_2 = "value2"

[matrix]
your_language = ["version1", "version2", "version-nightly"]

[cache]
enabled = true
paths = ["path/to/cache1", "path/to/cache2"]

[notifications]
enabled = true
tools = ["notify_tool"]
notify_tool = { webhook_url = "your-webhook-url", channel = "#your-channel" }

[hooks]
pre_commit = ["command1", "command2"]
post_merge = ["command3"]

[security]
dependabot = true
vulnerability_check = true

[docs]
enabled = true
tools = ["docs_tool"]
docs_tool = { version = "x.x.x", theme = "your-theme", output_dir = "docs/output" }

[plugins]
python = "https://github.com/kurajo/dodo-python"
rust = "https://github.com/kurajo/dodo-rust"

[ai]
enabled = true
model = "phi-3-mini-128k"

Sections Overview

[project]

Defines basic project settings.

  • name: Project name.
  • language: Programming language (rust, python, node, etc.).
  • ci_provider: CI/CD provider (currently supports github-actions).

[ci]

Manages global CI/CD settings.

  • auto_update: Automatically updates workflows.
  • workflow_file: Location of the generated workflow file.
  • branch_protection: Enforces branch protection rules.

[build]

Defines build settings.

  • enabled: Enables/disables the build process.
  • tools: List of build tools (e.g., cargo, go, setuptools).

[lint]

Manages linting tools.

  • enabled: Enables/disables linting.
  • tools: List of linters (e.g., clippy, ruff, eslint).

[test]

Configures testing tools.

  • enabled: Runs tests if true.
  • tools: Testing tools (e.g., cargo-test, pytest, go-test).

[deploy]

Handles deployment settings.

  • enabled: Enables/disables deployment.
  • tools: Deployment options (e.g., Docker, GitHub Pages).

[env]

Defines environment variables.

[matrix]

Supports matrix builds for testing multiple versions.

[cache]

Defines caching strategies to speed up builds.

[notifications]

Sets up build status notifications (e.g., Slack, Discord).

[hooks]

Runs automated scripts before or after specific actions.

[security]

Configures security checks.

[docs]

Defines documentation generation settings.

[plugins]

Adds custom configurations via plugins.

Example Configurations

Rust Project

[project]
name = "rust-app"
language = "rust"
ci_provider = "github-actions"

[build]
enabled = true
tools = ["cargo"]
cargo = { version = "1.74.0", features = ["default"] }

[lint]
enabled = true
tools = ["clippy"]
clippy = { version = "latest", args = "--fix" }

[test]
enabled = true
tools = ["cargo-test"]
cargo-test = { args = "--release" }

[ci]
auto_update = true
workflow_file = ".github/workflows/ci.yml"
branch_protection = true

[plugins]
rust = "https://github.com/kurajo/dodo"

Node.js Project

[project]
name = "node-app"
language = "node"
ci_provider = "github-actions"

[build]
enabled = true
tools = ["npm"]

[lint]
enabled = true
tools = ["eslint"]
eslint = { version = "latest", args = "--fix" }

[test]
enabled = true
tools = ["npm-test"]

[deploy]
enabled = true
tools = ["docker"]
docker = { image = "ghcr.io/username/node-app", tag = "latest" }

[custom_workflows]
pre_ci = ["echo 'Starting CI for Node.js app'"]
post_ci = ["echo 'CI process complete'"]

[env]
NODE_ENV = "production"

[notifications]
enabled = true
tools = ["slack"]
slack = { webhook_url = "https://hooks.slack.com/services/...", channel = "#ci-updates" }

[plugins]
python = "https://github.com/kurajo/dodo-python"

How Dodo Uses dodo.toml

  1. Parsing: Reads dodo.toml from the project root.
  2. Workflow Generation: Creates .github/workflows/ci.yml based on your settings.
  3. Automation: Reduces manual YAML editing and ensures consistency.

Get Involved

Have suggestions or feature requests? Open an issue or contribute at GitHub.

raphus.io

raphus.io is the official CI/CD workflow registry for Dodo. It provides a structured repository of standardized GitHub Actions workflow templates and plugins that enable Dodo to generate and manage CI/CD pipelines reliably, consistently, and intelligently (local or cloud AI, depending on what you need).

This documentation covers the current architecture, integration flow with Dodo, usage recommendations, and contribution guidelines.

Table of Contents

Overview

raphus.io is a versioned, community-driven registry of workflow templates and plugins that power Dodo's local generation and management of GitHub Actions pipelines. Inspired by platforms like crates.io, it aims to be the definitive source for scalable, high-quality, and reproducible workflows.

Key Features

  • Registry for Templates & Plugins: Hosts reusable, customizable workflow templates and plugins.
  • Template System: Maps languages and frameworks to predefined workflows using the raphus.io-index.
  • Plugin System: Enables logic extension (e.g., environment setup, secrets handling) in a modular, reusable way.

Architecture

1. Template System

  • Templates are structured YAML files with placeholders ({{ }}) for project-specific substitutions.
  • Templates are indexed using the raphus.io-index repository.
  • Each template:
    • Supports semantic versioning
    • Includes metadata such as supported languages, frameworks, and toolchains
    • Can declare optional plugin hooks for pre-/post-generation logic

2. Plugin System

  • Plugins are executable logic components (e.g., environment validators, version matchers, secret injectors).
  • Hosted in the same registry as templates.
  • Can be:
    • Native (Rust) binaries
    • Scripts or WASM modules
  • Executed locally as part of Dodo’s build pipeline.

3. Local AI Integration

  • Phi-3 Mini 128K is used to:
    • Extract metadata from source files (e.g., detect build systems, testing tools, or frameworks)
    • Assist in template selection and plugin orchestration
  • All inference is performed locally with no cloud access.

Integration with Dodo

How raphus.io Fits into Dodo’s Workflow

  1. Initialization (dodo init)

    • Dodo scans the project environment.
    • Phi-3 Mini 128K extracts relevant information.
    • Dodo fetches a suitable template and plugin set from raphus.io using raphus.io-index.

  2. Configuration (dodo.toml)

    • The user configures build, lint, test, and deploy steps.
    • This config customizes template rendering.

  3. Build (dodo build)

    • Templates are rendered locally using the settings in dodo.toml.
    • Plugins are executed if needed to adjust or verify behavior.
    • Final CI/CD workflow is saved in .github/workflows/ci.yml.

  4. (Optional) Auto-Update

    • Users can enable workflow and plugin version auto-updates using dodo.toml.

Usage Guidelines

Getting Started

  1. Run Initialization

    dodo init

    This creates a dodo.toml file and fetches a recommended template from raphus.io.

  2. Configure Your Project

    • Edit dodo.toml to define:
      • Build tools
      • Lint/test commands
      • Deployment configuration
      • Plugin preferences

  3. Generate Your Workflow

    dodo build

    This generates .github/workflows/ci.yml using templates and plugins from raphus.io.

  4. Commit & Push

    • Commit your .github/workflows/ directory to your VCS.
    • Your CI/CD pipeline is now live.

Contributing

We welcome contributions to raphus.io!

  1. Fork the repository.
  2. Add your template/plugin
    • Follow template guidelines in TEMPLATE_GUIDELINES.md.
    • Follow plugin interface in PLUGIN_GUIDELINES.md.
  3. Submit a Pull Request.
    • Include metadata (version, language tags, etc.)
    • Add a test project if possible.

License & Support

raphus.io is licensed under the Elastic License 2.0 (ELv2).

You may:

  • Use, modify, and distribute the source freely for personal or internal use.

You may not:

  • Host raphus.io as a service or provide managed access to it.
  • Remove or obscure copyright.
  • Circumvent license enforcement, if any.

For more details, read the full Elastic License 2.0.

Happy building! 🚀
Questions or feedback? Join our GitHub Discussions or file an issue.

Internal Working of Dodo

Overview

Dodo is an AI-powered CI/CD automation tool that intelligently parses a project’s configuration files, detects tools for various development workflows (linting, testing, building, deploying), and generates optimized GitHub Actions workflows. It caches detected configurations for fast lookups and ensures that changes in project dependencies are seamlessly integrated into CI/CD pipelines.

Project Parsing

  1. Full Project Scan:

    • Uses Magika (by Google) to identify and classify files.
    • Uses local or cloud to determine whether a file is a configuration or an "interest" file (i.e., relevant to linting, testing, building, or deployment).

  2. Parsing Configuration Files:

    • Once files of interest are identified, Dodo parses the file and use AI to extract relevant tool configurations.
    • Extracts tool names, versions, dependencies, and settings from files like:
      • pyproject.toml, setup.py, requirements.txt (Python)
      • Cargo.toml (Rust)
      • package.json (Node.js)
      • Makefile, CMakeLists.txt (C/C++)
      • clippy.toml, .prettierrc, .eslint.json (Linters and formatters)

  3. Generating dodo.toml:

    • AI processes the extracted data and generates a structured dodo.toml with:
      • Detected tools and their versions
      • CI/CD configurations for linting, testing, building, and deployment
      • Additional settings for caching, notifications, hooks, and security checks

2. Dependency Updates & CI/CD Syncing

Dependency Management

  • Many users rely on Dependabot or manual updates to bump dependency versions.
  • Once new versions are pulled locally, running dodo update will:
    • Use the cached file locations to rapidly find relevant config files.
    • Parse them for updated versions and reflect the changes in dodo.toml.
    • Update the corresponding dodo.lock file.

CI/CD Workflow Synchronization

  • dodo update or dodo upgrade also ensures:
    • Only new/modified files are re-parsed, optimizing execution speed.
    • If a new configuration file is detected (e.g., clippy.toml added), it gets automatically included in dodo.toml.

3. Adding External Integrations

Dodo allows users to integrate external CI/CD tools using:

dodo add <external-ci>
  • This fetches workflow templates from raphus.io (Dodo’s template registry) and adds them to .github/workflows/*.yml.
  • Example integrations:
    • Security Scans: Trivy, Snyk, CodeQL
    • Dependency Updaters: Dependabot, Renovate
    • Pre-commit Hooks: Black, Prettier, pre-commit
  • dodo add ensures these integrations persist even when running dodo clean.

4. Building & Regenerating CI/CD Workflows

Fetching & Adapting CI/CD Templates

  • When running dodo build, Dodo:
    • Fetches base workflow templates from raphus.io.
    • Uses AI to adapt them according to project structure.
    • Generates .github/workflows/ci.yml.

Updating vs. Upgrading

  • dodo update: Updates dependency versions in dodo.toml.
  • dodo upgrade: Updates dependency versions in dodo.toml and dodo.lock both.

5. Cleaning CI/CD Configuration

Implicit Cleanup

dodo clean
  • Removes all tools (testing, linting, building, deploying) from CI/CD if their config files are not present in the project.
  • Does not remove external integrations (e.g., Dependabot, pre-commit, security scans).

Explicit Tool Removal

dodo clean <tool>
  • Removes specific tools from CI/CD even if their config files still exist.
  • Example: 
    dodo clean ruff
    • Removes Ruff from CI/CD but keeps Flake8 if both are present.

Final Thoughts

Dodo is designed to minimize manual CI/CD management by ensuring:

  • Automatic detection of project tools.
  • Smart dependency updates leveraging cached file locations.
  • Seamless workflow synchronization.
  • Fast and flexible cleanup operations.

By integrating AI-powered parsing with a robust caching mechanism, Dodo ensures blazing-fast execution while maintaining an up-to-date and optimized CI/CD pipeline. 🚀

Generation of dodo.toml

  1. 🧠 Magika detects file types → Fast, parallel, respects .gitignore and exclusions

  2. 📥 Phi-3 checks if path (or name) indicates it's a config file → e.g., pyproject.toml, ruff.toml, .prettierrc, go.mod, Cargo.toml → If "maybe config", proceed. Otherwise skip.

  3. 🔄 Convert config file to JSON → Use a modular "parser adapter" interface

    • toml → json: toml
    • yaml → json: serde_yaml
    • ini → json: configparser or write mini-parser
    • go.mod, etc.: external Go tool → output JSON

  4. ✅ Send JSON to CUE → If schema available, validate and normalize → If schema not available, attempt inference (CUE supports structural inference)

  5. 🧩 CUE returns clean, schema-aligned JSON → Structure now looks like:

    {
  "tool": "ruff",
  "version": "0.4.3",
  "config": { ... }
}

  6. 🧠 Phi-3 Mini processes clean JSON → Now it's not hallucinating keys, confused by indentation or nesting → Output: { tool: "ruff", deps: [...], config_version: "0.4.3" }

  7. 📤 Dodo generates or updates dodo.toml → Merge strategy can be:

    • strict (overwrite)
    • merge (preserve and add)
    • interactive (prompt if conflict, optional)

Troubleshooting

raphus.io

ProblemSolution
No workflow generatedCheck for errors in dodo.toml. Verify your project type is supported.
Network issuesraphus.io is only used for downloading templates/plugins — retry later.
Template does not applyTry updating Dodo or specifying a fallback template in dodo.toml.
Plugin fails to runEnsure local plugin dependencies are met (e.g., wasmtime if using WASM).

Frequently Asked Questions

raphus.io

Q: How are templates selected?

Templates are chosen using:

  • Language/framework mappings from raphus.io-index
  • Metadata extracted by Phi-3 from your codebase
  • Overrides or hints in dodo.toml

Q: Can I override templates or plugins?

Yes. You can:

  • Provide a local template path in dodo.toml
  • Override plugin behavior by specifying local versions
  • Disable plugins with plugins.disabled = [...]

Licenses

Dodo is released under a dual-license model, allowing users and contributors to choose between the following licenses:

  • Apache License 2.0 – A permissive license with an explicit grant of patent rights, providing legal protection for both users and contributors.
  • MIT License – A highly permissive license that allows nearly unrestricted use, modification, and distribution of the codebase.

Unless explicitly stated otherwise, all contributions to this repository are licensed under the terms of both licenses listed above.

Contribution Guidelines

By submitting a pull request, issue, or any contribution to this project, you agree that your contributions will be licensed under both the Apache 2.0 and MIT licenses.
This ensures that all users benefit from a consistent and open licensing model.

If you wish to contribute under a different license, please state it explicitly in your pull request.

Third-Party Dependencies

This project may include dependencies that are licensed under different terms. It is the responsibility of contributors and users to ensure compliance with third-party license agreements when using or distributing Dodo.

Additional Notes

  • If you have any legal concerns regarding the licensing of this project, please open an issue or contact the maintainers.
  • The maintainers reserve the right to update this licensing document as necessary, ensuring continued clarity and compliance with best practices.