Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
96 lines (67 loc) · 3.66 KB

CONTRIBUTING.md

File metadata and controls

96 lines (67 loc) · 3.66 KB

Contributing to wardex

Thank you for your interest in contributing! This document outlines the process for contributing to this project.

Code of Conduct

Please read and follow our Code of Conduct.

How to Contribute

⚠️ Contributor Licence Agreement (CLA)

Wardex operates under a dual-licensing model (AGPL-3.0 and Commercial). To protect the project's IP and enable commercial sublicensing, all contributors must sign a Contributor Licence Agreement (CLA).

You do not need to sign the CLA to use Wardex, only to contribute code.

When you open your first Pull Request, the @cla-assistant bot will comment with a link to sign the CLA. You only need to sign this once. PRs cannot be merged until the author has signed the CLA.

Reporting Bugs

  • Search existing issues before opening a new one.
  • Include a minimal reproducible example.
  • Describe the expected vs. actual behaviour.

Gitflow Strategy (main + dev)

Wardex strictly uses a Simplified Gitflow model (main + dev branches) to maintain project hygiene, historically granulated commits, and high security standards. We do not use long-lived test or audit branches.

Branch Architecture

  1. main (Production / Audit Trail)

    • Always pristine, deployable, and cryptographically sound.
    • Contains only tagged production releases (e.g., v1.7.0).
    • Direct commits are prohibited. All code arrives via Pull Requests from dev.
    • Used as the ultimate source of truth for SOC2/ISO 27001 auditors.

  2. dev (Integration / Pre-Release)

    • The primary working branch.
    • All feature branches branch off dev and merge back into dev.
    • Once dev reaches a stable milestone, a Release PR is opened from dev into main.

  3. Feature Branches (feat/*, fix/*, docs/*, chore/*)

    • Short-lived, ephemeral branches branched off dev.
    • Deleted immediately after being squashed/merged into dev.

Submission Pipeline (Project Hygiene)

  1. Branch off dev: git checkout -b feat/my-feature dev
  2. Commit your changes using Conventional Commits (e.g., feat: implement epss enrichment).
  3. Run local security and hygiene checks:
    • golangci-lint run ./...
    • gosec ./...
    • go test -race ./...
  4. Push your branch and open a Pull Request targeting the dev branch (NOT main).
  5. GitHub Actions CI will re-run all linting, static analysis, and unit tests. The PR cannot be merged if any check fails or coverage drops.
  6. Once merged, the feature branch must be deleted.

Commit Style (Conventional Commits)

Prefix When to use
feat: New feature
fix: Bug fix
docs: Documentation only
refactor: Code change that neither fixes nor adds
test: Adding or fixing tests
chore: Maintenance, dependency updates, build tasks
ci: CI/CD changes

Example: feat: add support for YAML config replay

Testing Requirements

  • All new code must include unit tests.
  • Run make test before submitting.
  • Coverage must not regress.
  • Tests must pass with -race flag.

Code Review

  • All PRs require at least one review.
  • Address all comments before merging.
  • Keep PRs focused — one feature/fix per PR.

Development Setup

git clone https://github.com/had-nu/wardex.git
cd wardex
go mod download
make test

Thank you for contributing to wardex!