v0.7.4

What's Changed

• feat: support instrumentation of k8s.io/client-go by @rarguelloF in #185
• feat: support instrumentation of hashicorp/vault by @darccio in #189
• feat: add log/slog instrumentation by @nsrip-dd in #208
• feat: add continuous profiler instrumentation by @nsrip-dd in #178
• feat: orchestrion job server to reduce duplicated effort by @RomainMuller in #176
• perf: switch to regexp-less directive matching by @nsrip-dd in #212
• feat: support instrumentation of github.com/aws/aws-sdk-go/aws by @RomainMuller in #209
• feat: add profiling of Orchestrion by @nsrip-dd in #217
• fix: propagate --log-level and --log-file to child processes by @nsrip-dd in #224
• feat: support instrumentation of github.com/{Shopify,IBM}/sarama by @darccio in #216
• fix(goflags): using -cover causes fingerprint mismatch by @RomainMuller in #230
• fix: GLS slot not cleaned up after goroutine exits by @RomainMuller in #232
• fix: apply //dd:orchestrion-enabled to tracer-internal modules by @nsrip-dd in #223

New Contributors

• @rarguelloF made their first contribution in #185
• @eliottness made their first contribution in #158
• @github-actions made their first contribution in #226

Full Changelog: v0.7.3...v0.7.4

v0.7.4-rc.2

What's Changed

• feat: support instrumentation of hashicorp/vault by @darccio in #189

New Contributors

• @eliottness made their first contribution in #158

Full Changelog: v0.7.4-rc.1...v0.7.4-rc.2

v0.7.4-rc.1

What's Changed

• feat: support instrumentation of k8s.io/client-go by @rarguelloF in #185

New Contributors

• @rarguelloF made their first contribution in #185

Full Changelog: v0.7.3...v0.7.4-rc.1

v0.7.3

What's Changed

• fix: cannot lazily link against GLS accessors by @RomainMuller in #127
• feat: support instrumentation of go.mongodb.org/mongo-driver/mongo by @darccio in #164
• fix: go artifact cache may not be invalidated correctly by @RomainMuller in #166
• fix: injected imports conflict with local names by @RomainMuller in #177

New Contributors

• @Julio-Guerra made their first contribution in #162
• @nsrip-dd made their first contribution in #169

Full Changelog: v0.7.2...v0.7.3

v0.7.2

What's Changed

• fix: missing link.deps records cause link-time error by @RomainMuller in #125
• docs: initial documentation website work by @RomainMuller in #110
• chore: add unit test for autoPinOrchestrion / pinOrchestrion by @RomainMuller in #124
• fix: broken documentation site by @RomainMuller in #150

New Contributors

• @dependabot made their first contribution in #129

Full Changelog: v0.7.1...v0.7.2

v0.7.1

What's new

⚠️ Breaking Changes

This release of orchestrion is a major re-design: in order to improve the coverage achievable with Orchestrion, it moved from being a coding-time tool (where check-in instrumented code) to a build-time tool, moving the instrumentation code completely out of the way.

Migration from versions up to 0.6.0:

1. in order to avoid doubly-instrumented code, we strongly advise users of Orchestrion until version 0.6.0 to run orchestrion -rm . to remove any existing orchestrion-inserted code from their codebase before upgrading to Orchestrion 0.7.0 and greater.
2. once done, follow the installation instructions in the README file.

Highlights

Orchestrion now runs as a Go toolchain -toolexec tool, allowing it to instrument all Go code included in the final binary, including any and all transitive dependencies as well as the standard library; while only changing a single build command. This allows maximization of the profiling and application security coverage, without requiring any significant developer effort.

The instrumentation code remains out of the way so that developers can focus on building their product without having to worry about – or be distracted by – verbose instrumentation code.

Bug fixes

