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 Action with code scanning

The LaraBeacon action runs the CI profile, writes a SARIF report, uploads it to GitHub code scanning, and then applies the scan result to the job. Findings appear as annotations in pull requests and in the repository's Security tab.

permissions:
  contents: read
  security-events: write

steps:
  - uses: actions/checkout@v7
  - uses: shivammathur/setup-php@v2
    with:
      php-version: '8.4'
  - run: composer install --no-interaction --prefer-dist
  - run: cp .env.example .env && php artisan key:generate
  - uses: A-Baer/LaraBeacon@v3
    with:
      fail-on: major
      baseline: larabeacon-baseline.json

Inputs: working-directory, profile (default ci), fail-on (default major), baseline, sarif-file, upload-sarif (default true), and args for further options. With a baseline, only new findings fail the job. args is split on whitespace and sarif-file must be relative. Code scanning resolves file paths from the repository root, so annotations are exact when the Laravel application lives at the root. Set upload-sarif: false if code scanning is not available for the repository; private repository support depends on plan and Code Security entitlement.

Manual GitHub Actions step

- 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.