This file provides guidance to AI coding agents when working with code in this repository.
This is the Red Hat Best Practices Test Suite for Kubernetes (certsuite) - a comprehensive certification test suite for verifying CNF/Cloud Native Functions deployment best practices on OpenShift/Kubernetes clusters. The test suite validates workloads against Red Hat's best practices across multiple categories including networking, security, lifecycle, operators, and more.
make build # Build the certsuite binary
make build-darwin-arm64 # Build for macOS ARM64make test # Run unit tests with coverage
make coverage-html # Generate and view HTML coverage reportmake lint # Run all linters (golangci-lint, hadolint, shfmt, markdownlint, yamllint, shellcheck, typos)
make markdownlint # Run markdown linter only
make yamllint # Run YAML linter onlymake generate # Run go generate for code generationmake build-catalog-md # Generate test catalog in Markdown (CATALOG.md)
make coverage-qe # Generate QE coverage reportmake build-image-local # Build local container image
make get-db # Download offline certification database
make delete-db # Remove offline database./certsuite run --config-file <path> --output-dir <path>
./certsuite check results # Validate test results
./certsuite claim show failures # Show failed test cases
./certsuite claim compare <file1> <file2> # Compare two claim filesThe CLI is built using Cobra and organized into subcommands:
run: Execute test suites against a clusterclaim: Manage and analyze claim files (show, compare)generate: Generate catalogs, configs, feedback reportscheck: Validate results and image certification statusinfo: Display information about test casesversion: Show version informationupload: Upload results to external systems
autodiscover: Automatically discovers pods, operators, CRDs, and other Kubernetes resources in target namespaces. The DiscoveredTestData structure contains all discovered resources that tests validate against:
- Pods (target, probe, operand)
- Operators (CSVs, install plans, catalog sources)
- Network resources (policies, attachments, SR-IOV)
- Storage (PVs, PVCs)
- RBAC (roles, bindings)
- Custom resources and CRDs
configuration: Test configuration parsing and validation. Reads tnf_config.yaml (or custom config file) to determine:
- Target namespaces to test
- Pod label selectors
- Operator label selectors
- Network attachment definitions to check
- Test-specific parameters
provider: Test execution providers and resource access. The TestEnvironment interface provides access to discovered resources for test implementations.
checksdb: Test case database and results tracking. Each test is registered as a Check with metadata, skip conditions, and execution functions.
compatibility: Version compatibility checks between cluster components and expected versions.
collector: Result collection and submission to external data collectors.
clientsholder: Kubernetes client management and caching. Maintains singleton instances of various k8s clients (core, apps, networking, etc.).
log: Logging infrastructure used throughout the codebase.
cli: CLI framework and utilities for command-line interactions.
results: Results processing and HTML generation for test reports.
Test suites are organized by category:
accesscontrol: Security context, namespace, and privilege testsnetworking: Network policies, ICMP, services, and connectivity testsplatform: OS validation, sysctls, node taints, boot parameterslifecycle: Pod recreation, scaling, owner referencesobservability: Logging, monitoring, pod disruption budgetsoperator: Operator lifecycle, installation, best practicescertification: Container, operator, and helm chart certification checksperformance: Performance-related validationsmanageability: Management and configuration testspreflight: Red Hat preflight certification integration
Each test suite contains:
- Individual test implementations (e.g.,
tests/networking/icmp/icmp.go) - Test utilities and helpers (e.g.,
tests/networking/netcommons/netcommons.go) - Ginkgo test suite setup (
suite_test.go) - A
suite.gofile that registers checks using the checksdb API
Tests use the Ginkgo/Gomega BDD framework. Test execution follows this pattern:
- Autodiscovery Phase: The
autodiscoverpackage scans the cluster and buildsDiscoveredTestData - Check Registration: Each test suite's
LoadChecks()function registers test cases with checksdb - Check Execution: The test runner iterates through registered checks, evaluating skip conditions and executing check functions
- Results Collection: Test results are collected into a "claim file" (JSON format) containing pass/fail/skip status, logs, and configuration snapshots
Tests require a configuration file (default: config/certsuite_config.yml) specifying:
targetNameSpaces:
- name: tnf
podsUnderTestLabels:
- "redhat-best-practices-for-k8s.com/generic: target"
operatorsUnderTestLabels:
- "redhat-best-practices-for-k8s.com/operator:target"
targetCrdFilters:
- nameSuffix: "group1.test.com"
scalable: falseThis repository uses Go 1.26.4. Ensure your local environment matches this version.
The codebase uses native Go structs for mocking interfaces in tests. Mock implementations are hand-written and located alongside the interfaces they mock (e.g., internal/clientsholder/command_mock.go). This approach avoids external dependencies and makes the code easier to understand and maintain.
All code must pass the configured linters before submission. Use make lint to run all linters. The project uses:
golangci-lint(Go code quality)hadolint(Dockerfile linting)shfmt(Shell script formatting)markdownlint(Markdown formatting)yamllint(YAML validation)shellcheck(Shell script analysis)typos(Spelling checker)
- cmd/: Main applications and CLI tools
- pkg/: Public/exported packages that can be imported by other projects
- internal/: Private packages not meant for external use
- tests/: Test suite implementations organized by category
- script/: Build and automation scripts
Version information is managed via scripts:
script/create-version-files.sh: Creates version metadatascript/get-git-release.sh: Gets current Git release tagversion.json: Contains version information for dependencies
Test execution produces a "claim file" (JSON format) containing:
- Test results (pass/fail/skip)
- Configuration snapshots
- Resource inventories
- Logs and failure reasons
The claim format is defined in a separate package (certsuite-claim) and shared across tools.
./certsuite run --config-file=tnf_config.yaml --label-filter=networking./certsuite claim compare claim1.json claim2.jsonmake build
make test
make lint./certsuite check image-cert-status --image <image-reference>