• Dot-imports result in instrumentation failure (#50)
• Cannot decorate multiple packages with the same apparent package name (#56)

Full Changelog: v0.6.0...v0.7.1

v0.7.0

What's new

⚠️ Breaking Changes

This release of orchestrion is a major re-design: in order to improve the coverage achievable with Orchestrion, it moved from being a coding-time tool (where check-in instrumented code) to a build-time tool, moving the instrumentation code completely out of the way.

Migration from versions up to 0.6.0:

1. in order to avoid doubly-instrumented code, we strongly advise users of Orchestrion until version 0.6.0 to run orchestrion -rm . to remove any existing orchestrion-inserted code from their codebase before upgrading to Orchestrion 0.7.0 and greater.
2. once done, follow the installation instructions in the README file.

Highlights

Orchestrion now runs as a Go toolchain -toolexec tool, allowing it to instrument all Go code included in the final binary, including any and all transitive dependencies as well as the standard library; while only changing a single build command. This allows maximization of the profiling and application security coverage, without requiring any significant developer effort.

The instrumentation code remains out of the way so that developers can focus on building their product without having to worry about – or be distracted by – verbose instrumentation code.

Bug fixes

• Dot-imports result in instrumentation failure (#50)
• Cannot decorate multiple packages with the same apparent package name (#56)

Full Changelog: v0.6.0...v0.7.0

v0.7.0-rc.1

What's new

⚠️ Breaking Changes

This release of orchestrion is a major re-design: in order to improve the coverage achievable with Orchestrion, it moved from being a coding-time tool (where check-in instrumented code) to a build-time tool, moving the instrumentation code completely out of the way.

Migration from versions up to 0.6.0:

1. in order to avoid doubly-instrumented code, we strongly advise users of Orchestrion until version 0.6.0 to run orchestrion -rm . to remove any existing orchestrion-inserted code from their codebase before upgrading to Orchestrion 0.7.0 and greater.
2. once done, follow the installation instructions in the README file.

Highlights

Orchestrion now runs as a Go toolchain -toolexec tool, allowing it to instrument all Go code included in the final binary, including any and all transitive dependencies as well as the standard library; while only changing a single build command. This allows maximization of the profiling and application security coverage, without requiring any significant developer effort.

The instrumentation code remains out of the way so that developers can focus on building their product without having to worry about – or be distracted by – verbose instrumentation code.

Known issues

• Constructor instrumentation may cause compilation errors when the instrumented function returns a different type (e.g: mux.NewRouter) #86

Bug fixes

• Dot-imports result in instrumentation failure (#50)
• Cannot decorate multiple packages with the same apparent package name (#56)

Full Changelog: v0.6.0...v0.7.0-dev.2

v0.7.0-dev.2

What's new

⚠️ Breaking Changes

This release of orchestrion is a major re-design: in order to improve the coverage achievable with Orchestrion, it moved from being a coding-time tool (where check-in instrumented code) to a build-time tool, moving the instrumentation code completely out of the way.

Migration from versions up to 0.6.0:

1. in order to avoid doubly-instrumented code, we strongly advise users of Orchestrion until version 0.6.0 to run orchestrion -rm . to remove any existing orchestrion-inserted code from their codebase before upgrading to Orchestrion 0.7.0 and greater.
2. once done, follow the installation instructions in the README file.

Highlights

Orchestrion now runs as a Go toolchain -toolexec tool, allowing it to instrument all Go code included in the final binary, including any and all transitive dependencies as well as the standard library; while only changing a single build command. This allows maximization of the profiling and application security coverage, without requiring any significant developer effort.

The instrumentation code remains out of the way so that developers can focus on building their product without having to worry about – or be distracted by – verbose instrumentation code.

Known issues

• Constructor instrumentation may cause compilation errors when the instrumented function returns a different type (e.g: mux.NewRouter) #86

Bug fixes

• Dot-imports result in instrumentation failure (#50)
• Cannot decorate multiple packages with the same apparent package name (#56)

Full Changelog: v0.6.0...v0.7.0-dev.2

v0.7.0-dev.1

What's new

⚠️ Breaking Changes

This release of orchestrion is a major re-design: in order to improve the coverage achievable with Orchestrion, it moved from being a coding-time tool (where check-in instrumented code) to a build-time tool, moving the instrumentation code completely out of the way.

Migration from versions up to 0.6.0:

1. in order to avoid doubly-instrumented code, we strongly advise users of Orchestrion until version 0.6.0 to run orchestrion -rm . to remove any existing orchestrion-inserted code from their codebase before upgrading to Orchestrion 0.7.0 and greater.
2. once done, follow the installation instructions in the README file.

Highlights

Orchestrion now runs as a Go toolchain -toolexec tool, allowing it to instrument all Go code included in the final binary, including any and all transitive dependencies as well as the standard library; while only changing a single build command. This allows maximization of the profiling and application security coverage, without requiring any significant developer effort.

The instrumentation code remains out of the way so that developers can focus on building their product without having to worry about – or be distracted by – verbose instrumentation code.

Known issues

• Constructor instrumentation may cause compilation errors when the instrumented function returns a different type (e.g: mux.NewRouter) #86

Bug fixes

• Dot-imports result in instrumentation failure (#50)
• Cannot decorate multiple packages with the same apparent package name (#56)

Full Changelog: v0.6.0...v0.7.0-rc.1