Fix duplicate checkout action in GitHub workflow #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…still read the response body. (open-telemetry#1328) * chore(zipkin-exporter): relay on the status code for the request but still read the response body. * fix(zipkin-exporter): fix tests. * chore(zipkin-exporter): adds changelog. * chore: 202 -> http.StatusAccepted Co-authored-by: Chris Bandy <bandy.chris@gmail.com> * chore: 202 -> http.StatusAccepted Co-authored-by: Anthony Mirabella <a9@aneurysm9.com> Co-authored-by: Chris Bandy <bandy.chris@gmail.com> Co-authored-by: Anthony Mirabella <a9@aneurysm9.com> Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Rework proto generation The changes here are: - Fix the default goal (using "default" target is not doing it). - Bail out with a useful message if proto submodule is not checked out. - Replace the use of docker image with downloading the protoc binary and building the gogofast plugin ourselves. This gives us a greater control over the invocation of protoc. - Use rsync to copy the generated code, instead of pax. Pax did not work for me (it was complaining about the unknown -0 flag). The control over the protoc invocation will be useful later, when we will want to generate a code with data structures in one place and the collector code elsewhere. The collector code may or may not depend on gRPC, but data structures have no need for it. This split will happen when we move the gRPC code out of the OTLP exporter module into a submodule. Getting rid of docker has the upside that the generated files do not belong to root, so there is no hassle of changing the ownership of the files, and it is not requires to use sudo for the `clean` target. And not using docker is faster. The downside of this work is that it depends on more tools: rsync, unzip and wget. I can only hope that macOS users have those tools too, and that those tools are invoked the same. * Update protogen workflow
) * Enable support for externally-defined ID generators * Moved the SDK's `internal.IDGenerator` interface to the `sdk/trace` package. * Added `trace.WithIDGenerator()` `TracerProviderOption`. Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Update CHANGELOG.md with PR info * Address PR feedback: * Fix IDGenerator godoc comment * rename type defaultIDGenerator to randomIDGenerator * rename defIDGenerator() to defaultIDGenerator() Signed-off-by: Anthony J Mirabella <a9@aneurysm9.com> * Rework trace.IDGenerator interface * NewTraceID() -> NewIDs(ctx) ** Returns both TraceID and SpanID * NewSpanID() -> NewSpanID(ctx, traceID) ** Returns only SpanID, has access to TraceID * Both methods now receive a context, from which they may extract information * startSpanInternal() updated to receive a context to pass to the ID generator * Drop outdated comment from docblock Co-authored-by: Krzesimir Nowak <qdlacz@gmail.com> Co-authored-by: Krzesimir Nowak <qdlacz@gmail.com>
* Let SynchronizedMove(nil) reset and discard * Add common test for SynchronizedMove(nil) * End-to-end test for the Processor and SumObserver * Implement SynchronizedMove(nil) six ways * Lint * Changelog * Test no reset for wrong aggregator type; Fix four Aggregators * Cleanup * imports Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Fix typo Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Store span data directly in the span
- Nesting only some of a span's data in a `data` field (with the rest
of the data living direclty in the `span` struct) is confusing.
- export.SpanData is meant to be an immutable *snapshot* of a span,
not the "authoritative" state of the span.
- Refactor attributesMap.toSpanData into toKeyValue and make it
return a []label.KeyValue which is clearer than modifying a struct
passed to the function.
- Read droppedCount from the attributesMap as a separate operation
instead of setting it from within attributesMap.toSpanData.
- Set a span's end time in the span itself rather than in the
SpanData to allow reading the span's end time after a span has
ended.
- Set a span's end time as soon as possible within span.End so that
we don't influence the span's end time with operations such as
fetching span processors and generating span data.
- Remove error handling for uninitialized spans. This check seems to
be necessary only because we used to have an *export.SpanData field
which could be nil. Now that we no longer have this field I think we
can safely remove the check. The error isn't used anywhere else so
remove it, too.
* Store parent as trace.SpanContext
The spec requires that the parent field of a Span be a Span, a
SpanContext or null.
Rather than extracting the parent's span ID from the trace.SpanContext
which we get from the tracer, store the trace.SpanContext as is and
explicitly extract the parent's span ID where necessary.
* Add ReadOnlySpan interface
Use this interface instead of export.SpanData in places where reading
information from a span is necessary. Use export.SpanData only when
exporting spans.
* Add ReadWriteSpan interface
Use this interface instead of export.SpanData in places where it is
necessary to read information from a span and write to it at the same
time.
* Rename export.SpanData to SpanSnapshot
SpanSnapshot represents the nature of this type as well as its
intended use more accurately.
Clarify the purpose of SpanSnapshot in the docs and emphasize what
should and should not be done with it.
* Rephrase attributesMap doc comment
"refreshes" is wrong for plural ("updates").
* Refactor span.End()
- Improve accuracy of span duration. Record span end time ASAP. We
want to measure a user operation as accurately as possible, which
means we want to mark the end time of a span as soon as possible
after span.End() is called. Any operations we do inside span.End()
before storing the end time affect the total duration of the span,
and although these operations are rather fast at the moment they
still seem to affect the duration of the span by "artificially"
adding time between the start and end timestamps. This is relevant
only in cases where the end time isn't explicitly specified.
- Remove redundant idempotence check. Now that IsRecording() is based
on the value of span.endTime, IsRecording() will always return
false after span.End() had been called because span.endTime won't
be zero. This means we no longer need span.endOnce.
- Improve TestEndSpanTwice so that it also ensures subsequent calls
to span.End() don't modify the span's end time.
* Update changelog
Co-authored-by: Tyler Yahn <codingalias@gmail.com>
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* Call otel.Handle with non-nil errors That's what normally happens in other call sites. Those two didn't check it, but passed the "error" to Handle. The default, delegating implementation of ErrorHandler was printing the error unconditionally, which resulted in pointless lines like `2020/12/07 19:51:28 <nil>` in demos, for example. * Add tests Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
…pen-telemetry#1396) * Bump google.golang.org/grpc from 1.32.0 to 1.34.0 in /exporters/otlp Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.32.0 to 1.34.0. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](grpc/grpc-go@v1.32.0...v1.34.0) Signed-off-by: dependabot[bot] <support@github.com> * Auto-fix go.sum changes in dependent modules Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: dependabot[bot] <dependabot[bot]@users.noreply.github.com>
…rters/metric/prometheus (open-telemetry#1397) * Bump github.com/prometheus/client_golang in /exporters/metric/prometheus Bumps [github.com/prometheus/client_golang](https://github.com/prometheus/client_golang) from 1.7.1 to 1.8.0. - [Release notes](https://github.com/prometheus/client_golang/releases) - [Changelog](https://github.com/prometheus/client_golang/blob/master/CHANGELOG.md) - [Commits](prometheus/client_golang@v1.7.1...v1.8.0) Signed-off-by: dependabot[bot] <support@github.com> * Auto-fix go.sum changes in dependent modules Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: dependabot[bot] <dependabot[bot]@users.noreply.github.com> Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
…jaeger (open-telemetry#1398) * Bump google.golang.org/api in /exporters/trace/jaeger Bumps [google.golang.org/api](https://github.com/googleapis/google-api-go-client) from 0.32.0 to 0.36.0. - [Release notes](https://github.com/googleapis/google-api-go-client/releases) - [Changelog](https://github.com/googleapis/google-api-go-client/blob/master/CHANGES.md) - [Commits](googleapis/google-api-go-client@v0.32.0...v0.36.0) Signed-off-by: dependabot[bot] <support@github.com> * Auto-fix go.sum changes in dependent modules Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: dependabot[bot] <dependabot[bot]@users.noreply.github.com> Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
…llector (open-telemetry#1400) * Bump google.golang.org/grpc in /example/otel-collector Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.32.0 to 1.34.0. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](grpc/grpc-go@v1.32.0...v1.34.0) Signed-off-by: dependabot[bot] <support@github.com> * Auto-fix go.sum changes in dependent modules Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: dependabot[bot] <dependabot[bot]@users.noreply.github.com> Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
* migrating CircleCI jobs to GitHub Actions * using container matrix instead * prevent entire workflow from stopping if one go version job fails * updating github ci to use setup-go * updating changelog
Remove duplicate strategy that is causing an error.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to open-telemetry#880, when copying over the
setup-gochanges I accidentally included checkout twice :(