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

v0.6.0

What's Changed

• Add Fiber V2 support for automated tracing by @mlund01 in #55
• ci: fix ci and make it run on external contribs by @ahmed-mez in #58

New Contributors

• @mlund01 made their first contribution in #55

Full Changelog: v0.5.0...v0.6.0