[Do not merge] Test PR for PR check verification

[sutaakar]

Many thanks for submiting your Pull Request ❤️!

Please make sure that your PR meets the following requirements:

• You have read the contributors' guide
• Pull Request title is properly formatted: [KOGITO-XYZ] Subject
• Pull Request contains link to the JIRA issue
• Pull Request contains description of the issue
• Pull Request does not include fixes for issues other than the main ticket
• Your feature/bug fix has a unit test that verifies it
• You've tested the new feature/bug fix in an actual OpenShift cluster

[sutaakar]

/jenkins test

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

/jenkins test

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

/jenkins test

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

/jenkins test

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

/jenkins test

[sutaakar]

@ricardozanini Right now we are building the Kogito images to be used by ourselves (takes 5-15 minutes, depends on who knows what). I was considering to rather use some pre-built images. Those images would be stored for example in Quay and build for every release (or in case of some significant change in Runtime or example, or maybe built every night?).

[ricardozanini]

@sutaakar I'd say to use the nightly images to run the tests, wdyt?

[sutaakar]

Fine for me

[sutaakar]

@ricardozanini
Current test structure for PR check in this PR:

• deploy_kogito_build.feature - checking remote S2I and binary build for both Quarkus and SpringBoot (native build is skipped for PR check) and also Webhooks
• deploy_kogito_runtime.feature - (using pre-built image) checking that Kogito application is properly deployed (without any integration, with KogitoInfra persistence, with KogitoInfra events, with external persistence, with external events) for both Quarkus and SpringBoot
• deploy_service_resources.feature - checking resource requests and limits
• deploy_source_files.feature - checking remove built with uploaded source file (both Quarkus and SpringBoot) and uploaded source folder (Quarkus only)
• install_dataindex.feature - Data index with KogitoInfra dependencies and with external dependencies
• install_jobs_service.feature - Jobs service without persistence, with persistence, with external persistence and with external events (by connecting to Data index)
• install_kogitoinfra.feature - checks installing Infinispan, Kafka and Keycloak by CLI
• install_mgmtconsole.feature - Management console
• install_trusty.feature - Trusty
• install_trustyui.feature - Trusty UI
• prometheus.feature - Prometheus
• update_httpport.feature - Checking httpPort configuration for various components

I think that in update_httpport we could check httpPort just for example for Kogito Quarkus application and expect the other runtimes/Data index/Jobs service... to behave same.
Some tests contain check for both KogitoInfra provided Infinispan/Kafka and externally provided. Those tests can IMHO stay as they are now and can be removed once we get rid of KogitoInfra provided instances.
For deploy_kogito_runtime.feature, I think that both Quarkus and SpringBoot check could stay there, what do you think?

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

reverted changes for image build as it will be handled on nightly build side

[sutaakar]

/jenkins test

[ricardozanini]

@sutaakar many thanks for your efforts doing this, my opinion inline. Assuming that we are running the full tests in the nightly pipelines:

deploy_kogito_build.feature - checking remote S2I and binary build for both Quarkus and SpringBoot (native build is skipped for PR check) and also Webhooks

We can keep only Quarkus since that's not much to do from the operator side, the build configuration is basically the same thing, but the attribute runtime. Won't worth.

deploy_kogito_runtime.feature - (using pre-built image) checking that Kogito application is properly deployed (without any integration, with KogitoInfra persistence, with KogitoInfra events, with external persistence, with external events) for both Quarkus and SpringBoot

This is just a simple KogitoRuntime deployment with a pre existent image? If so, we can keep both runtimes.

deploy_service_resources.feature - checking resource requests and limits

We can leave this to the nightly builds or just check for SpringBoot or Quarkus and remove the other one from the deploy_kogito_runtime.feature. This way we have SpringBoot there and Quarkus here, or vice-versa.

deploy_source_files.feature - checking remote built with uploaded source file (both Quarkus and SpringBoot) and uploaded source folder (Quarkus only)

We can keep the remote built with SpringBoot and folder with Quarkus.

install_dataindex.feature - Data index with KogitoInfra dependencies and with external dependencies

Fine!

install_jobs_service.feature - Jobs service without persistence, with persistence, with external persistence and with external events (by connecting to Data index)

I would only test the Jobs Service with persistence and events connected to Data Index. Removing the external one.

install_kogitoinfra.feature - checks installing Infinispan, Kafka and Keycloak by CLI

We can remove this one.

install_mgmtconsole.feature - Management console

We can remove this one. From the operator perspective is like a Data Index or Jobs Service. It's an integration test with Kogito apps that can run only during the night.

install_trusty.feature - Trusty
install_trustyui.feature - Trusty UI

Remove both, since it's the same scenario of the Management Console.

prometheus.feature - Prometheus

Absolutely, we can keep.

update_httpport.feature - Checking httpPort configuration for various components

Absolutely!

I would focus only on possible deployment scenarios for the Operator point of view, not scenarios that are meant to be an integration like verifying if Jobs Service is sending messages or if the authentication is working, since we can be affected by bugs in their side, impacting our flow. We should not be the bottleneck IMHO.

[ricardozanini]

/jenkins test

[msmagnanijr]

/jenkins test

[ricardozanini]

@sutaakar do you mind rebasing? The CI is failing because of this conflict.

[sutaakar]

I plan to open a new PR, will use a different approach

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

/jenkins test

[kie-ci-bot]

Change detected in the PR, requesting reviews and running pipeline(if required) again

[sutaakar]

/jenkins test

[sutaakar]

Replaced by #587