Code Formatting
Code Quality, Formatting and Conventions
Code Formatting and Linting
- Use
make lint-fixafter writing Go code to automatically fix most linting issues - Run
make verifyto verify both linting and tests pass before committing - For markdown files, use
make verify-codespellto catch spelling errors
Test Conventions - MANDATORY
NON-NEGOTIABLE RULE: Every Go test name MUST follow this exact format:
name: "When <condition>, it should <expected behavior>"
Examples:
name: "When NodePool has valid image ID, it should create Azure machine template"
name: "When subnet ID is invalid, it should return error"
More from openshift/hypershift
effective go
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.
307debug cluster
Provides systematic debugging approaches for HyperShift hosted-cluster issues. Auto-applies when debugging cluster problems, investigating stuck deletions, or troubleshooting control plane issues.
64git commit format
Apply HyperShift conventional commit formatting rules. Use when generating commit messages or creating commits.
62konflux archived pipelineruns
Accesses archived Konflux PipelineRuns, TaskRuns, and pod logs via KubeArchive. Auto-applies when checking Konflux PipelineRun results, investigating enterprise contract failures, or retrieving logs from completed Konflux CI runs.
7