buildkite / buildkite/agent

Additional information on OpenTelemetry spans

Open
#1,563 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
1.1k
Forks
378
Avg merge
2d 6h
Merged PRs (30d)
74

Description

**Is your feature request related to a problem? Please describe.**

I was very excited to try out the OpenTelemetry backend to get some insight into our CI performance. It is so close but I am missing a few pieces of information on spans that would really make the difference for me. I saw a comment on an older issue that seemed to imply adding more information to spans was not desired (https://github.com/buildkite/agent/issues/869#issuecomment-447684086) but it would make a big differenct.

We dynamically generate all but one of our build steps. That results in unstable job uuids for each job. The labels of the job are stable over time, though. That makes the OpenTelemetry span data collected almost useless to track job performance over time (which is my ultimate goal). It would be much nicer to see the value of `BUILDKITE_LABEL` instead of `BUILDKITE_JOB_ID`.

**Describe the solution you'd like**

In fact it might be nice to do one of the following:

* Expose all reasonable environment variables to the spans as contextual information, much like you might see in a debugger's local variables inspection.
* Make the contextual information available configurable by the user. I like the way `sudo --preserve-env` works as an example.

**Describe alternatives you've considered**

I suppose you could make graphql calls for each span to get more detail about the label but that seems wasteful. Perhaps there are other options I have not considered.

Contributor guide

Open the contributing guide

Research direction

Start by locating the agent's OpenTelemetry span instrumentation and reviewing the linked discussion in issue 869. Compare the existing BUILDKITE_JOB_ID context with the requested BUILDKITE_LABEL value, then determine whether configurable contextual environment variables are in scope. Done should include an agreed attribute or configuration design and tests covering the resulting span data.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
observability
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.