feat: migrate to tools directive

[dnaeon]

Description

This PR migrates the existing internal/tools to the new recommended approach for managing tool dependencies.

The makefile targets have been updated, including test/build scripts as well.

All tools have been migrated to the to the new go tool approach, with one exception - modernize tool.

The reason why modernize has been left out is because of this issue.

The issue here is that the modernize command, currently (but not fundamentally) part of the gopls module, is governed by the gopls release process, and you can't just upgrade the x/tools package to a later one, as happens when installing stringer, because the gopls release branch needs a particular version and x/tools does not present a stable internal API to gopls. In short, no-one should ever add gopls as a module dependency, and that means you cannot use go get -tool with gopls. I will update the documentation to make this clear.

Please check this issue for full details:

• cmd/go: adding a tool dependency leads to build failures golang/go#73279

Based on the comment above it would appear that even in the current internal/tools/go.mod we have a dependency on gopls, which we should not.

cc: @mx-psi

Link to tracking issue

Fixes #13721

Testing

Manual testing and running the various Makefile targets, including all target.

Documentation

N/A

[dnaeon]

I've set the min Go version to 1.24 for the tools, which should fix the majority of the pipeline failures, since they are running on the old stable version.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.67%. Comparing base (cd46300) to head (b471232).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #13844      +/-   ##
==========================================
- Coverage   91.69%   91.67%   -0.02%     
==========================================
  Files         652      652              
  Lines       42506    42506              
==========================================
- Hits        38976    38968       -8     
- Misses       2725     2731       +6     
- Partials      805      807       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dnaeon]

Please hold this one for now, as it seems there is an issue related to how go tool ... interprets relative replace statements in go.mod when using the -modfile flag, which is the reason for this pipeline failure.

• https://github.com/open-telemetry/opentelemetry-collector/actions/runs/17767453794/job/50495070389?pr=13844

go tool -modfile /home/runner/work/opentelemetry-collector/opentelemetry-collector/internal/tools/go.mod pdatagen
go.opentelemetry.io/collector/internal/cmd/pdatagen: go.opentelemetry.io/collector/internal/cmd/[email protected]: replacement directory ../cmd/pdatagen does not exist
make: *** [Makefile:256: genpdata] Error 1
Error: Process completed with exit code 2.

It appears that the relative replace statement is relative to the current directory of the calling process (in this case the repo root), instead of location of the go.mod file itself.

I will follow up with additional details, as soon as I have them, but for now please hold this PR. Thanks!

[dnaeon]

Please hold this PR for now, as there is a known limitation with how go tool -modfile <tool-name> works when being called outside of the tools module.

See this one for more details.

• cmd/go/tool: tool directive with local relative path replace golang/go#75497

@dmathieu , in order to workaround this limitation we may need to remove the replace directive in the internal/tools module.

Are you okay with such changes? Also, is there a specific reason why pdatagen is not exported/published elsewhere, and requires a replace directive?

Thanks!

[dmathieu]

Removing the replace directive would be fine by me, if the behavior remains the same.
pdatagen should stay in this repository however. It's a tool that generates code used only by this repository, and has no reason to be used elsewhere. So extracting it would just make things harder to maintain.

[dnaeon]

Removing the replace directive would be fine by me, if the behavior remains the same. pdatagen should stay in this repository however. It's a tool that generates code used only by this repository, and has no reason to be used elsewhere. So extracting it would just make things harder to maintain.

Makes sense, I've just updated and rebased the PR.

[dnaeon]

@dmathieu , @mx-psi , as far as I can tell I can safely ignore this pipeline failure?

• https://github.com/open-telemetry/opentelemetry-collector/actions/runs/17922993205/job/51010279614

[mx-psi]

@dmathieu , @mx-psi , as far as I can tell I can safely ignore this pipeline failure?

• https://github.com/open-telemetry/opentelemetry-collector/actions/runs/17922993205/job/51010279614

Yes, feel free to ignore that error, it is not related to this PR

[mx-psi]

Feel free to rebase this PR now!

[dnaeon]

Feel free to rebase this PR now!

... and done :)

[mx-psi]

Thank you!!

[otelbot]

Thank you for your contribution @dnaeon! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey.