Replace `--compilers` and `--procs` with `-p` flag after Ginkgo v2.23.4 upgrade

[KevFan]

Description

Currently, our integration tests use separate --compilers and --procs flags to configure Ginkgo's parallelization. According to the Ginkgo v2.23.4 documentation, these flags can be replaced with a single -p flag for improved usability.

Current Implementation

--compilers=$(INTEGRATION_TEST_NUM_CORES) \
--procs=$(INTEGRATION_TEST_NUM_PROCESSES) \

Proposed Change

Replace the above with:

-p \

This will automatically configure both compilation parallelization and test execution parallelization based on the available system resources.

Files to Update

• make/integration-tests.mk - All integration test targets:
  • test-bare-k8s-integration (currently uses --procs=1 which should remain)
  • test-gatewayapi-env-integration
  • test-istio-env-integration
  • test-envoygateway-env-integration
  • test-integration

Benefits

• Simplified configuration
• Automatic optimization based on available system resources
• Follows Ginkgo's recommended CI configuration
• Reduces the need for manual tuning of parallelization settings

Prerequisites

• [ ] Upgrade Ginkgo to v2.23.4 or later
• [ ] Verify that -p flag behavior meets our testing requirements
• [ ] Update any CI configurations that depend on the current flag structure

Notes

• The test-bare-k8s-integration target uses --procs=1 intentionally due to the limitation of 1 Kuadrant CR, so this should be preserved or handled appropriately with the new flag.
• Consider removing the INTEGRATION_TEST_NUM_CORES and INTEGRATION_TEST_NUM_PROCESSES variables if they're no longer needed after this change.

[codesmith25103]

Hey I am new to open source. Can you please assign me this issue?

[codesmith25103]

I am not able to join slack channel

[eguzki]

@codesmith25103 assigned to you!

Kuadrant Slack channel https://kubernetes.slack.com/archives/C05J0D0V525

[codesmith25103]

@eguzki I have made the required changes and open the pull request. But i am still not able to slack channel

[codesmith25103]

Facing this error

[eguzki]

Can you try https://slack.k8s.io/ ?

[eguzki]

Upgrade Ginkgo to v2.23.4 or later

@KevFan any reason for the requirement of v2.23.4?

Currently with go 1.24.2, go install github.com/onsi/ginkgo/v2/ginkgo installs

❯ bin/ginkgo version
Ginkgo Version 2.22.0

And -p flag is available

❯ bin/ginkgo run --help | grep -A 1 -- '-p\W'
  -p[0m 
    If set, ginkgo will run in parallel with an auto-detected number of nodes.

[eguzki]

@KevFan regarding constraints of test-bare-k8s-integration,i.e. --procs=1, wouldn't be better to enforce the serializaton of It specs with serial specs ??

[KevFan]

Upgrade Ginkgo to v2.23.4 or later

@KevFan any reason for the requirement of v2.23.4?

Currently with go 1.24.2, go install github.com/onsi/ginkgo/v2/ginkgo installs

❯ bin/ginkgo version
Ginkgo Version 2.22.0

And -p flag is available

❯ bin/ginkgo run --help | grep -A 1 -- '-p\W'
  -p[0m 
    If set, ginkgo will run in parallel with an auto-detected number of nodes.

Yes, this is their recommendation from v2.23.4 onwards according to their documentation for CI:

-p will run each suite in parallel. This can substantially speed up suites. As of 2.23.4 the correct number of available CPUs is identified when running in a linux container - but if you see Ginkgo using the wrong number of CPUs on a shared machine/container you should run with --procs=N and --compilers=N to manually control the number of CPIs used.

• https://onsi.github.io/ginkgo/#recommended-continuous-integration-configuration
• https://github.com/onsi/ginkgo/releases/tag/v2.23.4

While the -p flag was available previous to this version, their previous recommendation was to always use the existing --compilers and --procs flags instead for CI as the -p flag would not work as expected in a CI environment on earlier versions

@KevFan regarding constraints of test-bare-k8s-integration,i.e. --procs=1, wouldn't be better to enforce the serializaton of It specs with serial specs ??

That's true, running the tests serially for those tests instead would be a better approach to allow for keeping running all the test suites consistent and allow for adding tests to run in parallel to that suite if there are cases that allow for it 👍

[eguzki]

Thanks for the explanation. All makes sense to me!