Gally Sample Data Laravel Package

Getting Started

This is not a Laravel package. There is no service provider, no config/ to publish, and no migrations. gally/gally-sample-data is a Composer-installable bundle of fixture/demo data (catalog, products, attributes, merchandising rules) for the Gally searchandising engine — a PHP/Symfony + Elasticsearch-style stack. Treat it as a data artifact plus CLI tooling, not a framework dependency.

Minimal path:

1. Inspect before installing. Read composer.json (look at require for the Gally core version and the Symfony 7.4 floor introduced in v2.3.1), the README, and any bin/ or Command/ directory. You are looking for the console command(s) that load fixtures — that command name is the whole integration surface.
2. Add it as a dev dependency in the repo that actually hosts Gally, not in your Laravel app:

   composer require --dev gally/gally-sample-data
   

3. Have a running Gally + search engine (Docker Compose is the usual route) on a Symfony 7.4-compatible image, with indexes created per the Gally schema version you pinned.
4. Run the seed command, then verify documents landed:

   curl -s "localhost:9200/_cat/indices?v"
   

5. First real use case: you're building a storefront or a search UI in Laravel and need a realistic catalog to develop against. Load sample data once, point your Laravel HTTP client at Gally's API, and you have search, facets, and sorting to build against without writing your own fixture pipeline.

Where to look first, in order: README → composer.json version constraints → the console command source → the fixture file layout. The layout tells you what "a product" looks like in Gally's model, which is what your Laravel models/DTOs must mirror.

Implementation Patterns

Bootstrap script, not a migration. Because there are no Artisan hooks, the idiomatic pattern is a shell entrypoint or Composer script:

"scripts": {
  "sample-data": "bin/console gally:sample-data:load"
}

Keep it idempotent-safe by wrapping it: reset indexes → load → smoke-test one known SKU.

Wrap the invocation in an Artisan command. If your Laravel app orchestrates the local stack, a thin command keeps the workflow discoverable:

$result = Process::timeout(300)->run('docker compose exec -T gally bin/console gally:sample-data:load');

Fail loudly on non-zero exit; fixture loaders frequently return 0 while logging per-document errors, so grep stdout for error counts too.

Feature tests against known data. The highest-value pattern: sample data gives you stable, named products. Assert against specific identifiers rather than "some results":

$response = Http::baseUrl(config('gally.url'))
    ->get('/api/products', ['q' => 'shirt', 'category' => 'men']);

Pin the package version so those assertions don't silently rot when upstream edits fixtures.

CI as ephemeral seed. Spin up the search engine container, run the loader, execute integration tests, tear down. Never cache a seeded index between CI runs — mapping drift between the image and the fixture set is the number one flake source.

Environment scoping. Dev and staging only. Guard the loader behind app()->environment(['local','staging']) if you wrap it, and make the base URL an env var so a misconfigured .env can't point seeding at production.

Subsetting for speed. Full catalogs slow test suites. Either maintain a small override fixture directory (check whether the command accepts a path/--limit flag) or load once into a long-lived local index and use transactions-free read-only tests against it.

Gotchas and Tips

• v2.3.1 is a dependency-only release — but it raises the floor. The sole change is "Update symfony to 7.4". Nothing in the fixture payload or command surface changed, so no data migration is needed; however, the package now requires a Symfony 7.4 host. If your Gally stack (or a sibling bundle in the same Composer graph) is still on 6.x/7.0–7.3, composer update will either hold you back at 2.3.0 or fail resolution. Bump the Gally host image first, then the fixtures.
• Zero stars, zero dependents, one maintainer org. Assume breaking changes without deprecation cycles. Pin an exact version ("gally/gally-sample-data": "2.3.1"), commit the lockfile, and budget for reading diffs on upgrade. The 2.3.0 → 2.3.1 diff is a one-liner, which is a good reminder to actually read them.
• No Laravel auto-discovery. Don't add it to config/app.php providers or expect php artisan vendor:publish. If you find yourself writing a service provider for this, you're over-engineering — a Process call or a shell script is correct.
• Schema coupling is the real footgun. Fixture documents are written against a specific Gally/Elasticsearch mapping. Upgrade Gally core without upgrading sample data (or vice versa) and you get silent partial indexing: documents accepted, fields dropped, facets empty. Always upgrade the pair together — and note the Symfony minor-version coupling now makes this a three-way constraint (Gally core ↔ Symfony ↔ fixtures).
• Idempotency. Re-running the loader usually appends rather than replaces. Make index deletion explicit in your reset step, and never assume "load twice" is harmless.
• Memory and heap. Sample catalogs are bulk-indexed; a default 512 MB search container will OOM mid-load and leave a half-populated index that looks like an application bug. Bump heap in your compose file before debugging your query code.
• Debugging order: _cat/indices for doc counts → Gally's own logs (Symfony var/log/) → the loader's stdout. The loader rarely throws; it logs. Read stdout.
• Extension points are filesystem-level. You customize by forking the fixture files or pointing the loader at an override directory — not by subclassing. Keep your customizations in a separate repo/path so upstream updates stay mergeable.
• License: OSL-3.0. Reciprocal, not plain MIT. Fine for internal/dev usage; if you redistribute derived fixture data or bundle it into a distributed product, get a legal read rather than assuming Composer-installable means permissive.
• Don't commit the seeded volume. Index data and any Elasticsearch data directory belong in .gitignore and Docker named volumes.