fix: solaris build compatibility

[gaige]

Proposed commit message

This is a change to allow beats (for now specifically filebeat and heartbeat, others likely coming in the future) to be compiled and run on SmartOS and other Solaris systems.

Mostly this is a matter of excluding from build requirements, but for a couple of tests we also needed to stub out the kubernetes provider (which should also be usable on AIX).

Tests are accomplished with the existing test cases.

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.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Disruptive User Impact

There should be no impact for non-Solaris/Illumos/SmartOS users

Author's Checklist

• ensure tests run correctly on other platforms

How to test this PR locally

This will require a local Solaris/SmartOS/Illumos environment to test.

Related issues

Use cases

Screenshots

Logs

[github-actions]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[mergify]

This pull request does not have a backport label.
If this is a bug or security fix, could you label this PR @gaige? 🙏.
For such, you'll need to label your PR with:

• The upcoming major version of the Elastic Stack
• The upcoming minor version of the Elastic Stack (if you're not pushing a breaking change)

To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[elasticmachine]

Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane)

[elasticmachine]

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

[gaige]

Is there anything else I need to do to move this forward?

[mauri870]

Is there anything else I need to do to move this forward?

I don't see any blockers, it is missing reviews from our team so we should be focusing on that next.

[mauri870]

Thanks, the changes here look good. I'll unblock the CI next.

[gaige]

@mauri870 I think I've fixed the link errors.

[gaige]

Please approve the workflows so that I can see the remaining lint issues. I gather from the last set of warnings that by touching the files (in my case adding the build directives) that now I own pre-existing lint issues ? Any recommendations on how to resolve these would be appreciated, although they mostly look like unchecked return values.

Sorry for the delay, I'm back from holiday today. If the lint issues are easy to fix, we generally go ahead and fix them or add a //nolint comment with a reasonable explanation when touching old files. However, if the issues are in parts of the file you didn’t actually modify, it’s usually fine to leave them as-is. I’ve unblocked the workflows.

I did a mixture of actual changes where they were straightforward and a few places I did //nolint.

No worries on the delay, I was pencils-down on the weekend anyway, so it didn't slow me down.

[mauri870]

/test
run docs build

[mauri870]

/test
run docs build

[pierrehilbert]

/test

[gaige]

@pierrehilbert
Can someone help me understand what's going on here? I have zero visibility into the failed tests here (they all go to pages that 404, and there's nothing pulled back into the files as there usually is for the github-based tests.

I'd love to address whatever problems are here, but I'm at a bit of a loss.

[mauri870]

Remaining linter issues:

   Error: libbeat/autodiscover/providers/kubernetes/node.go:117:10: Error return value is not checked (errcheck)
  	node := obj.(*kubernetes.Node)
  	        ^
  Error: libbeat/autodiscover/providers/kubernetes/node.go:135:58: Error return value is not checked (errcheck)
  	time.AfterFunc(n.config.CleanupTimeout, func() { n.emit(obj.(*kubernetes.Node), "stop") })
  	                                                        ^
  Error: libbeat/autodiscover/providers/kubernetes/node.go:147:14: Error return value is not checked (errcheck)
  		kubeMeta = rawMeta.(mapstr.M)

[mauri870]

Thanks for fixing the pending issues! Unblocking the CI 🙏

[gaige]

Thanks for fixing the pending issues! Unblocking the CI 🙏

I don’t understand why every time we rerun the ci-cd it develops new issues in files that were unchanged from the last run and had no warnings previously. Further, I don’t understand why these issues don’t reflect what I see when running mage LLC with GOOS=linux.

Any recommendations on how to make this less of a drip?

[pierrehilbert]

/test

[mauri870]

Any recommendations on how to make this less of a drip?

Sorry about that, CI can be quite picky at times. I'm looking at the failures and looks like you need to run make update and commit the changes. There is also the following linter issues:

  Error: libbeat/autodiscover/providers/kubernetes/node.go:161:19: Error return value is not checked (errcheck)
  				annotations = rawAnn.(mapstr.M)
  				              ^
  Error: libbeat/autodiscover/providers/kubernetes/pod.go:214:9: Error return value is not checked (errcheck)
  	p.emit(obj.(*kubernetes.Pod), "start")
  	       ^
  Error: libbeat/autodiscover/providers/kubernetes/pod.go:227:9: Error return value is not checked (errcheck)
  	p.emit(obj.(*kubernetes.Pod), "stop")
  	       ^
  3 issues:
  * errcheck: 3

[gaige]

Sorry about that, CI can be quite picky at times. I'm looking at the failures and looks like you need to run make update and commit the changes. There is also the following linter issues:

I don’t really have a problem with it being picky. Incomplete and not available are the issues. It seems to be failing fast on lint failures in one file and since I can’t reproduce reliably on my machine, I have to wait basically a day for another file; all this because I added build directives to files causing them to be in scope.

if there’s a trick to getting the same output on my local system as we get from the CI linter, that’d be super helpful, so I could clean everything at once before committing.

[mauri870]

if there’s a trick to getting the same output on my local system as we get from the CI linter, that’d be super helpful, so I could clean everything at once before committing.

Looking at the build code, I can pinpoint the commands that CI uses:

make -C libbeat check update
make check-no-changes

And for the linter:

golangci-lint run --new-from-patch=<(git diff main) --new=false --new-from-rev= --timeout=30m --whole-files

This last one is a github action, so I'm guessing what it probably does, I'm not entirely sure.

Give it a try, it should report the linter failures I posted on #45105 (comment).

[gaige]

Give it a try, it should report the linter failures I posted on #45105 (comment).

Interestingly, it doesn't. Looking at the docs for golangci-lint it looks like GOOS isn't going to be sufficient. I'll need to spin up a separate Linux dev environment to run it in order to get the results from the linux version. That'll take me a day or two...

[mauri870]

/test
run docs build

[mauri870]

The remaining linter failures seems unrelated with your changes. I'll give another quick review and then merge the changes. Thank you for contributing to Beats!