Skip to content

[ST] Add documentation - quickstart, architecture explanation, running tests, config + OLM catalogsource setup script#2685

Open
jankalinic wants to merge 1 commit into
streamshub:mainfrom
jankalinic:doc-sts
Open

[ST] Add documentation - quickstart, architecture explanation, running tests, config + OLM catalogsource setup script#2685
jankalinic wants to merge 1 commit into
streamshub:mainfrom
jankalinic:doc-sts

Conversation

@jankalinic

Copy link
Copy Markdown
Contributor

Added some docs about STs and some of the important parts that should help anyone get started up.
I also added olm catalog script for the debugging/testing setup to be more convenient.

  • one removed unused ENV var.

If you feel like there is anything missing i'll add it to the docs.

Signed-off-by: jkalinic <jkalinic@redhat.com>
@sonarqubecloud

Copy link
Copy Markdown

@MikeEdgar MikeEdgar left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks good so far, I just want to try out the setup script on a blank/empty minikube today.

@jankalinic

Copy link
Copy Markdown
Contributor Author

I guess if needed we could create setup minikube/kind script to mirror the github workflow, but it might be too much since there are many variables/usecases that we can't determine and the minikube/kind has already enough of quickstart documentation that it might not be worthy.

Also there is the VM networking layer issue on MacOS, i read some blogpost about using moon that might solve this utilizing container browser and websockets, but i'm not confident enough, that it will completely eliminate the Mac-container communication issue - that might require finding some clever workaround which does not directly modify the whole user environment just for running systemtests.

@MikeEdgar

MikeEdgar commented Jun 25, 2026

Copy link
Copy Markdown
Member

Maybe it's overly simplistic, but would it work to have in that script something like

  • if linux, create a minikube like we do in GH action
  • if mac, [do whatever it takes to have a local Kube on mac]

Then maybe the GH action could just run that same script (or components of it if necessary) so the logic is in only one place.

@alexcreasy

Copy link
Copy Markdown
Contributor

+1 to what Mike said, I think that's the ideal solution if we can make it happen, a single script that's run in CI or locally. We just need to get to the bottom of the minikube networking on mac issue and see if it's solvable or we need to take a different route.

Comment on lines +7 to +9
### setup-olm-catalog.sh

Creates an OLM CatalogSource for the Console Operator.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thinking about it again today, why not have the creation of the CatalogSource be handled by the OlmConfigJava class instead of a script? Of course it could still be possible to skip that step if one already exists and the catalog name and namespace is provided to the tests.

| Variable | Default | Description |
|----------|---------|-------------|
| `CONSOLE_OLM_CATALOG_SOURCE_NAME` | `console-source` | Name of the CatalogSource for Console Operator. |
| `CONSOLE_OLM_CATALOG_SOURCE_NAMESPACE` | `openshift-marketplace` | Namespace where CatalogSource is created. |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
| `CONSOLE_OLM_CATALOG_SOURCE_NAMESPACE` | `openshift-marketplace` | Namespace where CatalogSource is created. |
| `CONSOLE_OLM_CATALOG_SOURCE_NAMESPACE` | `olm` | Namespace where CatalogSource is created. |

I think the OLM install scripts use olm, which may be a better default here.

| `CONSOLE_DEPLOYMENT_NAME` | `streamshub-console` | Deployment name of Console instance. |
| `CONSOLE_INSTALL_TYPE` | `olm` | Installation method: `olm` (Operator Lifecycle Manager) or `yaml` (direct manifests). |
| `CLIENT_TYPE` | `kubectl` | Kubernetes CLI client: `kubectl` or `oc` (for OpenShift). |
| `CONSOLE_CLUSTER_DOMAIN` | `192.168.49.2.nip.io` | Cluster domain for ingress routes. Required for non-OpenShift clusters. Update to match your cluster IP. |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
| `CONSOLE_CLUSTER_DOMAIN` | `192.168.49.2.nip.io` | Cluster domain for ingress routes. Required for non-OpenShift clusters. Update to match your cluster IP. |
| `CONSOLE_CLUSTER_DOMAIN` | N/A | Cluster domain for ingress routes. Required for non-OpenShift clusters. Update to match your cluster IP. |

Should we remove the default here? It's always going to be variable and having a default could lead to someone thinking that would automatically work,

| Variable | Default | Description |
|----------|---------|-------------|
| `CONSOLE_API_IMAGE` | _(empty)_ | Custom Console API image. Overrides operator's default API image. |
| `CONSOLE_UI_IMAGE` | _(empty)_ | Custom Console UI image. Overrides operator's default UI image. |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
| `CONSOLE_UI_IMAGE` | _(empty)_ | Custom Console UI image. Overrides operator's default UI image. |

Obsolete

**Example:**
```yaml
CONSOLE_API_IMAGE: quay.io/your-username/console-api:my-feature
CONSOLE_UI_IMAGE: quay.io/your-username/console-ui:my-feature

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
CONSOLE_UI_IMAGE: quay.io/your-username/console-ui:my-feature

Obsolete


```yaml
CONSOLE_API_IMAGE: localhost:5000/console-api:dev
CONSOLE_UI_IMAGE: localhost:5000/console-ui:dev

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
CONSOLE_UI_IMAGE: localhost:5000/console-ui:dev

Obsolete

Comment thread systemtests/README.md

| Software | Minimum Version | Recommended | Installation Guide |
|----------|----------------|-------------|-------------------|
| **Java JDK** | 17 or higher | 21 | [OpenJDK](https://openjdk.org/) |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
| **Java JDK** | 17 or higher | 21 | [OpenJDK](https://openjdk.org/) |
| **Java JDK** | 21 or higher | 21 | [OpenJDK](https://openjdk.org/) |

Comment thread systemtests/README.md
Comment on lines +102 to +118
### Initial Project Build

**CRITICAL:** You must build the entire project before running system tests.

```bash
# From project root
mvn clean install -DskipTests
```

**Why this is required:**

The systemtests module depends on artifacts from other modules:
- [Console API module](../api/)
- [Console UI](../api/src/main/webui/)
- Shared libraries and utilities
- Custom resource definitions (CRDs)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This seems redundant with it also being in the "quick start" section.

Comment thread systemtests/README.md
Once the full project is built, you can rebuild just systemtests:

```bash
mvn -pl systemtests clean verify

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I need to add -DskipSTs=false to the mvn command. Do you usually do that or does that sound incorrect?

| `TEST_CONSOLE_LOG_LEVEL` | `INFO` | Log level for console output. Keeps console clean while files have details. |
| `TEST_LOG_DIR` | `target/logs` | Directory path for test logs, YAML dumps, and diagnostic output. |
| `RUN_HEADLESS` | `true` | Run Playwright tests without visible browser window. Set to `false` to watch UI tests execute. |
| `SCREENSHOTS_DIR_PATH` | `screenshots` | Directory for test failure screenshots. Relative to systemtests directory. |

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Should the screenshots be dropped into target or target/logs by default? Some examples in the TROUBLESHOOTING.md show them placed there and it might be good to make them be removed automatically from mvn clean.

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.

3 participants