Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
130 lines (95 loc) · 4 KB

CONTRIBUTING.md

File metadata and controls

130 lines (95 loc) · 4 KB
Raw

Contributing to VulnerabilityHub

Thank you for helping improve VulnerabilityHub.

VulnerabilityHub is currently pre-alpha software. Until v1.0.0, interfaces, configuration, data models, and deployment behavior may change without a deprecation period. Contributions should therefore favor clear migrations and release notes whenever they change operator-visible behavior.

Before You Start

  • Search existing issues and pull requests before opening a new one.
  • Use the issue forms for bugs, feature proposals, and support questions.
  • For a substantial change, open an issue first so the approach and scope can be agreed before implementation begins.
  • Do not report vulnerabilities in public issues. Follow SECURITY.md instead.

Branches

  • Open normal pull requests against dev.
  • main is the release branch and should only receive reviewed release promotions or urgent hotfixes.
  • Keep each pull request focused on one logical change.

Dependabot targets dev for dependency updates. Verified minor and patch updates are automatically approved and set to auto-merge using squash merges only after both CI Pipeline and E2E Tests succeed for the PR's exact head commit. Missing, pending, failed, cancelled, or skipped pipelines cannot authorize a merge. Branch protection rules still apply. Major updates (including Vue and Vuetify) and updates without a recognized version change remain open for manual review.

For this automation, enable Allow auto-merge and squash merging in the repository settings, and Allow GitHub Actions to create and approve pull requests under Actions → General → Workflow permissions. The explicit pipeline gate applies even without required-check rules on dev; configuring those rules also protects manual merges. The workflow does not bypass branch protection or organization policies.

Create a branch from the latest dev branch:

git fetch origin
git switch dev
git pull --ff-only
git switch -c feature/short-description

Common prefixes such as feature/, fix/, docs/, and chore/ are recommended but not required.

Development Setup

The README and development guide describe the complete local setup.

At minimum, install the backend and frontend dependencies before running their respective checks:

python -m pip install -r src/backend/requirements.txt
python -m pip install -r src/backend/requirements-test.txt
npm --prefix src/frontend/app ci

Checks

Run the checks that apply to your change before opening a pull request.

Backend unit tests:

python -m pytest src/backend/tests

Backend database integration tests:

scripts/e2e/run-backend.sh

Frontend tests and build:

npm --prefix src/frontend/app test -- --run
npm --prefix src/frontend/app run build

End-to-end tests:

npm --prefix src/frontend/app run test:e2e:local

Documentation build:

python -m pip install -r docs/requirements.txt
sphinx-build docs docs/output

Pull Requests

Every pull request should:

  • Explain the problem and the chosen solution.
  • Link related issues.
  • Describe how the change was tested.
  • Update user or operator documentation when behavior changes.
  • Call out breaking changes, migrations, security impact, and release-note requirements explicitly.
  • Pass all required GitHub Actions checks.

Maintainers may ask for a change to be split when unrelated concerns are mixed in one pull request.

Commit and Review Expectations

  • Write concise, descriptive commit messages.
  • Do not commit credentials, secrets, production data, or vulnerability details.
  • Address review comments with additional commits; maintainers will choose the final merge strategy.
  • Be respectful and follow the Code of Conduct.

Licensing

By contributing, you agree that your contribution is provided under the European Union Public Licence 1.2, the license used by this project.