-
Notifications
You must be signed in to change notification settings - Fork 216
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
Feat add metrics #256
Feat add metrics #256
Conversation
Co-authored-by: Matt Fellows <matt.fellows@onegeek.com.au>
lib/pact/utils/metrics.rb
Outdated
|
||
if track_events? | ||
Pact.configuration.output_stream.puts "WARN: Please note: we are tracking events anonymously to gather important usage statistics like Pact-Ruby version | ||
and operating system. To disable tracking, set the 'pact_do_not_track' environment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upper case PACT_DO_NOT_TRACK
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other implementations have followed the original Pact.js implementation, which uses a lower case environment variable name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I think you've misread the code. In Pact Node, you can set the pact_do_not_track
config item (i.e. npm config set pact_do_not_track true or in package.json
).
We still support the env var PACT_DO_NOT_TRACK
also, see https://github.com/pact-foundation/pact-js-core/blob/pact-node/standalone/install.ts#L85.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, in that case we need to change the other implementations. Probably best to make it case-insensitive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, for clarity, Upper case PACT_DO_NOT_TRACK
is what we want for consistency (including the warning). We can update rust later.
lib/pact/utils/metrics.rb
Outdated
"av" => Pact::VERSION, | ||
"aid" => "pact-ruby", | ||
"aip" => 1, | ||
"ds" => ENV["CI"] || "unknown", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ENV["CI"]
will eq 'true'. You need this to return "ci" if ENV["CI"] == 'true'
.
lib/pact/utils/metrics.rb
Outdated
"aid" => "pact-ruby", | ||
"aip" => 1, | ||
"ds" => ENV["CI"] || "unknown", | ||
"cd2" => ENV['PACT_EXECUTING_LANGUAGE'] ? "client" : "unknown", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is cd2? I think this will always be 'client'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I think what's happened is I have mixed up the 'ds' field and 'cd2' field.
ds should be one of: client, cli, broker
while cd2 should be "One of: CI, development, unknown"
For cd2 Ron suggested it should be "CI" if the CI env var is set or otherwise "unknown". If that sounds good I'll fix up these 2 fields
lib/pact/utils/metrics.rb
Outdated
"cd2" => ENV['PACT_EXECUTING_LANGUAGE'] ? "client" : "unknown", | ||
"cd3" => RUBY_PLATFORM, | ||
"cd6" => ENV['PACT_EXECUTING_LANGUAGE'] || "unknown", | ||
"cd7" => RUBY_VERSION, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we only want to use the ruby version if the executing language is Ruby.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when it's not ruby would we just leave this blank?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should get it from the wrapping language implementation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So perhaps ENV['PACT_EXECUTING_LANGUAGE_VERSION']?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats seems sensible to me!
The next thing we need to do is make this call interrupt the user as little as possible. We want to keep the connection and request timeouts very small. Some reading: Do you think it's worth using a thread to make sure it's non blocking @uglyog? How have you implemented it in other languages? |
We also need to make sure any exception that gets thrown does not impact or get shown to the user. |
I've implemented it as a background thread in other places |
Cool. This looks straightforward https://www.rubyguides.com/2015/07/ruby-threads/ |
Unlike the mock service, this one is reporting at the end of the event, and it's possible that the ruby process will have shut down before the http request is completed. I think we should either call it before the test is run, so it can have lots of time to make the http call, or we need to do a thread.join to ensure it's finished before the tests shut down. |
As mentioned here, I think we should not implement this change.
If we do bring in a change like this, I think it should be opt-in by default - as that's the trend (and in my view best-behaviour) these days anyway. I created pact-foundation/pact-js-core#360 to track this for pact-js. Critically, I think the GDPR is relevant here, too - as it means that we're gaining access to information that is already stored on the user's machine that could be used in the process of identifying them (and isn't required for the operation of the service, which means the exception doesn't apply). This means it must be opt-in. There's some discussion on stack exchange here (although it's about local storage, the discussion is relevant). |
@TimothyJones I understand your concern, rather than duplicating responses, I'll refer to https://github.com/pact-foundation/pact-js-core/pull/359#issuecomment-1027529629] which sums up the thinking so future readers will know where to look. |
Confirming the telemetry docs page is now live and shared with maintainers, who have given it the 👍 . |
lib/pact/utils/metrics.rb
Outdated
|
||
def self.handle_error e | ||
if ENV['PACT_METRICS_DEBUG'] == 'true' | ||
Pact.configuration.output_stream.puts("DEBUG: #{e.inspect}") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
e.inspect doesn't include the backtrace. Can you make this
Pact.configuration.output_stream.puts("DEBUG: #{e.inspect}\n" + e.backtrace.join("\n"))
|
||
private | ||
|
||
def self.handle_error e |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indentation is a bit off here.
The upgrade to pact 1.62.0 includes pact-foundation/pact-ruby#256 which adds telemetry[[1]] for the package maintainers. Set the `PACT_DO_NOT_TRACK` environment variable which opts out of sending this telemetry. [1]: https://docs.pact.io/telemetry/
Pact have recently added tracking to their project which will result in data sent from our build servers to their servers [1]. I'm not sure if we have a collective opinion on whether we're happy with this or not, so it seems simplest to disable it and save the need for a divisive decision. [1]: pact-foundation/pact-ruby#256
Pact have recently added tracking to their project which will result in data sent from our build servers to their servers [1]. I'm not sure if we have a collective opinion on whether we're happy with this or not, so it seems simplest to disable it and save the need for a divisive decision. [1]: pact-foundation/pact-ruby#256
Pact have recently added tracking to their project which will result in data sent from our build servers to their servers [1]. I'm not sure if we have a collective opinion on whether we're happy with this or not, so it seems simplest to disable it and save the need for a divisive decision. It also gets rid of an annoying warning. [1]: pact-foundation/pact-ruby#256
The purpose of this PR is to add code that can be used to push metrics from pact-ruby to google analytics.
The PR adds event tracking for when pact verification has completed. The code supports users turning off this tracking by setting the env var PACT_DO_NOT_TRACK to 'true'.