Check for agent rogue processes in integration tests

[pchila]

This commit adds assertions at the beginning and at the end of Fixture.Install() checking that no agent processes are running before installing or after uninstalling.

If any elastic-agent processes are detected, the test is marked as failed but it still runs to completion.

What does this PR do?

This PR adds assertions for elastic-agent processes not running before installing or after uninstalling elastic agent in our integration tests.

Why is it important?

This is needed to highlight any test that leaves agent processes running (usually watchers) which may influence other tests runs and cause flakyness.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] I have made corresponding change to the default configuration files
• [ ] I have added tests that prove my fix is effective or that my feature works
• [ ] I have added an entry in ./changelog/fragments using the changelog tool
• [ ] I have added an integration test or an E2E test

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Relates [Flaky Test]: TestStandaloneUpgrade/Upgrade_8.12.0-SNAPSHOT_to_8.13.0-SNAPSHOT_(privileged) – error installing package: failed to copy source directory... /opt/Elastic/Agent/elastic-agent: file exists #4204

Use cases

Screenshots

Logs

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[mergify]

This pull request does not have a backport label. Could you fix it @pchila? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[AndersonQ]

I don't see why not fail the test as soon we detect there it another agent running, it'll lead to unexpected behaviour in the test anyway. Besides failing the test will block the PR anyway, so I'd say fail fast is better.

Also perhaps it could be more optimistic and do not fail the test when it fails getting the process information. I see it limits the information we have, but it isn't a failure in the test

[pchila]

I don't see why not fail the test as soon we detect there it another agent running, it'll lead to unexpected behaviour in the test anyway. Besides failing the test will block the PR anyway, so I'd say fail fast is better.

Also perhaps it could be more optimistic and do not fail the test when it fails getting the process information. I see it limits the information we have, but it isn't a failure in the test

Originally this was to try and correlate with logs I saw in test runs that did not have this guard.

I want to fail the test because it attracts attention (nobody ever looks at the green ones) but if a test is still leaking or adding processes between start and end I want to see it, hence I let it run to completion.

There was another part to this on the branch I cherry-picked this from where we try to clean up at the end of every test that installed agent after asserting no agent processes but that may be overkill for the moment

Regarding failing if I cannot get process information, if that happens it may be a problem with the setup of the test and I wanted to bring that out too ;)

[elastic-sonarqube]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube