Colonel Smoker Bundle Laravel Package

Getting Started

Before you composer require anything, note the shape of the package: lag/colonel-smoker-bundle is a Symfony bundle (vendor larriereguichet, package type symfony-bundle). Laravel's package auto-discovery will not register it, there is no ServiceProvider, and its classes are wired through Symfony's DI container. As a Laravel developer, the realistic first move is to treat it as a reference implementation for smoke-testing rather than a drop-in dependency.

Where to look first:

1. composer.json — confirm the Symfony/framework version constraints and PHP floor. A 2019 bundle will likely cap at Symfony 4/5 and PHP 7.x, which is a hard blocker on modern Laravel 10/11 (PHP 8.1+).
2. src/ColonelSmokerBundle.php and src/DependencyInjection/ — see what services it registers and what configuration keys it accepts.
3. src/Command/ and src/Controller/ — this is where the actual "smoke" check lives (a console command and/or a health route).
4. Resources/config/ — service definitions and any routing/health endpoint.

First use case, translated to Laravel — a deploy-time smoke gate you can run after artisan migrate:

// app/Console/Commands/SmokeCheck.php
public function handle(): int
{
    $checks = [
        'db'    => fn () => DB::select('select 1') !== null,
        'cache' => fn () => Cache::put('smoke', 1, 10) && Cache::get('smoke') === 1,
        'storage' => fn () => Storage::disk('local')->put('smoke.txt', 'ok'),
        'routes' => fn () => Route::has('login'),
    ];

    $failed = 0;
    foreach ($checks as $name => $check) {
        try {
            $check() ? $this->info("ok  {$name}") : throw new \RuntimeException();
        } catch (\Throwable $e) {
            $failed++;
            $this->error("FAIL {$name}: {$e->getMessage()}");
        }
    }
    return $failed === 0 ? self::SUCCESS : self::FAILURE;
}

If you genuinely are on Symfony (mixed team, legacy service), then composer require lag/colonel-smoker-bundle, add it to config/bundles.php, and run bin/console list colonel to discover the actual command names.

Implementation Patterns

Deploy gate, not a monitor. Run the smoke check as a post-deploy CI step (php artisan app:smoke) so a broken DB credential or missing cache driver fails the pipeline in seconds rather than after the first user request.

Two surfaces, one implementation. Expose the same checks as an HTTP endpoint for load balancers/uptime probes and as a console command for CI. Keep the logic in one class and have both call it:

Route::get('/health', HealthController::class)->middleware('throttle:60,1')
     ->name('health');

Return structured JSON ({"status":"ok","checks":{...}}) with HTTP 200/503 — that's what Kubernetes/ALB/uptime services actually consume.

Translate the Symfony concepts, don't port them. The bundle's patterns map cleanly:

Polyglot adapter. If the rest of the org runs this bundle in Symfony services, standardize the response contract (JSON shape, status codes) so your Laravel health endpoint and theirs are interchangeable to the ops layer.

Keep checks idempotent and cheap. Each check should be a single round-trip and safe to run repeatedly. No writes you can't roll back (the Storage::put above is the borderline case — prefer exists() in production).

Gotchas and Tips

• Abandoned and tiny. Last release 2019-11-15, 3 stars, 0 dependents. Treat it as documentation of an idea, not a maintained dependency. Audit it before pulling into anything, and expect the Symfony version constraints to be the real blocker.
• Not a Laravel package. No laravel/framework requirement, no service provider, no facade. composer require will install but nothing auto-wires; you'd be writing an adapter for what is essentially a one-command bundle.
• "Smoke" ≠ smoke and mirrors. This is a liveness/smoke check, not APM, not load testing, not a synthetic monitor. Don't overload it with paging or metrics.
• Probe semantics. For a liveness probe, checks should only confirm the app itself booted — not external dependencies, or you'll restart healthy pods when the DB is down. Put dependency checks in a readiness endpoint instead.
• Config quirks. If you do read the source, inspect DependencyInjection/Configuration.php for env var names and defaults; undocumented bundles often carry odd naming and required keys that fail only at container compile time.
• Debugging in Symfony: bin/console debug:container --tag=... and debug:router show how it wired itself; the profiler will show the health request. In Laravel, php artisan about and php artisan config:show smoke are your equivalents.
• Extension points worth copying: decorators around individual checks and tagged collectors are the right shape — they let you add a check without editing the core command. Mirror that in Laravel with a SmokeCheck interface and tagged() bindings so contributors add files, not switches.
• Version pin. If a sibling Symfony app must use it, pin the exact version and lock Symfony below the bundle's cap to avoid a container-compilation surprise on upgrade day.
• Don't expose /health publicly unauthenticated beyond what your infra needs; it leaks which subsystems are down. Bind it to internal networks or guard with a shared token.