-
Notifications
You must be signed in to change notification settings - Fork 1.3k
appcontext/tracing: make InitContext
public
#4548
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Make `detect.InitContext` public as opposed to only available through the use of contexts from `appcontext` so that downstream users (e.g. buildx) can keep the OTEL context utils without having to use `appcontext` - see: docker/buildx#2184 Signed-off-by: Laura Brehm <laurabrehm@hey.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, ptal @jsternberg
func init() { | ||
appcontext.Register(initContext) | ||
appcontext.Register(InitContext) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if we need to keep the init
, as that would be dead-code if appcontext
is not used (but it will remain a dependency due to it being imported) 🤔
(have not looked how / where it's imported though).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I thought about making other changes to appcontext
/this package for that but had concerns about that possibly silently breaking things for other downstream users. If we do that, we should do that together with other changes to make sure we don't silently break, or clearly call it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(side note, but I really hate init
s for this reason, it's much harder to reason about and figure out the blast radius of changes like this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. My preference for the future is that we make an effort to refactor the tracing code so we're not seeing buildx or other docker utilities depend so heavily on buildkit for tracing utilities and improve the buildx code to have a less ambiguous way of configuring tracing, but this seems like a good way to handle the current problem without making the blast radius too large.
@jsternberg with this function exported, do you think it would make sense to move the (trying to see if we can get |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me LGTM because the other bits can still be worked on in a follow-up 🤞
@thaJeztah I don't know too much about it, but I assume it can probably be moved to another package. |
little ping, maybe we can get this one in and then open up another to move the init elsewhere so we can discuss that there? |
Per latest comments in docker/buildx#2184 , I don't think that PR needs this anymore. |
Closing based on discussion in docker/buildx#2184 |
Make
detect.InitContext
public as opposed to only available through the use of contexts fromappcontext
so that downstream users (e.g. buildx) can keep the OTEL context utils without having to useappcontext
- see: docker/buildx#2184