Skip to content

NETOBSERV-2387: Backend tests migration#2586

Draft
oliver-smakal wants to merge 27 commits intonetobserv:mainfrom
oliver-smakal:backend-tests-migration/NETOBSERV-2387
Draft

NETOBSERV-2387: Backend tests migration#2586
oliver-smakal wants to merge 27 commits intonetobserv:mainfrom
oliver-smakal:backend-tests-migration/NETOBSERV-2387

Conversation

@oliver-smakal
Copy link
Copy Markdown

@oliver-smakal oliver-smakal commented Mar 24, 2026

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes and add guards to skip some of the testcases for certain openshift versions. Then I would put this PR from Draft status.

How to run locally

Either:

go run github.com/onsi/ginkgo/v2/ginkgo #to run all
go run github.com/onsi/ginkgo/v2/ginkgo --focus="VM" #use regex to filter

or if the ginkgo cli is installed:

ginkgo #to run all
ginkgo --focus="VM" #use regex to filter

Other standard flags of ginkgo such as --dry-run or -v also work.

Example output

The following is an example output of of a run:

[1776324075] Backend Suite - 3/7488 specs Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776324075

Will run 3 specs
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2601
• PASSED [0.000 seconds]
•[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2654
• PASSED [0.000 seconds]
•[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2780
• PASSED [0.000 seconds]
•------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.136 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 0
 SUCCESS! 136.307854ms PASS

Ginkgo ran 1 suite in 12.165523429s
Test Suite Passed

This implementation cannot control the [1776103444] Backend Suite - 3/7488 specs line. I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

@openshift-ci
Copy link
Copy Markdown

openshift-ci bot commented Mar 24, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Mar 24, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible
  • yaml testdata files are not being compiled in and are just referenced from the file tree

TODO:

  • explore --dry-run and piping possibilities with ginkgo, to eliminate the 'skipped tests' number to include non netobserv tests.
  • port latest netobserv test changes.

Please comment, if you see any other thinks we could change.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci
Copy link
Copy Markdown

openshift-ci bot commented Mar 24, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign stleerh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@codecov
Copy link
Copy Markdown

codecov bot commented Mar 24, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.28%. Comparing base (877e2e9) to head (037d406).
⚠️ Report is 91 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2586      +/-   ##
==========================================
- Coverage   72.65%   72.28%   -0.37%     
==========================================
  Files         104      107       +3     
  Lines       10615    11354     +739     
==========================================
+ Hits         7712     8207     +495     
- Misses       2429     2659     +230     
- Partials      474      488      +14     
Flag Coverage Δ
unittests 72.28% <ø> (-0.37%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 42 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Mar 24, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

TODO:

  • explore --dry-run and piping possibilities with ginkgo, to eliminate the 'skipped tests' number to include non netobserv tests.
  • port latest netobserv test changes.

Please comment, if you see any other thinks we could change.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Mar 25, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

TODO:

  • port latest netobserv test changes.

Please comment, if you see any other thinks we could change.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Comment thread integration-tests/backend/alerts.go Outdated
@@ -0,0 +1,44 @@
package netobserv
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 we change the package name to say, may be "integration-tests" instead?

Copy link
Copy Markdown
Author

@oliver-smakal oliver-smakal Apr 1, 2026

Choose a reason for hiding this comment

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

Sure, what about just integration, testsuite or tests?

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.

e2etests?

ensureNetObservOperatorDeployed(oc, NO, NOSource, deployedUpstreamCatalogSource)
})

g.It("Author:aramesha-High-64156-Verify IPFIX-exporter [Serial]", func() {
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 am not sure if labels like [Serial] will have any meaning here. Most of the tests that deals with flowcollector resource are Serial, we could use ginkgo Ordered decorator to make tests Serial.

We should also probably evaluate what tests could run in parallel, for e.g. FlowMetrics ones perhaps?

Copy link
Copy Markdown
Author

@oliver-smakal oliver-smakal Apr 2, 2026

Choose a reason for hiding this comment

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

I am not sure if labels like [Serial] will have any meaning here. Most of the tests that deals with flowcollector resource are Serial, we could use ginkgo Ordered decorator to make tests Serial.

Unless we do -p flag, than it does not run in parallel. But I will definitionally cleanup the [Serial] flags once I merge the latest test changes.

We should also probably evaluate what tests could run in parallel, for e.g. FlowMetrics ones
perhaps?

Agree, I will make sure it is possible to run tests in parallel and do some brief exploration and suggestion on which tests to run in parallel. It is nice that with the Ordered we could even run tests in stages, if a few tests can run in parallel together but cannot run parallel with others.

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.

cool, all of these can be done as follow ups, no rush to get them as part of migration.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

TODO:

  • port latest netobserv test changes.

Please comment, if you see any other thinks we could change.

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

This way you can see which parts we can control by which part of the code. The things that are not under our controll using the current implementation is anything above --------------------REPORT_BEFORE_SUITE_START-------------------- line eg. the [1776103444] Backend Suite - 3/7488 specs. I don't think it will be issue in any way, as for people the rest of the report can be made really clear in what is actually being run. For running it in prow it should also not be a problem if we preserv the way it works with the openshift-test-private repo, is that a junit report is generated and then parsed there. Machine outputs from ginkglo like junit or json are not affected by the report hooks and should be parsed in prow if nescessary.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line. I don't think it will be issue in any way, as for people the rest of the report can be made really clear to see what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo, is that a junit report is generated and then parsed there. Machine outputs from ginkgo like junit or json are not affected by the report hooks.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could use something a bit more custom using more low level ginkgo functionality like in commit xxx, that could get us whatever console output we wish. But I don't think it would be worth the tradeoff of not using the default ginkgo runner as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line. I don't think it will be issue in any way, as for people the rest of the report can be made really clear to see what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo, is that a junit report is generated and then parsed there. Machine outputs from ginkgo like junit or json are not affected by the report hooks.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could use something a bit more custom using more low level ginkgo functionality like in commit xxx, that could get us whatever console output we wish. But I don't think it would be worth the tradeoff of not using the default ginkgo runner as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could use something a bit more custom using more low level ginkgo functionality like in commit xxx, that could get us whatever console output we wish. But I don't think it would be worth the tradeoff of not using the default ginkgo runner as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit xxx, that could get us whatever console output we wish. But I don't think it would be worth the tradeoff of not using the default ginkgo runner as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc3, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 13, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes.

Example output

The following is an example output of of a run, with added start/end report hooks for clarity:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In this example I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code, but would not actually be part of the implementation. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 13, 2026

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 13af035a-d238-4ee7-984e-8e63fa5f74cb

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 14, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes and add guards to skip some of the testcases for certain openshift versions. Then I would put this PR from Draft status.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 14, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes and add guards to skip some of the testcases for certain openshift versions. Then I would put this PR from Draft status.

How to run locally

Either:

go run github.com/onsi/ginkgo/v2/ginkgo #to run all
go run github.com/onsi/ginkgo/v2/ginkgo --focus="VM" #use regex to filter

or if the ginkgo cli is installed:

ginkgo #to run all
ginkgo --focus="VM" #use regex to filter

Other standard flags of ginkgo such as --dry-run or -v also work.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the '---REPORTxxxxSTART/END---' to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 14, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes and add guards to skip some of the testcases for certain openshift versions. Then I would put this PR from Draft status.

How to run locally

Either:

go run github.com/onsi/ginkgo/v2/ginkgo #to run all
go run github.com/onsi/ginkgo/v2/ginkgo --focus="VM" #use regex to filter

or if the ginkgo cli is installed:

ginkgo #to run all
ginkgo --focus="VM" #use regex to filter

Other standard flags of ginkgo such as --dry-run or -v also work.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 7485

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the ---REPORTxxxxSTART/END--- to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 14, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes and add guards to skip some of the testcases for certain openshift versions. Then I would put this PR from Draft status.

How to run locally

Either:

go run github.com/onsi/ginkgo/v2/ginkgo #to run all
go run github.com/onsi/ginkgo/v2/ginkgo --focus="VM" #use regex to filter

or if the ginkgo cli is installed:

ginkgo #to run all
ginkgo --focus="VM" #use regex to filter

Other standard flags of ginkgo such as --dry-run or -v also work.

Example output

The following is an example output of of a run:

$ go run github.com/onsi/ginkgo/v2/ginkgo --focus="Kafka" -v --dry-run
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/networking
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/subscription
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/testdata/flowcollector_v1beta2_template.yaml
[1776103444] Backend Suite - 3/7488 specs
--------------------REPORT_BEFORE_SUITE_START--------------------
Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776103444

Will run 3 specs

--------------------REPORT_BEFORE_SUITE_END--------------------
--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2606
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2659
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•--------------------REPORT_AFTER_EACH_START--------------------
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2785
• PASSED [0.000 seconds]
--------------------REPORT_AFTER_EACH_END--------------------
•
--------------------REPORT_AFTER_SUITE_START--------------------
------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.122 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 3

--------------------REPORT_AFTER_SUITE_END--------------------
SUCCESS! 122.331852ms PASS

Ginkgo ran 1 suite in 12.321528802s
Test Suite Passed

In current form I have used the ---REPORTxxxxSTART/END--- to indicate which parts can be controlled by which parts of our code. This implementation cannot control anything above line REPORT_BEFORE_SUITE_START or below line REPORT_AFTER_SUITE_END . This means we cannot adjust the [1776103444] Backend Suite - 3/7488 specs line.

I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@openshift-ci-robot
Copy link
Copy Markdown
Collaborator

openshift-ci-robot commented Apr 16, 2026

@oliver-smakal: This pull request references NETOBSERV-2387 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Description

This PR is intended to show how the e2e backend migration of tests could look like and where we can discuss more details.

Changes compare to the openshift-tests-private repo:

  • using ginkgo directly without wrapper
  • using BeforeSuite possible, but we need to be carefull about not using compat_otp.NewCLI and similar utilities which have g.BeforeEach calls
  • yaml testdata files are not being compiled in and are just referenced from the file tree

Once agreed on the implementation, the testcases will need to be ported over one more time to reflect the latest changes and add guards to skip some of the testcases for certain openshift versions. Then I would put this PR from Draft status.

How to run locally

Either:

go run github.com/onsi/ginkgo/v2/ginkgo #to run all
go run github.com/onsi/ginkgo/v2/ginkgo --focus="VM" #use regex to filter

or if the ginkgo cli is installed:

ginkgo #to run all
ginkgo --focus="VM" #use regex to filter

Other standard flags of ginkgo such as --dry-run or -v also work.

Example output

The following is an example output of of a run:

[1776324075] Backend Suite - 3/7488 specs Running Suite: Backend Suite - /home/osmakal/Repos/network-observability-operator/integration-tests/backend
==========================================================================================================
Random Seed: 1776324075

Will run 3 specs
[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-Critical-56362-High-53597-High-56326-Verify network flows are captured with Kafka with TLS [Serial][Slow]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2601
• PASSED [0.000 seconds]
•[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-Longduration-High-57397-High-65116-Verify network-flows export with Kafka and netobserv installation without Loki[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2654
• PASSED [0.000 seconds]
•[sig-netobserv] Network_Observability with Loki with Kafka Author:aramesha-NonPreRelease-High-64880-High-75340-Verify secrets copied for Loki and Kafka when deployed in NS other than flowcollector pods and networkPolicy enabled[Serial]
/home/osmakal/Repos/network-observability-operator/integration-tests/backend/test_flowcollector.go:2780
• PASSED [0.000 seconds]
•------------------------------

Backend Suite - 3/3 specs • SUCCESS! [0.136 seconds]

Ran 3 tests
Passed: 3, Failed: 0, Skipped: 0
SUCCESS! 136.307854ms PASS

Ginkgo ran 1 suite in 12.165523429s
Test Suite Passed

This implementation cannot control the [1776103444] Backend Suite - 3/7488 specs line. I don't think it will be issue in any way, as the rest of the report can make it really clear to us what is actually being run. For running it in prow it should also not be a problem if we preserve the way it works with the openshift-test-private repo and use junit report.

More examples:

How it could be used in CI.

Currently the openshift-test-private implementation uses junit to handle the result.
See lines 398-459 that junit result is generated and parsed and later is used by the openshift-e2e-test-qe-report step to fail the prow job if necessary). For the nice output in prow, it seems like the function handle_result in the openshift-extended-test step is used as it seems to be formatting and renaming the junit file with the help of handleresult.py python script.

Though this is probably not directly reusable for implementation as the junit in openshift-test-private does not use default ginkgo implementation, we could use the same idea and use the junit output with minor transformation in prow to report result in a nice way.

Alternative approaches

We could create something a bit more custom using more low level ginkgo functionality like in commit fbb6fc36b17bc37b6eb847b8e51f42d26a9b29d8, to remove things like the [1776103444] Backend Suite - 3/7488 specs line. However, I don't think it would be worth the tradeoff of not using the default ginkgo runner via RunSpecs() as we would use the possibility to run tests in parallel and some other features.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

Oliver Smakal added 2 commits April 19, 2026 21:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants