Skip to content

Add getting started and contributing guide#81

Open
alicefr wants to merge 2 commits into
bootc-dev:mainfrom
alicefr:contributing
Open

Add getting started and contributing guide#81
alicefr wants to merge 2 commits into
bootc-dev:mainfrom
alicefr:contributing

Conversation

@alicefr

@alicefr alicefr commented Jun 26, 2026

Copy link
Copy Markdown
Collaborator

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

alicefr added 2 commits June 26, 2026 09:20
Cover building, running unit and e2e tests, bink internal registry
usage, and code style checks.

Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Alice Frosi <afrosi@redhat.com>
Cover prerequisites, development environment, code style, DCO sign-off,
commit conventions, and PR process.

Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Signed-off-by: Alice Frosi <afrosi@redhat.com>
Comment thread docs/GETTING_STARTED.md
@@ -0,0 +1,160 @@
# Getting Started

This guide covers how to build, test, and develop the Bootc Operator.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment thread docs/GETTING_STARTED.md
Comment on lines +38 to +51
## 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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For unit and e2e test should we mention the test files directory?

Comment thread docs/GETTING_STARTED.md
Comment on lines +21 to +26
## Building

```shell
make build # Build all binaries (manager + daemon) to ./bin/
make buildimg # Build the container image (default: bootc-operator:dev)
```

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be beneficial to include the systemctl --user start podman.socket command as a step in this process?

@jlebon

jlebon commented Jun 30, 2026

Copy link
Copy Markdown
Collaborator

Hmm, do we need both a GETTING_STARTED and a CONTRIBUTING?

@jlebon jlebon left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for writing this up!

Yeah, I would ideally merge the two docs to avoid some of the duplication and to reduce confusion.

Comment thread docs/GETTING_STARTED.md

This collects the same diagnostics into `_output/logs/gather-bink/`.

To tear down the cluster when done:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels weird to have this live in the test logs section. Perhaps in the previous one instead?

Comment thread docs/GETTING_STARTED.md
Comment on lines +85 to +90
Options:
```shell
make e2e V=1 # Verbose streaming output
make e2e RUN=Foo # Run tests matching "Foo"
```

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would just merge this in the code block above that introduces make e2e, like you did for make unit.

Comment thread docs/GETTING_STARTED.md
Comment on lines +125 to +148
## 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).

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, unsure whether this belongs here. This seems like more general advice.

Not against it though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a CONTRIBUTING.md

4 participants