Getting Started

Install with composer require tomatophp/tomato-eddy and ensure the underlying Eddy package is installed and migrated first. Tomato plugins are usually auto-discovered; if not, register the plugin/provider in your Tomato panel configuration.
Look first at:
- config/tomato-eddy.php for panel/navigation/resource settings.
- src/TomatoEddyServiceProvider.php for registration, publishing, and route/migration loading.
- database/migrations for the site_id-related schema and ordering.
- routes/ and src/Filament (or Tomato resource classes) for the server/site/deployment UI.
Publish and run migrations before opening the panel:

php artisan vendor:publish --tag=tomato-eddy-config
php artisan vendor:publish --tag=tomato-eddy-migrations
php artisan migrate

First use case: add a server with SSH credentials, create a site under that server, then trigger a deployment from the Tomato panel. Confirm the deployment record is linked to the correct site_id before wiring it into any automation.

Implementation Patterns

Use the Tomato resource UI for day-to-day server/site/deployment management, but keep deployment logic in queued jobs. Deployments should not run synchronously inside a panel request.
Scope deployment queries through the site relationship rather than querying deployments globally:

$site = Eddy\Models\Site::findOrFail($siteId);

$site->deployments()
    ->latest()
    ->first();

For custom workflows, call Eddy’s deployment service/actions directly from an Artisan command or job, then persist or update the deployment record with the correct site_id.
Integrate with CI by exposing a small authenticated endpoint or Artisan command that triggers a deployment for a known site ID. Keep authorization checks in the panel/policy layer, not only in the UI.
Use events/listeners for deployment status changes where available, so notifications, Slack messages, or audit logs do not block the deployment process.
For multi-tenant or multi-site setups, treat site_id as the primary scoping key everywhere: policies, table filters, deployment history, and any custom reports.
Keep server-specific and site-specific settings in the database (server credentials, repository/branch, deploy path) rather than in config files, so panel users can manage them without redeploying code.

v1.0.20 fixes a site_id not exists issue. If you hit “column not found: site_id” or a foreign-key/migration error, upgrade to v1.0.20, republish migrations if needed, and run php artisan migrate. Then verify the column exists:

php artisan tinker
Schema::hasColumn('eddy_deployments', 'site_id');

Migration order matters. Eddy’s sites table must exist before any deployment migration references site_id. If you have an existing install, check php artisan migrate:status and inspect the deployment migration rather than editing vendor files.
Clear cached config after publishing or changing panel settings:

php artisan config:clear
php artisan optimize:clear

Deployments need a queue worker. If the panel shows a deployment as queued or stuck, check php artisan queue:work is running and review failed jobs before assuming the package is broken.
SSH failures are usually environmental: key permissions, known_hosts, the deploy user’s shell, or missing write permissions on the target path. Test the same SSH command manually before debugging package code.
Avoid hard-coding site_id values in code or seeders. Resolve sites by a stable slug/domain/path and store the ID only in the database.
When extending the panel, prefer policies and scoped queries over global model scopes that hide records unexpectedly. A global site_id scope can make admin/debug pages confusing.
Use the package’s published config and resource extension points rather than overriding vendor classes. If you must customize a resource, extend it and re-register it in the panel provider.
For debugging deployment failures, check the deployment log/record first, then Laravel logs, then the queue worker output. Most “package bugs” in this area are migration order, queue, or SSH connectivity issues.