Skip to content

make debug exporter available for custom builds #1551

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

Merged
merged 1 commit into from
Oct 21, 2024

Conversation

its-felix
Copy link
Contributor

This PR makes the debug exporter available for customized builds (#1427).

The debug exporter was added to default in #1520

@its-felix its-felix requested a review from a team as a code owner October 8, 2024 14:24
@its-felix
Copy link
Contributor Author

its-felix commented Oct 9, 2024

Just sharing a thought:

If you decide to move this out of experimental eventually, we could make use of this for both the default and custom build, by including the default components without any additional build tag, i.e.:

Component included in default build (no tags provided) - available either if lambdacomponents.custom is not present or explicitly included:

//go:build !lambdacomponents.custom || lambdacomponents.all || lambdacomponents.exporter.all || lambdacomponents.exporter.debug

Component only available for custom builds - available only if explicitly included:

//go:build lambdacomponents.custom && (lambdacomponents.all || lambdacomponents.exporter.all || lambdacomponents.exporter.debug)

Also, if (emphasis on if) you decide to move this out of experimental, a CI build with BUILDTAGS="lambdacomponents.custom,lambdacomponents.all should be included to ensure these builds succeed

// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The convention in collector-contrib is to simply use...

// Copyright The OpenTelemetry Authors
// SPDX-License-Identifier: Apache-2.0

Although the convention differs in this repo, I think it's innocuous migration that would be worthwhile. Since the convention here differs I'm not suggesting this PR has to be the place where we would migrate. And I'm certainly open to other reasoning.

The benefit in this case would be almost a 50% reduction in the line scan requirement for reviewers and other readers. To my brain that matters. It's also nicer to see that someone has requested a review on 50% fewer lines, when 1/2 of that is skimming over license detail.

To be clear, I'm approving as is in keeping with current practice here. And defer to consensus on whether and when we would migrate.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I support switching to the shorter format. How do we standardize that here?

@nslaughter
Copy link
Contributor

Should we remove the custom build support for the logging exporter?

@its-felix
Copy link
Contributor Author

Should we remove the custom build support for the logging exporter?

I think it should stay as long as it stays in default too

@tylerbenson tylerbenson merged commit 4d1e38d into open-telemetry:main Oct 21, 2024
12 checks passed
@tylerbenson tylerbenson added the go Pull requests that update Go code label Oct 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
go Pull requests that update Go code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants