Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
82 lines (63 loc) · 2.98 KB

CONTRIBUTING.md

File metadata and controls

82 lines (63 loc) · 2.98 KB

Contributing to SeatLock

We follow strict engineering practices to ensure maintainability and clarity.

1. Git Commit Strategy

We strictly adhere to Conventional Commits specification.

Format

<type>(<scope>): <description>

[optional body]

Allowed Types

  • feat: A new feature (correlates with MINOR in SemVer).
  • fix: A bug fix (correlates with PATCH in SemVer).
  • docs: Documentation only changes.
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
  • refactor: A code change that neither fixes a bug nor adds a feature.
  • perf: A code change that improves performance.
  • test: Adding missing tests or correcting existing tests.
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation.

Examples

  • feat(auth): add pessimistic locking to reservation flow
  • fix(db): resolve deadlock issue in seat allocation
  • docs(adr): add decision record for outbox pattern

Strictness & Clarifications

  • CI Enforcement: The CI pipeline uses commitlint. If a commit message does not follow Conventional Commits (e.g. starts with Update... instead of feat: ...), the build WILL FAIL.
  • Chore vs Style:
    • Use chore: For configuration changes (Docker, Makefile, Composer, .gitignore) that do not touch PHP code.
    • Use style: For code formatting (PHP-CS-Fixer, Pint) or whitespace changes.
    • Use docs: For any change to .md files or PHPDoc.

2. Branching Strategy

  • main: Production-ready code.
  • develop (or dev): Integration branch.
  • feature/feature-name: For new features.
  • fix/bug-name: For bug fixes.

3. Git Workflow (GitHub Flow + Release)

  • All work on feature/* or fix/* branches.
  • PR required → minimum 1 approval from senior.
  • PR template required (includes checklist for tests, phpstan, DCO).
  • After merge to main → GitHub Action auto-tags with SemVer (vX.Y.Z).
  • Weekly release/vX.Y branch for hotfixes.

4. CI/CD Pipeline

  • Managed with GitHub Actions (see .github/workflows/ci.yml).
  • Main stages: test (pest + coverage >= 95%), phpstan level 8, pint, commitlint, trivy container scan, build docker image.
  • Every PR must pass CI.

5. Quality Checks (Pre-Commit)

Before pushing, ensure:

  1. Tests pass: make test
  2. Static Analysis passes: make analyse
  3. Code Style is fixed: make lint

6. Release Workflow

  1. All PRs merged to main → GitHub Actions creates tag vX.Y.Z (conventional commits)
  2. Run npm run changelog → generates CHANGELOG.md
  3. Create GitHub Release with changelog
  4. ArgoCD picks up new tag automatically (staging)
  5. Promote to production via ArgoCD sync or manual button

7. Versioning Rules

  • feat → MINOR
  • fix → PATCH
  • Breaking change → MAJOR + ADR + migration guide

8. Testing Requirements per PR

  • Unit: 100% Domain, 95% overall
  • PHPStan level 8: 0 errors
  • Pint: 0 issues
  • Load test (k6) must pass on main every night