README.md in rspec-trace-formatter-0.1.0 vs README.md in rspec-trace-formatter-0.2.0
- old
+ new
@@ -50,40 +50,62 @@
If you're running in an environment where this isn't supported (e.g. JRuby) you won't be able to use this.
However, the rest of this library is _expected_ to work for you, and [specifying an `--out` target for `RSpec::Trace::Formatter`](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/format-option) may make this easier.
## How Do I Use It?
+You can install this gem by adding the `rspec-trace-formatter` (along with the necessary OpenTelemetry dependencies, if they aren't already included) to your `Gemfile` and running `bundle install`.
+For example:
+
+```ruby
+group :test do
+ gem "rspec-trace-formatter"
+ gem "opentelemetry-api", "~> 1.0"
+ gem "opentelemetry-exporter-otlp", "~> 0.20.0"
+end
+```
+
This library should be used like [any other RSpec formatter](https://relishapp.com/rspec/rspec-core/v/3-10/docs/command-line/format-option), with the assistance of any environment variables that you need to control the OpenTelemetry data.
Example of using the `RSpec::Trace::OpenTelemetryFormatter` with representative environment variables set:
```bash
-OTEL_TRACES_EXPORTER=console bundle exec rspec --format RSpec::Trace::OpenTelemetryFormatter
+$ OTEL_TRACES_EXPORTER=console bundle exec rspec --format RSpec::Trace::OpenTelemetryFormatter
```
Example of running the `RSpec::Trace::Formatter` by itself and sending the output to `rspec-trace-consumer` separately (in a way that you can surely improve upon):
```bash
-OTEL_TRACES_EXPORTER=console bundle exec rspec --format RSpec::Trace::Formatter --out /tmp/trace-events.jsonl
+$ OTEL_TRACES_EXPORTER=console bundle exec rspec --format RSpec::Trace::Formatter --out /tmp/trace-events.jsonl
-rspec-trace-consumer < /tmp/trace-events.jsonl
+# Piping the input in
+$ rspec-trace-consumer < /tmp/trace-events.jsonl
+
+# Passing a filename as an argument
+$ rspec-trace-consumer /tmp/trace-events.jsonl
```
+If the `TRACEPARENT` environment variable is set in either of these cases, it will be interpreted as a [W3C Trace Context Traceparent Header value](https://www.w3.org/TR/trace-context/#traceparent-header).
+This will allow you to include the span events generated by this library in a larger distributed trace.
+
## How Do I Contribute?
Very carefully, I hope.
One notable fact is that we use [snapshot testing](https://github.com/levinmr/rspec-snapshot) for the class underpinning `rspec-trace-consumer`.
To keep this reliable, I've defined a custom OpenTelemetry span exporter that includes meaningful-enough data to test with and no execution-specific fields.
-## What's Coming Next?
+### Useful `rake` commands
-This does not yet support providing a [parent trace ID with an environment variable](https://github.com/open-telemetry/opentelemetry-specification/issues/740).
-I haven't done it yet because it's not very helpful to me given my primary use case, but I'll add that soon enough.
+* `rake build`: Build the gem
+* `rake install`: Builds and installs the gem
+* `rake regenerate_examples`: Rebuilds fixtures for snapshot tests
+* `rake test`: Runs the automated tests (written with RSpec, of course)
+* `rake update_snapshots`: Updates the test snapshots
-The fixtures for the snapshot tests for the `Consumer` class are currently system-specific insofar as the exception stack traces are built from real exceptions that include paths from the Ruby installation that generated them.
-Right now they come from my setup, so if anyone else regenerates the fixtures these paths will change.
-I believe that the ideal way to fix this is to provide a containerized development environment for which these paths can be fixed for everyone.
+### Containers
+
+Configuration for a [dev container](https://code.visualstudio.com/docs/remote/containers) is provided for convenience.
+The main practical benefit of developing in the container is to be able to regenerate the snapshots for the `Consumer` tests with consistent and non-identifying file paths for the stack traces.
## License
MIT