LaraBeacon

Workflows

Continuous integration

CI mode runs the checks designed to be deterministic in an isolated pipeline and returns a non-zero exit status when reportable findings fail.

Basic release gate

php artisan larabeacon --ci --details

Run the command after dependencies and application configuration are available. Keep it next to tests, static analysis, and the production asset build.

GitHub Actions example

- name: Run LaraBeacon
  env:
    APP_ENV: testing
    APP_KEY: base64:your-ci-key
  run: php artisan larabeacon --ci --details
Do not commit real secrets

Use the secret store of your CI provider for credentials. The example key is a placeholder and must not be reused.

Runtime stage

HTTP headers, production caches, queue workers, Redis, filesystem capacity, Telescope evidence, and similar signals need a representative environment. Run them against a release candidate before the final traffic switch, not against a synthetic CI container that cannot satisfy their assumptions.

Gate new findings

Finding-level JSON baselines and structured reports require LaraBeacon Core 3.1.0 or newer.

php artisan larabeacon:baseline --profile=ci \
  --output=larabeacon-baseline.json \
  --reason="Scheduled remediation" --expires=2026-12-31
php artisan larabeacon --profile=ci \
  --baseline=larabeacon-baseline.json --only-new --fail-on=major \
  --format=sarif --output=larabeacon.sarif

Review and commit each acceptance with its reason and optional expiry. Known findings stay in the report. Expired entries block again, and reportable execution errors always block. Loading a baseline without --only-new keeps the normal gate. Invalid options or baseline data return exit code 2.

Regenerating a JSON baseline preserves existing reasons and expiry dates. It removes resolved entries only for checks that completed, retaining entries for skipped or excluded checks. Review the baseline diff; do not regenerate it automatically in CI.

Upload the SARIF file as a CI artifact with an always() condition so failed gates retain their report. GitHub Code Scanning can consume it when enabled for the repository; private repository availability depends on plan and Code Security entitlement.

Baseline policy

  • Review every new finding before adding it to a baseline.
  • Keep baseline changes in the same pull request as the responsible code or architecture decision.
  • Prefer narrow analyzer exclusions over disabling an entire category.
  • Regenerate the baseline periodically so deleted code does not leave stale entries behind.