Story
As a Galasa maintainer, I want to exercise the Helm install of a Galasa service more frequently before changes are delivered into main, so that I can identify issues sooner.
Background
At the moment, changes to the Galasa service (e.g. API server, engine controller, extensions, etc.) are only covered by unit tests in PRs. These changes are only exercised in our galasa-service-main and prod1 services after changes are delivered into main.
This means we rely on contributors to have tried the changes out locally (e.g. in minikube) before delivering PRs. It would be good if we had a PR check that installed a Galasa service within a GitHub Actions workflow using something like minikube or kind, and then ran tests on that service to make sure everything works as expected.
We could start by running the built-in helm test command which submits a CoreManagerIVT test run.
Tasks
Story
As a Galasa maintainer, I want to exercise the Helm install of a Galasa service more frequently before changes are delivered into main, so that I can identify issues sooner.
Background
At the moment, changes to the Galasa service (e.g. API server, engine controller, extensions, etc.) are only covered by unit tests in PRs. These changes are only exercised in our galasa-service-main and prod1 services after changes are delivered into main.
This means we rely on contributors to have tried the changes out locally (e.g. in minikube) before delivering PRs. It would be good if we had a PR check that installed a Galasa service within a GitHub Actions workflow using something like minikube or kind, and then ran tests on that service to make sure everything works as expected.
We could start by running the built-in
helm testcommand which submits a CoreManagerIVT test run.Tasks
helm testcommand