feat(profiling): Add --trace-profile flag

[jboewer]

What type of PR is this?

/kind feature

What this PR does / why we need it:

Introduces a new --trace-profile [file] flag to generate a Go execution trace, for performance diagnostics using go tool trace.

Currently, buildah provides flags for profiling CPU (--cpu-profile) and memory (--memory-profile) usage.

However, when a build is slow but CPU usage is low, it's difficult to diagnose the bottleneck. These latency issues are often caused by time spent waiting on I/O (network or disk), blocking on system calls, or other scheduler events. The standard Go tool for investigating these specific issues is the execution tracer (go tool trace).

How to verify it

Run any buildah command with the additional --trace-profile flag.
For example

buildah info --trace-profile=/tmp/trace.out
go tool trace /tmp/trace.out

Which issue(s) this PR fixes:

None

Does this PR introduce a user-facing change?

add support for `--trace-profile [file]` to generate an execution trace.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: jboewer
Once this PR has been reviewed and has the lgtm label, please assign tomsweeneyredhat for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[TomSweeneyRedHat]

@jboewer thanks for the contribution. Can you add a test or three for this please?

[jboewer]

@jboewer thanks for the contribution. Can you add a test or three for this please?

Hey @TomSweeneyRedHat

Just added tests for all 3 available profiling flags.

Though as far as I know, the go tool CLI flags (such as those for go tool trace and go tool pprof) are not covered by Go’s backwards compatibility promise, so the flags or behavior might change in future Go releases and potentially break these tests.

Would you prefer to keep the current assertions that use go tool trace/pprof to validate the generated files, or should we limit the tests to just checking that the files are created and non-empty?

Edit: Tests were just failing as of this very reason. I used go v1.23 locally which had a different go tool trace CLI than the CI's go v1.24. I've switched to using the more stable -pprof=net flag instead of the debug -d=2 flag, but above's question still stands.

[TomSweeneyRedHat]

@jboewer unless @nalind has a differing opinion, and especially given the "fun" you ran into with v1.23 locally, I'd go with the -pprof=net flag as you suggested.

[github-actions]

A friendly reminder that this PR had no activity for 30 days.

[jboewer]

Hey @TomSweeneyRedHat @nalind,

I just noticed I still have this PR open. Do you mind revisiting this subject?

Cheers

[TomSweeneyRedHat]

LGTM
@nalind?