Robo Config Laravel Package

Product Decisions This Supports

• Standardizing DevOps/Build Configurations: Enables consistent, maintainable Robo task configurations across environments (local, CI, staging) by centralizing defaults in robo.yml.dist and allowing overrides via robo.yml or CLI flags. Reduces "works on my machine" issues.
• Build vs. Buy: Buy for teams already using Robo (or planning to adopt it) to avoid reinventing config management. Avoids custom scripting for YAML/CLI overrides.
• CI/CD Pipeline Optimization: Supports dynamic configuration injection via CLI args (e.g., --site.url=http://ci.example.com), enabling zero-config CI builds or environment-specific tweaks without modifying source.
• Multi-Environment Deployments: Useful for projects with shared codebases but environment-specific settings (e.g., Drupal/Silex sites with settings.php generation).
• Developer Experience: Reduces onboarding friction by letting new devs override defaults locally without touching core configs.
• Roadmap: Aligns with initiatives to modularize build scripts or migrate from custom shell scripts to Robo.

When to Consider This Package

• Avoid if:
  • Your team doesn’t use Robo (or PHP-based build tools). This is Robo-specific.
  • Configurations are static (no overrides needed across environments).
  • You’re using non-YAML configs (e.g., JSON, TOML, or environment variables exclusively).
  • Your project doesn’t generate PHP configs (e.g., if you’re not using Drupal/Silex or similar).
  • You need advanced secrets management (e.g., encrypted values). This package handles plaintext overrides only.
• Consider alternatives if:
  • You need dynamic config validation (e.g., schema enforcement) → Use symfony/yaml + custom validation.
  • You require runtime config reloading → Explore symfony/dependency-injection or phpdotenv.
  • Your team prefers infrastructure-as-code tools (e.g., Terraform, Ansible) for environment management.

How to Pitch It (Stakeholders)

For Executives/Stakeholders

"This package lets us standardize our build configurations across all environments—local devs, CI, and production—while keeping them flexible. Instead of hardcoding paths or settings in scripts (which break when environments change), we define defaults in a single file (robo.yml.dist) and let teams override them locally or via CI flags. For example, a developer can run ./robo deploy --site.url=staging.example.com without modifying shared code. This reduces build failures, speeds up onboarding, and makes our deployment pipeline more resilient. It’s a lightweight, PHP-native solution that integrates seamlessly with our existing Robo tasks—no new tools or learning curves."

Key Outcomes: ✅ Fewer build failures (consistent configs across environments). ✅ Faster developer ramp-up (local overrides reduce friction). ✅ CI/CD efficiency (dynamic configs via CLI args). ✅ Lower maintenance (centralized defaults, no duplicated configs).

For Engineering Teams

*"This package solves two pain points:

1. Config Management: It merges robo.yml.dist (shared defaults) with robo.yml (local overrides) and CLI args, so we can tweak settings without editing files. Example: Override site.url in CI without changing the repo.
2. PHP Config Generation: Need to inject YAML configs into settings.php (e.g., for Drupal/Silex)? It provides tasks to append/prepend/write PHP arrays from YAML, with customizable block comments and keys.

Why Use It?

• No more sed/awk hacks for config injection.
• Works with existing Robo tasks—just add the trait and start using $this->config('key').
• Lightweight: ~100 lines of code, no external dependencies beyond Robo/YAML.

Example Use Case: If your robo.yml.dist defines a database.host, a dev can override it in robo.yml, and CI can override it via --database.host=ci-db.example.com. The same config is then used across all Robo tasks.

Trade-offs:

• GPL-2.0 license (ensure compliance if using in proprietary projects).
• Limited to YAML/CLI overrides (not a full secrets manager)."*