Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HOSTEDCP-2206: Improve Unit Test Runtime #5257

Merged
merged 3 commits into from
Dec 10, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .pre-commit-config.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ repos:
- id: trailing-whitespace
args:
- --markdown-linebreak-ext=md
exclude: docs/content/reference/api.md
- repo: local
hooks:
- id: make-codespell
Expand Down
17 changes: 11 additions & 6 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -118,19 +118,19 @@ hypershift-api: $(CONTROLLER_GEN) $(CODE_GEN)
rm -rf cmd/install/assets/hypershift-operator/*

$(CONTROLLER_GEN) object:headerFile="hack/boilerplate.go.txt" paths="./api/..."

# These consolidate with the 3 steps used to generate CRDs by openshift/api.
$(CODE_GEN) empty-partial-schemas --base-dir ./api/hypershift/v1beta1
$(CODE_GEN) schemapatch --base-dir ./api/hypershift/v1beta1
$(CODE_GEN) crd-manifest-merge --manifest-merge:payload-manifest-path ./api/hypershift/v1beta1/featuregates --base-dir ./api/hypershift/v1beta1

# Move final CRDs to the install folder.
mv ./api/hypershift/v1beta1/zz_generated.crd-manifests cmd/install/assets/hypershift-operator/

# Generate additional CRDs.
$(CONTROLLER_GEN) $(CRD_OPTIONS) paths="./api/scheduling/..." output:crd:artifacts:config=cmd/install/assets/hypershift-operator
$(CONTROLLER_GEN) $(CRD_OPTIONS) paths="./api/certificates/..." output:crd:artifacts:config=cmd/install/assets/hypershift-operator

# TODO: Create a feature gate and install controlplanecomponents in TechPreviewNoUpgrde featureSet.
# TODO: remove when we complete the switch to the new CPO approach.
mv ./cmd/install/assets/hypershift-operator/zz_generated.crd-manifests/controlplanecomponents-CustomNoUpgrade.crd.yaml support/controlplane-component/crds/hypershift.openshift.io_controlplanecomponents.yaml
Expand All @@ -148,7 +148,7 @@ cluster-api-provider-aws: $(CONTROLLER_GEN)
$(CONTROLLER_GEN) $(CRD_OPTIONS) paths="./vendor/sigs.k8s.io/cluster-api-provider-aws/v2/api/..." output:crd:artifacts:config=cmd/install/assets/cluster-api-provider-aws
$(CONTROLLER_GEN) $(CRD_OPTIONS) paths="./vendor/sigs.k8s.io/cluster-api-provider-aws/v2/exp/api/..." output:crd:artifacts:config=cmd/install/assets/cluster-api-provider-aws
$(CONTROLLER_GEN) $(CRD_OPTIONS) paths="./vendor/sigs.k8s.io/cluster-api/exp/addons/api/..." output:crd:artifacts:config=cmd/install/assets/cluster-api
# remove ROSA CRDs
# remove ROSA CRDs
rm -rf cmd/install/assets/cluster-api-provider-aws/infrastructure.cluster.x-k8s.io_rosa*.yaml
# remove EKS CRDs
rm -rf cmd/install/assets/cluster-api-provider-aws/infrastructure.cluster.x-k8s.io_awsmanaged*.yaml
Expand Down Expand Up @@ -200,8 +200,13 @@ delegating_client:

# Run tests
.PHONY: test

# Determine the number of CPU cores
NUM_CORES := $(shell uname | grep -q 'Darwin' && sysctl -n hw.ncpu || nproc)

test:
$(GO) test -race -count=25 -timeout=30m ./... -coverprofile cover.out
echo "Running tests with $(NUM_CORES) parallel jobs..."
$(GO) test -race -parallel=$(NUM_CORES) -count=1 -timeout=30m ./... -coverprofile cover.out

.PHONY: e2e
e2e:
Expand Down
14 changes: 7 additions & 7 deletions docs/content/contribute/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,21 +8,21 @@ Thanks for your interest in contributing to HyperShift. Here are some guidelines
## Prior to Submitting a Pull Request
1. Prior to committing your code
1. Install `precommit`. The HyperShift repo is set up to run `codespell` on your commits through `precommit`. Instructions for installing `precommit` can be found [here](https://pre-commit.com/#install).
2. Run `make pre-commit`. This updates all Golang and API dependencies, builds the source code, builds the e2e tests, verifies source code format, and runs all unit tests. This will help catch issues before committing so that the verify and unit test CI jobs will not fail on your PR.
2. Before submitting your pull request on GitHub, look at your changes and try to view them from the eyes of a reviewer.
2. Run `make pre-commit`. This updates all Golang and API dependencies, builds the source code, builds the e2e tests, verifies source code format, and runs all unit tests. This will help catch issues before committing so that the verify and unit test CI jobs will not fail on your PR.
2. Before submitting your pull request on GitHub, look at your changes and try to view them from the eyes of a reviewer.
1. Try to find the aspects that might not immediately make sense for someone else and explain them in the pull request description.
3. Keep commits/changes scoped to one thing and as minimal as possible.
3. Keep commits/changes scoped to one thing and as minimal as possible.
1. Always keep refactorings (how we do something) separate from logic changes (what we do).
2. If you find additional things along the way that you feel should be improved, do that in a separate pull request.
2. If you find additional things along the way that you feel should be improved, do that in a separate pull request.
3. This helps ensure that you will get a timely review of your change, as a series of small pull requests is a lot easier to review than one big pull request that changes 10 independent things for independent reasons.
4. Use the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) in the subject line for every commit, e.g. `Mark infraID as required` instead of `This patch marks infraID as required`.
1. This follows Git’s own built-in conventions; see [github.com/openshift/hypershift/pull/485](https://github.com/openshift/hypershift/pull/485) as an example.
5. Make sure the "Why" and "How" are included in the message of each commit.

## Creating a Pull Request
1. For small changes, you can just do the change and submit a pull request with it.
2. For bigger changes (more than 200 lines of code diff), do not just do the change but, ask for feedback on the idea and direction of the change first (Either in a GitHub issue or the #project-hypershift channel in the External Red Hat Slack).
1. This avoids situations where big changes are submitted that are then declined or never reviewed, which is frustrating for everyone.
1. For small changes, you can just do the change and submit a pull request with it.
2. For bigger changes (more than 200 lines of code diff), do not just do the change but, ask for feedback on the idea and direction of the change first (Either in a GitHub issue or the #project-hypershift channel in the External Red Hat Slack).
1. This avoids situations where big changes are submitted that are then declined or never reviewed, which is frustrating for everyone.
3. Regardless of the size of the change, always explain how the change will improve the project.
4. Every PR title must be prefixed with the Jira ticket that is addressing e.g. [https://github.com/openshift/hypershift/pull/2233](https://github.com/openshift/hypershift/pull/2233).
5. This repository is the base code for the Hypershift Operator and the Control Plane Operator (belongs to the OCP payload) so they might have different release cadence.
6 changes: 3 additions & 3 deletions docs/content/contribute/release-process.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ We need to add the latest supported version in the `hypershift` repository. We n

- `support/supportedversion/version.go` which contains the variable called `LatestSupportedVersion`. This one contains, as you can imagine, the Latest supported version. We need to put the new version here.
- `support/supportedversion/version_test.go` contains the tests for the to validate the Latest version. It should comply with the established contract to support 2 versions prior to the Latest.

[Example Supported Version Bump PR](https://github.com/openshift/hypershift/pull/5146/files)

We also need to bump the base images in our Dockerfiles.
Expand All @@ -63,12 +63,12 @@ We also need to bump the base images in our Dockerfiles.

### [Openshift/Release](https://github.com/openshift/release) Repository

The Step registry config should be updated by Test Platform. However, the Test Platform is not aware of custom configurations of the different version for specifc hypershift tests.
The Step registry config should be updated by Test Platform. However, the Test Platform is not aware of custom configurations of the different version for specific hypershift tests.
So, we need to check over the Step registry config and make sure that the hypershift tests are correctly configured. Below is an example of the necessary changes to the Step registry config after test platform bumps:

[Example Release Repo PR](https://github.com/openshift/release/pull/59120/files)

### Notes
If test platform are testing new OCP releases before the release is cut the hypershift test will fail and block payloads until:
- There are at least two accepted nightly payloads for the new release.
- The supported versions in the HyperShift repository are updated.
- The supported versions in the HyperShift repository are updated.
Loading