Add getting started and contributing guide#81
Conversation
| @@ -0,0 +1,160 @@ | |||
| # Getting Started | |||
|
|
|||
| This guide covers how to build, test, and develop the Bootc Operator. | |||
There was a problem hiding this comment.
Just a thought, as this could be first file for any new comer to open, should we also mention about bootc-operator and to know more about it then re-direct it to that .md file for easy access?
| ## Running Unit Tests | ||
|
|
||
| Unit tests use the controller-runtime | ||
| [envtest](https://book.kubebuilder.io/reference/envtest) framework, which | ||
| provides a local control plane (etcd + API server) without a full cluster. The | ||
| required binaries are downloaded automatically. | ||
|
|
||
| ```shell | ||
| make unit # Run all unit tests | ||
| make unit V=1 # Verbose output | ||
| make unit RUN=Foo # Run tests matching "Foo" | ||
| ``` | ||
|
|
||
| ## Running End-to-End Tests |
There was a problem hiding this comment.
For unit and e2e test should we mention the test files directory?
| ## Building | ||
|
|
||
| ```shell | ||
| make build # Build all binaries (manager + daemon) to ./bin/ | ||
| make buildimg # Build the container image (default: bootc-operator:dev) | ||
| ``` |
There was a problem hiding this comment.
Would it be beneficial to include the systemctl --user start podman.socket command as a step in this process?
|
Hmm, do we need both a GETTING_STARTED and a CONTRIBUTING? |
|
|
||
| This collects the same diagnostics into `_output/logs/gather-bink/`. | ||
|
|
||
| To tear down the cluster when done: |
There was a problem hiding this comment.
Feels weird to have this live in the test logs section. Perhaps in the previous one instead?
| Options: | ||
|
|
||
| ```shell | ||
| make e2e V=1 # Verbose streaming output | ||
| make e2e RUN=Foo # Run tests matching "Foo" | ||
| ``` |
There was a problem hiding this comment.
I would just merge this in the code block above that introduces make e2e, like you did for make unit.
| ## Investigating CI Failures | ||
|
|
||
| CI runs on [GitHub Actions](https://github.com/bootc-dev/bootc-operator/actions) | ||
| and consists of three jobs: `unit`, `build-bink`, and `e2e`. When a run fails, | ||
| you can inspect it using the `gh` CLI. | ||
|
|
||
| View a run summary: | ||
|
|
||
| ```shell | ||
| gh run view <run-id> --repo bootc-dev/bootc-operator | ||
| ``` | ||
|
|
||
| ### Downloading E2E Logs | ||
|
|
||
| The e2e job uploads diagnostic logs as a GitHub Actions artifact named | ||
| `e2e-logs`. These contain the same logs collected by `make gather-bink` | ||
| (operator pod logs, node journals, event dumps, etc.). Download them with: | ||
|
|
||
| ```shell | ||
| gh run download <run-id> --repo bootc-dev/bootc-operator | ||
| ``` | ||
|
|
||
| This creates a local `e2e-logs/` directory with per-test subdirectories | ||
| matching the structure described in [Finding Test Logs](#finding-test-logs). |
There was a problem hiding this comment.
Hmm, unsure whether this belongs here. This seems like more general advice.
Not against it though!
There was a problem hiding this comment.
I would like to keep it. I always find it helpful to know how and where to find the logs, especially for people that open pull requests for the first time.
This includes how to setup a development environment using bink, the building and testing setup, how to interact and debug CI failure and how to submit PRs. Assisted-by: AI Signed-off-by: Alice Frosi <afrosi@redhat.com>
|
I merged the 2 document and addressed the comments. Additionally, I also included an |
4 participants
Add the started and contributing guide for newcomers.
The get starting guide is still missing a good example. I think it will be easier to add one once we merge #75. So we can reference by tag and it gets a bit easier to reference the images
Fixes: #54