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

📖 doc: add steps to build and deploy locally to contributing guide #463

Merged
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
23 changes: 23 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,29 @@ details.
- Create a new branch from the default `main` branch and begin development in
the area of your interest.

## How to Build and Deploy Locally

After creating a fork and cloning the project locally,
you can follow the steps below to test your changes:

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
```
Comment on lines +43 to +59
Copy link
Member

@m1kola m1kola Nov 18, 2024

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.

Copy link
Contributor Author

@camilamacedo86 camilamacedo86 Nov 18, 2024

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.

  1. 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.

  2. Improve clarity
    Contributors should quickly understand what each command does. Clear, concise documentation prevents wasted time.

  3. Enhance efficiency
    Running local tests for small contributions should be straightforward, not a time-consuming process.


## Reporting bugs and creating issues

Any new contribution should be linked to a new or existing github issue in the
Expand Down