run_number is not unique enough for trace_id about gha-buildevents

[kvrhdn]

Thanks for the report, I can confirm this happens with my workflows as well.

I think we can either:

• add the run ID to the trace components, the trace ID will become: <workflow>-<job>-<run-number>-<matrix-key>-<run ID> tried this in #17
• append a short random ID, I assume the runners will have enough randomness to generate something new every time
• use a completely random trace ID (a UUID for example)

I don't know if there is any drawback related to really long trace ID's, but the first feels most user friendly.

[kvrhdn]

So adding GITHUB_RUN_ID to the trace ID does not work, this run ID remains the same across re-runs.

This is also documented that way 😅:

Environment variable	Description
GITHUB_RUN_ID	A unique number for each run within a repository. This number does not change if you re-run the workflow run.
GITHUB_RUN_NUMBER	A unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run.

[DavidS]

So adding GITHUB_RUN_ID to the trace ID does not work, this run ID remains the same across re-runs.

which is weird, given the github.run_id field in my screenshots is different. 🤷‍♂️
I'd be fine with replacing the whole trace_id with a uuid or the otel style random byte[] string (see https://github.com/honeycombio/buildevents/blob/a29a075b660897b8e610b5ee479015d7da930481/cmd_cmd.go#L71)

[DavidS]

god - I must be really stressed. There is no repo name in the trace-id - and we're running on 50 different repos - no wonder there're collisions. 🤦

[kvrhdn]

I can confirm this is fixed now. Re-running the workflow creates a unique trace id: