konflux --> the integration test

[helio-frota]

Initially, in an attempt to avoid confusion with test names, we have the following:

• The current test coverage in the trustify repository is 68.83% function coverage and 76.14% line coverage according to cargo llvm-cov nextest --html --open command.

Let’s imagine a web application that has a feature to display the local weather, with a front-end accessing a back-end that returns this information. An interesting test to run on konflux would be an end-to-end (e2e) test that accesses the front-end and consequently verifies if the application displays the weather, a functional test. Since the idea is to have a release/deploy later to make sure the application is working.

Assuming trustify-pm-mode and reusing the thought above, a few natural questions arise:

a) Are we concerned about the % of "coverage" of functionalities in a konflux test? If so, what percentage? Based on the number of tests we already have that are running in trustify's CI.
b) Who (which team) is responsible for writing these tests?
c) Is using curl to check if the application is available on localhost:8080 valid? (Answer: Yes) Is that expected? (Answer: I don’t know, it depends on the team’s decision).

If we plan to run trustify-api-mode-only we would need some extra steps to make sure we have postgresql running inside konflux and we don't have the concept of e2e since the front-end is not being used in this mode. And items a) and c) above also applies to this.

[helio-frota]

b) Who (which team) is responsible for writing these tests?

This question is because of the following items:

• Currently we have a simple way to have trustify running in background when the konflux integration test is started and it runs inside the container that was built during the build image phase. So it runs with ubi image.
• We have this repository that uses playwright and according to this it will be complicated or not possible to run inside ubi container.
• A failing test (curl, playwright, cypress, or whatever) means a konflux-failing-integration-test visible on konflux pull requests chore(deps): update konflux references rhtpa#23

[helio-frota]

... it will be complicated or not possible to run inside ubi container.

I found this https://github.com/rust-headless-chrome/rust-headless-chrome?tab=readme-ov-file#headless-chrome

and created a "hello world" and it generates a binary ~13MiB, in which we could download from a different repository (or change rhtpa fork to add that extra binary similar to migration and xtask binaries) and execute e2e tests...but it also depends on / relates to a) and c) . In case we follow this, then in theory we can call that binary after this line https://github.com/trustification/rhtpa/blob/main/test.sh#L12

[jcrossley3]

If we plan to run trustify-api-mode-only we would need some extra steps to make sure we have postgresql running inside konflux and we don't have the concept of e2e since the front-end is not being used in this mode. And items a) and c) above also applies to this.

Just to clarify: "api mode" serves the front-end, too. The only thing PM mode gets you is an embedded database.

[helio-frota]

Just to clarify: "api mode" serves the front-end, too.

Thanks for clarification 👍

The only thing PM mode gets you is an embedded database.

And this means easy configs for us.

[helio-frota]

closing since we are going to use a different approach