[chore] Add extension/cgroupruntime integration tests

[rogercoll]

Description

Adds some integration tests for the extension. It uses the containerd/cgroups package to modify the current process's allocated cgroup resources and assert the corresponding values for GOMEMLIMIT/GOMAXPROCS set by the extension.

Link to tracking issue

Fixes #36545

Testing

Cgroup resources modification requires privileged access in GHA runner instances, thus the test must be run with sudo. The go toolchain has an exec flag to run tests binary(s) via another binary such as sudo. The Makefile has been modified to run Go tests files with build tag integration && sudo with the sudo command. I am not very confident with this solution, as I could not find any other component requiring privileged execution for its integration tests and the "go test -tags=integration,sudo" would run for all of them. I am all ears on other testing strategies for this use case.

Similar strategy in cgroups package https://github.com/containerd/cgroups/blob/main/.github/workflows/ci.yml#L101

Documentation

[mx-psi]

From the Collector SIG 2024-12-11 meeting, we think this approach is okay to take

[rogercoll]

Checking why the CI is failing 👀

[rogercoll]

@mx-psi I changed a bit the Go build approach to use it with the -run flag as well. The reasoning was because files (tests) without Go tags will run by default, meaning that when we run the integrations tests, we are also running the unit tests ones. So only adding the sudo Go build tag was also running the unit tests as a privileged user and some components were failing.

At the moment, we have the following scenarios when running the mod-integration-test Makefile target:

• All Integration tests that do not contain "Sudo" in its function name (-skip Sudo) and the integration build tag + Unit tests → run with the default user
• All Integration tests that contain "Sudo" in their function name and the integration build tag → run as sudo

Another downside of this solution is that if anyone runs the integrations Make target locally, the sudo prompt will appear. That is an issue because maybe in some systems the sudo tool is not available (Windows), wdyt if we only run those tests on the CI (check that the CI env variable is defined)? How could I document all the previous?

I am totally open to any suggestion of improvement, this solution looks very specific to this component.

[mx-psi]

@rogercoll LGTM

I changed a bit the Go build approach to use it with the -run flag as well. The reasoning was because files (tests) without Go tags will run by default, meaning that when we run the integrations tests, we are also running the unit tests ones. So only adding the sudo Go build tag was also running the unit tests as a privileged user and some components were failing.

Can you file an issue about this? From what we talked it seemed like we were running unit tests twice under the same conditions, I would like to avoid that.

Another downside of this solution is that if anyone runs the integrations Make target locally, the sudo prompt will appear. That is an issue because maybe in some systems the sudo tool is not available (Windows), wdyt if we only run those tests on the CI (check that the CI env variable is defined)? How could I document all the previous?

I feel like that is okay? Sudo for Windows is now a thing and I would not be suprised about other tests already having this issue of only running correctly on CI. I suggest we don't care about this until somebody complains 😄

[mx-psi]

Also, can you fix the merge conflict?

[rogercoll]

Can you file an issue about this? From what we talked it seemed like we were running unit tests twice under the same conditions, I would like to avoid that.

Sure, I gathered the details here #36817

I feel like that is okay? Sudo for Windows is now a thing and I would not be suprised about other tests already having this issue of only running correctly on CI. I suggest we don't care about this until somebody complains 😄

Sounds good :), I was not aware of sudo also available on Windows. If we want to only run them on the CI at some point, we would need to modify the current go test command with [ -n "$CI" ] && $(GOTESTSUM) $(GOTESTSUM_OPT) --packages="./..." -- $(GOTEST_OPT_WITH_INTEGRATION_SUDO)

[rogercoll]

Also, can you fix the merge conflict?

Fixed 🤞

[r0mdau]

How do you ensure the integration test is running ?

Locally, this test is skip because I am not running in a containerized environment.

// checkCgroupSystem skips the test if is not run in a cgroupv2 system
func checkCgroupSystem(tb testing.TB) {

I wonder if within Github Action this test is Skip too. Why asking ? I added integration test for a future PR to integrate gomaxecs : r0mdau#1

[rogercoll]

How do you ensure the integration test is running ?

Locally, this test is skip because I am not running in a containerized environment.

// checkCgroupSystem skips the test if is not run in a cgroupv2 system
func checkCgroupSystem(tb testing.TB) {

I wonder if within Github Action this test is Skip too. Why asking ? I added integration test for a future PR to integrate gomaxecs : r0mdau#1

I think here you can find the execution output: https://github.com/r0mdau/opentelemetry-collector-contrib/actions/runs/12438898261/job/34732589575?pr=1#step:5:118 The CI test is named integration-tests-matrix (extension)