This file provides guidance when working with code in this repository.
HyperShift is a middleware for hosting OpenShift control planes at scale. It provides cost-effective and time-efficient cluster provisioning with portability across clouds while maintaining strong separation between management and workloads.
- hypershift-operator: Main operator managing HostedCluster and NodePool resources
- control-plane-operator: Manages control plane components for hosted clusters
- control-plane-pki-operator: Handles PKI and certificate management
- karpenter-operator: Manages Karpenter resources for auto-scaling
- ignition-server: Serves ignition configs for node bootstrapping
api/: API definitions and CRDs for hypershift, scheduling, certificates, and karpentercmd/: CLI commands for cluster/nodepool management and infrastructure operationshypershift-operator/: Main operator controllers and logiccontrol-plane-operator/: Control plane component managementsupport/: Shared utilities and librariestest/: E2E and integration tests
The codebase supports multiple platforms:
- AWS (primary platform) - both self-managed and managed control plane (aka ROSA HCP)
- Azure - only managed control plane (aka ARO HCP)
- IBM Cloud (PowerVS)
- KubeVirt
- OpenStack
- Agent
make build # Build all binaries
make hypershift-operator # Build hypershift-operator
make control-plane-operator # Build control-plane-operator
make hypershift # Build CLImake test # Run unit tests with race detection
make e2e # Build E2E test binaries
make tests # Compile all testsmake lint # Run golangci-lint
make lint-fix # Auto-fix linting issues
make verify # Full verification (generate, fmt, vet, lint, etc.)
make staticcheck # Run staticcheck on core packages
make fmt # Format code
make vet # Run go vetmake api # Regenerate all API resources and CRDs
make generate # Run go generate
make clients # Update generated clients
make update # Full update (api-deps, workspace-sync, deps, api, api-docs, clients)make hypershift-install-aws-dev # Install HyperShift for AWS development
make run-operator-locally-aws-dev # Run operator locally for AWS development
bin/hypershift install --development # Install in development mode
bin/hypershift-operator run # Run operator locally- Located throughout the codebase alongside source files
- Use race detection and parallel execution
- Run with
make test
- Located in
test/e2e/ - Platform-specific tests for cluster lifecycle
- Nodepool management and upgrade scenarios
- Karpenter integration tests
- Located in
test/integration/ - Focus on controller behavior and API interactions
Please see /hypershift/.cursor/rules/code-formatting.mdc
- Follow standard controller-runtime patterns
- Controllers in
hypershift-operator/controllers/andcontrol-plane-operator/controllers/ - Use reconcile loops with proper error handling and requeuing
- Platform-specific logic isolated in separate packages
- Common interfaces defined in
support/packages - Platform implementations in respective controller subdirectories
- Use
support/upsert/for safe resource creation/updates - Follow owner reference patterns for proper garbage collection
- Leverage controller-runtime's structured logging
- APIs primarily in v1beta1
- Use feature gates for experimental functionality
- CRD generation via controller-gen with OpenShift-specific tooling
This is a Go 1.24+ project using:
- Kubernetes 0.32.x APIs
- Controller-runtime 0.20.x
- Various cloud provider SDKs (AWS, Azure, IBM)
- OpenShift API dependencies
The project uses vendoring (go mod vendor) and includes workspace configuration in hack/workspace/.
- Always run
make apiafter modifying types in theapi/package - Use
make verifybefore submitting PRs to catch formatting/generation issues - Platform-specific controllers require their respective cloud credentials for testing
- E2E tests need proper cloud infrastructure setup (S3 buckets, DNS zones, etc.)
Please see /hypershift/.cursor/rules/git-commit-format.mdc for information on how commit messages should be generated or formatted in this project.
- The project uses gitlint to enforce commit message format
- gitlint can be run by using this command
make run-gitlint - Ensure all commit messages pass gitlint validation
- Common gitlint rules to follow:
- Conventional commit format
- Proper line length limits
- Required footers
- No trailing whitespace