Ghygen Laravel Package

Product Decisions This Supports

• Time-to-first-CI for new Laravel services. ghygen scaffolds GitHub Actions workflow YAML from a guided set of choices, so greenfield projects get a working test/build pipeline without hand-writing boilerplate. The v1.0.1 release brings the templates current with PHP 8.3, Laravel 11, and Node 20, so new projects scaffold against a modern stack rather than a year-old baseline.
• Standardization across a portfolio of Laravel repos. If the org runs many Laravel services on GitHub, this can be the canonical way to emit consistent workflow files, reducing config drift between teams. Updated action versions (checkout@v4, cache@v4, setup-node@v4, codeql upload-sarif@v3, etc.) mean emitted workflows start closer to current best practice.
• Build vs. buy vs. template. It frames the real decision between (a) a shared template repo of .github/workflows snippets, (b) this generator, or (c) a bespoke internal generator — the trade-off is maintenance cost versus customization depth.
• Developer-experience roadmap. A concrete signal that teams value CI onboarding and reducing "first PR fails the pipeline" friction; can justify investment in internal platform tooling.
• Migration path to GitHub Actions. Useful when moving off Jenkins/GitLab CI and standardizing on GitHub, lowering per-repo migration cost. Current action-version coverage reduces the post-generation cleanup (e.g., bumping deprecated actions/*@v2/v3) that otherwise eats into migration savings.
• Not a runtime dependency. It emits a file; after generation the tool can be dropped entirely, so production risk is near zero.

When to Consider This Package

Consider it when:

• You're on Laravel/PHP and standardizing CI on GitHub Actions.
• You have a repeated need to scaffold or refresh workflow YAML (new services, forks, training repos).
• You're comfortable treating it as a dev-time, generate-once tool — you commit the YAML and can walk away from the tool.
• You want a fast starting point you will review and customize anyway.
• You want current-ecosystem defaults. v1.0.1 adds PHP 8.3, Laravel 11, and Node 20 selectors and refreshes pinned action versions, so generated workflows no longer ship stale, deprecated actions — reducing review churn.

Look elsewhere when:

• Your CI is GitLab/Bitbucket/Azure — the output is GitHub-specific.
• You need advanced or specialized pipelines (complex caching, matrix builds, reusable workflows, OIDC to cloud, self-hosted runners) beyond its templates.
• You require a broadly adopted, battle-tested component: 0 dependents and a low package score remain adoption red flags. Freshness is now less of a concern — v1.0.1 shows active maintenance — but community validation is still thin, so treat it as a low-support OSS component.
• You're outside the Laravel/PHP world.
• You have security/compliance constraints — audit exactly what YAML it emits before adopting; even a maintained generator should not inject unreviewed CI permissions or secret usage.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed developer tool that auto-generates GitHub Actions CI configuration for Laravel projects. The v1.0.1 release shows the project is actively maintained — it now targets PHP 8.3, Laravel 11, and Node 20 and updates pinned actions to current versions, addressing the earlier freshness concern. Upside is faster onboarding and consistent pipelines across services; cost is essentially zero since it is dev-only and outputs a file we own and commit. Risk is contained — no runtime dependency — but adoption remains minimal (zero dependents), so we recommend evaluating it as a maintained starter template, not a long-term platform commitment.

To engineering: Generates GitHub Actions YAML tailored to Laravel, so new services get tests and builds without copying a wiki page. You commit the generated file and can drop the tool immediately. v1.0.1 is a maintenance release: it adds PHP 8.3 / Laravel 11 / Node 20 options, bumps action pins to current majors (checkout@v4, cache@v4, setup-node@v4, codeql upload-sarif@v3, [email protected], security-checker@v5), and refreshes Larastan usage. No breaking changes — it's additive and version-bump only. Caveats: still zero dependents with limited community validation, so verify templates match our needs (PHP version matrix, caching, DB services) and review generated permissions and secrets before merging. If it doesn't cover our edge cases, a shared template repo remains the lower-risk equivalent — though this update narrows the gap.