beta version: Implementation tasks

[y1yang0]

v0 Goal

Ensure the net/http and grpc injection functions correctly.

Roadmap

• Initial

  • Setup Phase
    • isSetup - Check if setup phase is already done(because we can either otel setup + otel go build or just otel go build)
    • feat: find project's dependencies #34 - Find all dependencies of the project being build
    • feat: match hook rules with found dependencies #35 - Match the hook code with these dependencies
    • feat: introduce hook dependencies via otel.runtime.go #38 - Introduce additional hook code by generating otel.instrumentation.go
    • feat: sync new dependencies to go.mod #39 - Run go mod tidy to refresh dependencies
    • feat: instrument.load matched rules from setup phase #43 - Write the matched hook rules to match.txt
  • Instrument Phase
    • feat: instrument.load matched rules from setup phase #43 - Load matched hook rules from match.txt
    • feat: match the rules with compile command in instrument phase #46 - Check if the current package should be instrumented
    • feat: instrument the package #50 - Instrument the target function
  • Misc
    • Support otel cleanup subcommand #96

• Test

  • basic test framework and enable it in CI/CD
  • Add unit test for tool/{util,ex,cmd} and tool/internal/{ast,setup} #47 - unit test
  • Enable CI test actions #51 - unit test
  • Add an integration test for the full OTel injection process. The test should inject, run the app, and then verify the output - integration test
  • Link the instrumented binary and run it and further check output content in instrument_test.go #104

• Demo

  • Highest priority Refactor the demo applications to use net/http and grpc. - This will serve as our primary testbed
    • Support trace context propagation in demo application
    • Add basic net/http instrumentation rule under pkg/instrumentation/http
    • Add basic grpc instrumentation rule under pkg/instrumentation/grpc
    • Make http+grpc rules work

• Functionality

  • feat: instrument struct #83 - inject new field for arbitrary struct
  • Auto-generate go:linkname tags instead of depending on hook author
  • Split large trampoline.go into smaller files
  • refactor: limit visibility to necessary fields and constants #92 - Unexport HookContextImpl fields
  • Only embedding the *.yaml and *.gz instead of wildcard in tool/data/export.go
  • More detailed documents for new contributors
  • Auto-sync template_api.go and pkg/inst/context.go #54 - auto-sync two files
  • Consolidate all embeded files into tool/data dir
  • feat: instrument func with receiver type #105 - Inject func with receiver
  • feat: propagate otel trace context from caller goroutine #98

Please feel free to claim the implementation tasks.

[kakkoyun]

@y1yang0 Let's talk about this in the next SIG meeting.
We should also utilize the projects as we talked.

[123liuziming]

I think we should spilt a more detailed task list so we can do that concurrently

[RomainMuller]

My speciality is more towards instrumentation / AST manipulation, so I'm definitely up to contribute on this.

[pdelewski]

Two clear candidates for parallelization are:

• Dependency setup
• Instrumentation / AST manipulation

We can try to split this work further.

[kakkoyun]

Let's use Go Compile-Time Instrumentation - v0 (view) after creating the tasks as we discussed before.

[pdelewski]

@RomainMuller @kakkoyun @y1yang0 @123liuziming

I've been thinking about the list of tasks recently. It's great that we now have a basic framework with a well-defined workflow and clear entry points for the specific functionalities we need to implement.

Rather than treating these functions in isolation, we should approach them in terms of milestones—for example:
– instrumenting "hello world"
– instrumenting a basic HTTP server

This aligns with the idea of feature-based programming, where we focus on delivering vertical slices of functionality that are useful and testable from a user’s perspective.

In that sense, we don’t need to fully implement every individual function upfront. Instead, we should aim to implement only what’s necessary to satisfy each milestone or feature.

For example, we’ll likely need to more or less fully implement addDeps and refreshDeps. But functions like matchDeps (in the Setup phase) and load, match, and instrument (in the Instrumenting phase) may only require minimal implementation at this stage—just enough to support the current milestone.

Let me know your thoughts.

[ralf0131]

I think this is a good idea, which gives us a clear objective targeting end users.

@RomainMuller @kakkoyun @y1yang0 @123liuziming

I've been thinking about the list of tasks recently. It's great that we now have a basic framework with a well-defined workflow and clear entry points for the specific functionalities we need to implement.

Rather than treating these functions in isolation, we should approach them in terms of milestones—for example: – instrumenting "hello world" – instrumenting a basic HTTP server

This aligns with the idea of feature-based programming, where we focus on delivering vertical slices of functionality that are useful and testable from a user’s perspective.

In that sense, we don’t need to fully implement every individual function upfront. Instead, we should aim to implement only what’s necessary to satisfy each milestone or feature.

For example, we’ll likely need to more or less fully implement addDeps and refreshDeps. But functions like matchDeps (in the Setup phase) and load, match, and instrument (in the Instrumenting phase) may only require minimal implementation at this stage—just enough to support the current milestone.

Let me know your thoughts.

[pdelewski]

@y1yang0 I’d like to help, but at the moment I can’t commit to more than doing reviews.

[y1yang0]

I can’t commit to more than doing reviews.

That’s already so much — I’m really grateful!