test(ui): add ui tests with local-deploy

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.

[davdhacs]

• local-deploy (no secrets, no auth)
• ui e2e tests (cypress)
• run ^ in github actions (ci)

Originally written by claude(claude-sonnet-4-5@20250929): #1722
Refactored (hacked to pieces because it changed too much) by @davdhacs

[rhacs-bot]

A single node development cluster (infra-pr-1735) was allocated in production infra for this PR.

CI will attempt to deploy quay.io/rhacs-eng/infra-server: to it.

🔌 You can connect to this cluster with:

gcloud container clusters get-credentials infra-pr-1735 --zone us-central1-a --project acs-team-temp-dev

🛠️ And pull infractl from the deployed dev infra-server with:

nohup kubectl -n infra port-forward svc/infra-server-service 8443:8443 &
make pull-infractl-from-dev-server

🚲 You can then use the dev infra instance e.g.:

bin/infractl -k -e localhost:8443 whoami

⚠️Any clusters that you start using your dev infra instance should have a lifespan shorter then the development cluster instance. Otherwise they will not be destroyed when the dev infra instance ceases to exist when the development cluster is deleted.⚠️

Further Development

☕ If you make changes, you can commit and push and CI will take care of updating the development cluster.

🚀 If you only modify configuration (chart/infra-server/configuration) or templates (chart/infra-server/{static,templates}), you can get a faster update with:

make helm-deploy

Logs

Logs for the development infra depending on your @redhat.com authuser:

• authuser=0
• authuser=1
• authuser=2

Or:

kubectl -n infra logs -l app=infra-server --tail=1 -f

[tommartensen]

There should be a notice to run these commands from the repository root (not just in the second item in the list).

[tommartensen]

The top-level README should mention that docker is required for this.

[tommartensen]

helm is required for this command.
This also doesn't work with remote clusters (as the image is not available). A local cluster that has access to the local image registry is required or the image must be pushed.

[tommartensen]

Unfortunately, I also don't see an easy way to overwrite the version (result of make tag). I had to hardcode 0.13.55 as the result of make tag to continue (as I didn't want to deploy a container registry bridge between podman and Kind)

[tommartensen]

Next issue: No pull secrets for the quay.io image.

[tommartensen]

While running these steps, I asked myself why you didn't chose to run the infra-server locally as a binary, connected to a remote argo-workflows server, like we do with the existing e2e tests?

[davdhacs]

good question. I wanted to make it run without any external connections or dependencies, and with no auth or secrets. I thought this on-local deploy would make it simpler for anyone and CI to test/dev.
However, maybe it is too complicated especially with the podman/docker kind/colima registry differences, and needing to pull from quay anyway.