-
Notifications
You must be signed in to change notification settings - Fork 34
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
📖 doc: add steps to build and deploy locally to contributing guide #463
📖 doc: add steps to build and deploy locally to contributing guide #463
Conversation
- Updated the Contributing guide with detailed instructions for building and deploying the project locally. - Steps include creating a local kind cluster, building the container, and loading it into the cluster. This addition helps contributors set up their local environment efficiently.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #463 +/- ##
=======================================
Coverage 38.23% 38.23%
=======================================
Files 15 15
Lines 1224 1224
=======================================
Hits 468 468
Misses 706 706
Partials 50 50 ☔ View full report in Codecov by Sentry. |
1. Create the cluster: | ||
|
||
```sh | ||
kind create cluster -n catalogd | ||
``` | ||
|
||
2. Build your changes: | ||
|
||
```sh | ||
make build-container | ||
``` | ||
|
||
3. Load the image locally and Deploy to Kind | ||
|
||
```sh | ||
make kind-load deploy | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Last week I had to fix similar steps in operator-controller here. And I wondered why we have all this instead of just make run
which does everything mentioned here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @m1kola
Thank you for your input
Regards:
I had to fix similar steps in operator-controller here.
You fixed a typo issue. It was missing the -n
I think we can agree that is not a good argumentation against it.
And I wondered why we have all this instead of just make run which does everything mentioned here.
-
Avoid reliance on bingo's kind
I want to use my own local kind installation, not a version tied to bingo (e.g.,/Users/camilam/go/bin/kind-v0.24.0
). Contributors should have flexibility without unnecessary dependencies. We must start thinking that people have their local envs and want to take advantage of staff. -
Improve clarity
Contributors should quickly understand what each command does. Clear, concise documentation prevents wasted time. -
Enhance efficiency
Running local tests for small contributions should be straightforward, not a time-consuming process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just a question about using multiple steps in docs vs single make run
in both catalogd and operator-controller contributor docs.
and deploying the project locally.
and loading it into the cluster.
This addition helps contributors set up their local environment efficiently.