Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
83 lines (54 loc) · 3.59 KB

CONTRIBUTING.md

File metadata and controls

83 lines (54 loc) · 3.59 KB
Raw

Contributing

This repository follows the standard Crossplane contribution model, with a small amount of project-specific guidance below.

Code Of Conduct And DCO

Please follow the Crossplane Code of Conduct and sign your commits with the Developer Certificate of Origin.

Signed-off-by: John Doe <john.doe@example.org>

Use git commit -s to add the sign-off automatically.

Getting Started

  1. Fork the repository and create a branch for your work.
  2. Clone the repository locally.
  3. Run make submodules once so the shared build submodule is initialized.

Working In This Repository

Keep changes focused and prefer small, reviewable commits. When adding or changing provider resources, make sure the corresponding controller, API registration, and tests are updated together.

Makefile Overview

The most commonly used commands are:

  • make submodules: initialize or refresh the shared build submodule.
  • make generate: run code generation.
  • make lint: run linters.
  • make test: run unit tests.
  • make reviewable: run generation, linting, and tests.
  • make build: build the provider artifacts.
  • make dev: start a local kind-based development loop.
  • make dev-clean: delete the local development kind cluster.

Adding A New Type

Use the helper target to scaffold a new resource type:

export provider_name=SonarQube
export group=instance
export type=QualityGate
make provider.addtype provider=${provider_name} group=${group} kind=${type}

After scaffolding, register the new type in internal/controller/register.go, then run make reviewable.

Local Validation

Before opening a pull request, run make reviewable. If your change affects behavior, also run the most relevant focused tests for the area you changed.

E2E Testing Flow

The integration flow is driven by make test-integration or make e2e.run. It creates a kind cluster, installs Crossplane and the provider, then bootstraps an in-cluster SonarQube instance via cluster/local/sonarqube_setup.sh (Deployment + Service in the default namespace, plus a Secret and a ClusterProviderConfig named e2e wired to it). Provider pods reach SonarQube at http://sonarqube.default.svc.cluster.local:9000/api.

While the integration script is running you can inspect the in-cluster instance with:

kubectl logs deployment/sonarqube
kubectl port-forward svc/sonarqube 9000:9000   # then browse http://localhost:9000

The setup script is idempotent and can be re-run against a live cluster. Cluster teardown (driven by the script's exit trap) destroys the SonarQube Pod along with everything else.

For ad-hoc local exploration outside KIND, the standalone make sonarqube.start / make sonarqube.stop targets bring up SonarQube directly on the host via Docker or Podman.

For controller development, make dev starts a local kind cluster and runs the provider against it. Use make dev-clean to remove that cluster when you are done.

make e2e.run also runs in CI on every pull request (e2e-tests job in .github/workflows/ci.yml). PRs that change the provider runtime, the integration script, or anything under internal/test/e2e/ should be exercised locally with make e2e.run before pushing - the CI run is ~15 minutes on a warm cache and the local cycle is faster to iterate on.

CI

The CI workflow runs these high-level checks on every pull request:

  • linting
  • a diff check to keep generated artifacts in sync
  • unit tests with coverage publication
  • the e2e suite via make e2e.run (logs from a failing run are uploaded as the e2e-logs artifact)
  • artifact publishing for tagged and branch builds