feat: Implement otel tracing hook. (#130)

Adds the otel hook.
Adds a workspace.

Before using the workspace you need to:
```
make workspace
```

---------

Co-authored-by: Casey Waldren <[email protected]>

.github/ISSUE_TEMPLATE/bug_report--ldotel.md

@@ -0,0 +1,37 @@
+---
+name: Bug report for the ldotel module
+about: Create a report to help us improve
+title: ''
+labels: 'ldotel, enhancement'
+assignees: ''
+
+---
+
+**Is this a support request?**
+This issue tracker is maintained by LaunchDarkly SDK developers and is intended for feedback on the SDK code. If you're not sure whether the problem you are having is specifically related to the SDK, or to the LaunchDarkly service overall, it may be more appropriate to contact the LaunchDarkly support team; they can help to investigate the problem and will consult the SDK team if necessary. You can submit a support request by going [here](https://support.launchdarkly.com/hc/en-us/requests/new) or by emailing [email protected].
+
+Note that issues filed on this issue tracker are publicly accessible. Do not provide any private account information on your issues. If your problem is specific to your account, you should submit a support request as described above.
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To reproduce**
+Steps to reproduce the behavior.
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Logs**
+If applicable, add any log output related to your problem.
+
+**SDK version**
+The version of this SDK that you are using.
+
+**Language version, developer tools**
+For instance, Go 1.22. 
+
+**OS/platform**
+For instance, Ubuntu 16.04, or Windows 10.
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/bug_report.md

@@ -2,7 +2,7 @@
 name: Bug report
 about: Create a report to help us improve
 title: ''
-labels: ''
+labels: 'server-sdk, bug'
 assignees: ''
 
 ---

.github/ISSUE_TEMPLATE/feature_request--ldotel.md

@@ -0,0 +1,20 @@
+---
+name: Feature request for the ldotel module
+about: Suggest an idea for this project
+title: ''
+labels: 'ldotel, enhancement'
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I would love to see the SDK [...does something new...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context about the feature request here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -2,7 +2,7 @@
 name: Feature request
 about: Suggest an idea for this project
 title: ''
-labels: ''
+labels: 'server-sdk, enhancement'
 assignees: ''
 
 ---

.github/actions/unit-tests/action.yml

@@ -5,6 +5,9 @@ inputs:
     description: 'Whether to run linters.'
     required: false
     default: 'false'
+  test-target:
+    description: 'The test target to run.'
+    required: true
 
 runs:
   using: composite
@@ -19,7 +22,7 @@ runs:
     - name: Test
       shell: bash
       id: test
-      run: make test | tee raw_report.txt
+      run: make ${{ inputs.test-target }} | tee raw_report.txt
 
     - name: Process test results
       if: steps.test.outcome == 'success'
@@ -31,5 +34,5 @@ runs:
       if: steps.process-test.outcome == 'success'
       uses: actions/upload-artifact@v4
       with:
-        name: Test-result-${{ steps.go-version.outputs.version }}
+        name: Test-result-${{ inputs.test-target }}${{ steps.go-version.outputs.version }}
         path: junit_report.xml

.github/workflows/ci.yml

@@ -1,4 +1,4 @@
-name: Build and Test
+name: Build and Test SDK
 on:
   push:
     branches: [ 'v7', 'feat/**' ]

.github/workflows/common_ci.yml

@@ -7,7 +7,6 @@ on:
         required: true
         type: string
 
-
 jobs:
   unit-test-and-coverage:
     runs-on: ubuntu-latest
@@ -21,6 +20,7 @@ jobs:
       - uses: ./.github/actions/unit-tests
         with:
           lint: 'true'
+          test-target: sdk-test
       - uses: ./.github/actions/coverage
         with:
           enforce: 'false'
@@ -51,8 +51,6 @@ jobs:
           name: Contract-test-service-logs-${{ steps.go-version.outputs.version }}
           path: /tmp/sdk-contract-test-service.log
 
-
-
   benchmarks:
     name: 'Benchmarks'
     runs-on: ubuntu-latest

.github/workflows/ldotel-ci.yml

@@ -0,0 +1,38 @@
+name: Build and Test ldotel
+on:
+  push:
+    branches: [ 'v7', 'feat/**' ]
+    paths-ignore:
+      - '**.md' # Don't run CI on markdown changes.
+  pull_request:
+    branches: [ 'v7', 'feat/**'  ]
+    paths-ignore:
+      - '**.md'
+
+jobs:
+  go-versions:
+    uses: ./.github/workflows/go-versions.yml
+
+  # Runs the common tasks (unit tests, lint, contract tests) for each Go version.
+  test-linux:
+    name: ${{ format('ldotel Linux, Go {0}', matrix.go-version) }}
+    needs: go-versions
+    strategy:
+      # Let jobs fail independently, in case it's a single version that's broken.
+      fail-fast: false
+      matrix:
+        go-version: ${{ fromJSON(needs.go-versions.outputs.matrix) }}
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Setup Go ${{ inputs.go-version }}
+        uses: actions/setup-go@v5
+        with:
+          go-version: ${{ matrix.go-version }}
+      - uses: ./.github/actions/unit-tests
+        with:
+          lint: 'true'
+          test-target: ldotel-test
+      - uses: ./.github/actions/coverage
+        with:
+          enforce: 'false'

.gitignore

@@ -4,3 +4,5 @@ go-server-sdk.test
 allocations.out
 .idea
 .vscode
+go.work
+go.work.sum

CONTRIBUTING.md

@@ -18,28 +18,39 @@ This project should be built against the lowest supported Go version as describe
 
 ### Building
 
-To build the SDK without running any tests:
-```
+To build all modules without running any tests:
+```shell
 make
 ```
 
-If you wish to clean your working directory between builds, you can clean it by running:
-```
-make clean
-```
-
 To run the linter:
-```
+```shell
 make lint
 ```
 
 ### Testing
 
-To build the SDK and run all unit tests:
-```
+To build all modules and run all unit tests:
+```shell
 make test
 ```
 
+### Clean
+
+To clean temporary files created by other targets:
+```shell
+make clean
+```
+
+### Working Cross Module
+
+If you have a change which affects more than a single module, then you can use a go workspace.
+
+You can create a workspace using:
+```shell
+make workspace
+```
+
 ## Coding best practices
 
 The Go SDK can be used in high-traffic application/service code where performance is critical. There are a number of coding principles to keep in mind for maximizing performance. The benchmarks that are run in CI are helpful in measuring the impact of code changes in this regard.

Makefile

@@ -4,6 +4,9 @@ GOLANGCI_LINT_VERSION=v1.57.1
 LINTER=./bin/golangci-lint
 LINTER_VERSION_FILE=./bin/.golangci-lint-version-$(GOLANGCI_LINT_VERSION)
 
+GO_WORK_FILE=go.work
+GO_WORK_SUM=go.work.sum
+
 TEST_BINARY=./go-server-sdk.test
 ALLOCATIONS_LOG=./build/allocations.out
 
@@ -20,22 +23,59 @@ COVERAGE_ENFORCER_FLAGS=-package github.com/launchdarkly/go-server-sdk/v7 \
 	-skipcode "// COVERAGE" \
 	-packagestats -filestats -showcode
 
-.PHONY: build clean test test-coverage benchmarks benchmark-allocs lint
+ALL_BUILD_TARGETS=sdk ldotel
+ALL_TEST_TARGETS = $(addsuffix -test, $(ALL_BUILD_TARGETS))
+ALL_LINT_TARGETS = $(addsuffix -lint, $(ALL_BUILD_TARGETS))
 
-build:
-	go build ./...
+.PHONY: all build clean test test-coverage benchmarks benchmark-allocs lint workspace workspace-clean $(ALL_BUILD_TARGETS) $(ALL_TEST_TARGETS) $(ALL_LINT_TARGETS)
+
+all: $(ALL_BUILD_TARGETS)
+
+test: $(ALL_TEST_TARGETS)
 
-clean:
-	go clean
+clean: workspace-clean
+	rm -rf ./bin/
 
-test:
-	go test -run=not-a-real-test ./...  # just ensures that the tests compile
+sdk:
+	go build ./...
+
+sdk-test:
 	go test -v -race ./...
 	@# The proxy tests must be run separately because Go caches the global proxy environment variables. We use
 	@# build tags to isolate these tests from the main test run so that if you do "go test ./..." you won't
 	@# get unexpected errors.
 	for tag in proxytest1 proxytest2; do go test -race -v -tags=$$tag ./proxytest; done
 
+sdk-lint:
+	$(LINTER) run ./...
+
+ldotel:
+	@if [ -f go.work ]; then \
+  		echo "Building ldotel with workspace" \
+		go build ./ldotel; \
+	else \
+		echo "Building ldotel without workspace" \
+		cd ldotel && go build .; \
+	fi
+
+ldotel-test:
+	@if [ -f go.work ]; then \
+		echo "Testing ldotel with workspace" \
+		go test -v -race ./ldotel; \
+	else \
+		echo "Testing ldotel without workspace" \
+		cd ldotel && go test -v -race .; \
+	fi
+
+ldotel-lint:
+	@if [ -f go.work ]; then \
+		echo "Linting ldotel with workspace" \
+		$(LINTER) run ./ldotel; \
+	else \
+		echo "Linting ldotel without workspace" \
+		cd ldotel && 	$(LINTER) run .; \
+	fi
+
 test-coverage: $(COVERAGE_PROFILE_RAW)
 	go run github.com/launchdarkly-labs/go-coverage-enforcer@latest $(COVERAGE_ENFORCER_FLAGS) -outprofile $(COVERAGE_PROFILE_FILTERED) $(COVERAGE_PROFILE_RAW)
 	go tool cover -html $(COVERAGE_PROFILE_FILTERED) -o $(COVERAGE_PROFILE_FILTERED_HTML)
@@ -70,17 +110,25 @@ $(LINTER_VERSION_FILE):
 	curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s $(GOLANGCI_LINT_VERSION)
 	touch $(LINTER_VERSION_FILE)
 
-lint: $(LINTER_VERSION_FILE)
-	$(LINTER) run ./...
-
+lint: $(LINTER_VERSION_FILE) $(ALL_LINT_TARGETS)
 
 TEMP_TEST_OUTPUT=/tmp/sdk-contract-test-service.log
 
 # TEST_HARNESS_PARAMS can be set to add -skip parameters for any contract tests that cannot yet pass
 TEST_HARNESS_PARAMS=
 
+workspace: go.work
+
+go.work:
+	go work init ./
+	go work use ./ldotel
+	go work use ./testservice
+
+workspace-clean:
+	rm -f $(GO_WORK_FILE) $(GO_WORK_SUM)
+
 build-contract-tests:
-	@cd testservice && go mod tidy && go build
+	@go build -o ./testservice/testservice ./testservice
 
 start-contract-test-service: build-contract-tests
 	@./testservice/testservice

ldotel/README.md

@@ -0,0 +1,54 @@
+LaunchDarkly Server-side OTEL library for Go
+==============================================
+[![Actions Status](https://github.com/launchdarkly/go-server-sdk/actions/workflows/ldotel-ci.yml/badge.svg?branch=v7)](https://github.com/launchdarkly/go-server-sdk/actions/workflows/ci.yml)
+
+LaunchDarkly overview
+-------------------------
+[LaunchDarkly](https://www.launchdarkly.com) is a feature management platform that serves trillions of feature flags daily to help teams build better software, faster. [Get started](https://docs.launchdarkly.com/home/getting-started) using LaunchDarkly today!
+
+[![Twitter Follow](https://img.shields.io/twitter/follow/launchdarkly.svg?style=social&label=Follow&maxAge=2592000)](https://twitter.com/intent/follow?screen_name=launchdarkly)
+
+Getting started
+-----------
+
+Import the module:
+
+```go
+import (
+    "github.com/launchdarkly/go-server-sdk/ldotel"
+)
+```
+
+Configure the LaunchDarkly client to use a tracing hook:
+
+```go
+client, _ = ld.MakeCustomClient("your-sdk-key",
+ld.Config{
+    Hooks: []ldhooks.Hook{ldotel.NewTracingHook()},
+}, 5*time.Second)
+```
+
+Learn more
+-----------
+
+Read our [documentation](http://docs.launchdarkly.com) for in-depth instructions on configuring and using LaunchDarkly.
+
+Contributing
+------------
+
+We encourage pull requests and other contributions from the community. Check out our [contributing guidelines](CONTRIBUTING.md) for instructions on how to contribute to this library.
+
+About LaunchDarkly
+-----------
+
+* LaunchDarkly is a continuous delivery platform that provides feature flags as a service and allows developers to iterate quickly and safely. We allow you to easily flag your features and manage them from the LaunchDarkly dashboard.  With LaunchDarkly, you can:
+    * Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
+    * Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
+    * Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
+    * Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.
+* LaunchDarkly provides feature flag SDKs for a wide variety of languages and technologies. Read [our documentation](https://docs.launchdarkly.com/sdk) for a complete list.
+* Explore LaunchDarkly
+    * [launchdarkly.com](https://www.launchdarkly.com/ "LaunchDarkly Main Website") for more information
+    * [docs.launchdarkly.com](https://docs.launchdarkly.com/  "LaunchDarkly Documentation") for our documentation and SDK reference guides
+    * [apidocs.launchdarkly.com](https://apidocs.launchdarkly.com/  "LaunchDarkly API Documentation") for our API documentation
+    * [blog.launchdarkly.com](https://blog.launchdarkly.com/  "LaunchDarkly Blog Documentation") for the latest product updates