Deploy Tasks Bundle Laravel Package

Getting Started

Start by installing the package and reviewing its config, migrations, and console command registration. Look first for the package README and any config/deploytasks.php-style configuration to understand how deploy tasks, task groups, and execution records are stored. Confirm which storage backend you are using: JSON/filesystem or DBAL.

The first practical use case is defining deploy tasks in code, running them through the package’s normal Artisan entry point, and then inspecting execution history. In v0.6.0, the new deploytasks:prune command is the first thing to try after removing or renaming tasks/group slots:

php artisan deploytasks:prune --dry-run

Review the dry-run output before pruning anything. Once the scope looks correct, run it interactively or use --force in automation.

Implementation Patterns

Use the package as the source of truth for deploy task definitions, then treat execution records as historical data that can become stale when tasks or group slots are deleted from code. A typical day-to-day workflow is:

1. Add/modify deploy tasks and group slots in code.
2. Run deploy tasks normally.
3. When removing tasks or group slots, run deploytasks:prune --dry-run to inspect orphaned execution records.
4. Prune interactively in local/dev, or with --force / --no-interaction in CI/CD and scheduled maintenance.

Useful patterns:

• Schedule pruning periodically after deployments or code cleanup, e.g. weekly, with --force and appropriate logging.
• Scope cleanup with --group when only one task group was removed or renamed.
• Keep --dry-run in deployment pipelines as an audit step, then run the real prune only when the diff is expected.
• Use the interactive confirmation locally to avoid accidental deletion; use --force only where the environment is non-interactive and the scope is known.
• If you maintain multiple environments, run dry-run against production-like data before enabling forced pruning there.

The command is especially relevant after refactors that delete tasks or group slots, because those changes can leave execution records orphaned in JSON/filesystem or DBAL storage.

Gotchas and Tips

• Orphaned records are created when tasks or group slots are removed from code but their execution records remain in storage. Run deploytasks:prune --dry-run after any task/group cleanup.
• The prune command supports JSON/filesystem and DBAL storage backends. Confirm your backend is supported before relying on it for cleanup.
• --dry-run is your friend. Use it first in every environment, especially production, and compare the reported records against recent task/group changes.
• Interactive confirmation is the default safety mechanism. Use --force or --no-interaction only for automation where the scope has already been validated.
• --group filtering is useful for targeted cleanup, but verify group names carefully; a typo may produce an empty or unexpected scope.
• Back up execution data before the first production prune if the records matter for auditing or debugging.
• Shell completion is available, so wire it into your local shell if you use the command often.
• When debugging unexpected prune results, check whether tasks were renamed rather than deleted; renamed tasks can look like orphaned records depending on how the package tracks identities.
• Treat the prune command as maintenance, not part of normal deploy execution. Keep it separate from deployment steps unless you have a deliberate cleanup stage.