[QE] Compactify e2e tests

[jsliacan]

trafficstars

This PR contains the following changes

• include the relevant clicumber code in this codebase, as suggested in #2538 and #3210
• update dependencies (cucumber/godog/...)
• compactify features/scenarios to fit the cucumber paradigms
• leave out config.feature (should be replaced by an integration test of similar extent #3249)

[adrianriobo]

Does it make sense keep the clicumber integrated code under e2e? Or may keep e2e only with suites and features and move the clicumber code to extended?

WDYT?

[jsliacan]

@adrianriobo , I moved it directly into testsuite because testsuite was "extending" the clicumber suite. That said, I am happy to put it wherever you think is better, I have no real opinions either way.

EDIT: It's in extended now as you suggested.

[jsliacan]

/retest

[anjannath]

/test

[openshift-ci[bot]]

@anjannath: The /test command needs one or more targets. The following commands are available to trigger required jobs:

• /test e2e-crc
• /test images
• /test integration-crc

Use /test all to run all jobs.

In response to this:

/test

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 kubernetes/test-infra repository.

[anjannath]

/test all

[jsliacan]

/retest

[jsliacan]

/retest

[anjannath]

@jsliacan pr needs rebase

[anjannath]

nice speedup for e2e, integration tests!

test time	e2e	integration
this pr	1h52m46s	1h12m18s
in main	2h31m8s	1h23m38s

[anjannath]

Include clicumber code, update dependencies, compactify feature files

i guess these three things are tightly coupled and hard to split into individual commits without rewriting the feature files multiple times for each commit.. better to also include the information in the pr description as commit log

[anjannath]

leave out config.feature (should be replaced by an integration test of similar extent https://github.com/code-ready/crc/issues/3249)

@jsliacan maybe keep the config.feature for now (if it works with the current changes) and remove it when we have something similar in the integration tests? i.e when working on fixing #3249

[anjannath]

better to exclude the config.feature changes from the first commit itself than removing it and re-adding

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anjannath

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

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [anjannath]

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

[openshift-ci[bot]]

New changes are detected. LGTM label has been removed.