-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Fix average functions duration calculation in metrics output #3067
Fix average functions duration calculation in metrics output #3067
Conversation
Thank you very much @vladgolubev you rock 🎸 ! Awesome PR description! 👍 We'll look into it ASAP! |
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.
Really, really good refactoring!
Nicely done @vladgolubev love it (I always love it when more code is removed rather than added) 🥇 👍
I added 2 minor comments. Usually it's better to have function based PRs (so in this case one PR for the refactoring of the metrics plugin, one for awsProvider
, one for configCredentials
etc. which makes the PR easier to review and also easier to track down specific PRs when they introduce bugs) but these changes are not that major so it's fine to merge them here as well.
Again great job @vladgolubev GTM from my side once the comments are discussed / resolved 👍
@@ -182,6 +182,10 @@ class Service { | |||
return Object.keys(this.functions); | |||
} | |||
|
|||
getAllFunctionsNames() { |
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.
This should be covered by a test.
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.
Of course, thanks @pmuens, just pushed the changes
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.
Thanks!
(env.HOMEPATH ? ((env.HOMEDRIVE || 'C:/') + env.HOMEPATH) : null); | ||
|
||
if (!home) { | ||
if (!os.homedir()) { |
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.
is os.homedir()
also safe for old Node versions?
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.
Here's the list of Node versions we "officially" support:
Lines 5 to 8 in 53c9608
- node_js: '4.4' | |
- node_js: '5.11' | |
- node_js: '6.2' | |
- node_js: '6.2' |
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.
Hm, added in v2.3.0 - means safe.
My reasoning was, that I noticed that unit tests are using os.homedir()
but the code not. After git blame
found out it was because after refactoring project structure file was just copy pasted, and tests were written after by a different person. So just minor inconsistency.
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.
Yep. That totally makes sense.
I copied the code for the homedir detection from an old PR and pushed the test on top of that 😬. But yes, if the test use os.homedir and work for all node versions on our CI system, then the usage of os.homedir
should work in the main code as well 😆 🤦♂️
@pmuens thanks for the review and feedback! Sorry for absence, I'm back here )
I strongly agree for that!! But with this PR the story was a bit different. When you released metrics support in some of the recent releases, I, was impressed. So I went to the sources to read the implementation. After reading, I created a note to myself to refactor that file, as it's a great functionality, but no so readable as I could wish. So I started refactoring it at that time, and after unit tests, I moved to testing it with my AWS account. And at that time I realised that outputs differ from my local sls branch and what is published to npm. So I started digging into it to find where is my bug. But in the end, it occurred on contrary - my refactoring fixed a bug I didn't have an idea about. So, refactoring without any purpose resulted in a bug fix. Of course, afterwards I could fix couple of lines in the old code knowing the reason, and submit a new PR with just a refactoring, buuut, this didn't happen, it wasn't already so interesting for me, so all I can say to forgive me |
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.
Thanks for the update @vladgolubev 👍
Just gave it another spin and it works as expected. 💯
so all I can say to forgive me
No hard feelings! We love the stuff you do you so keep up the great work 🥇 👍
@@ -182,6 +182,10 @@ class Service { | |||
return Object.keys(this.functions); | |||
} | |||
|
|||
getAllFunctionsNames() { |
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.
Thanks!
(env.HOMEPATH ? ((env.HOMEDRIVE || 'C:/') + env.HOMEPATH) : null); | ||
|
||
if (!home) { | ||
if (!os.homedir()) { |
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.
Yep. That totally makes sense.
I copied the code for the homedir detection from an old PR and pushed the test on top of that 😬. But yes, if the test use os.homedir and work for all node versions on our CI system, then the usage of os.homedir
should work in the main code as well 😆 🤦♂️
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.
@vladgolubev I love how extensive your lodash usage is! ❤️ It helps refactor tons of LOCs
Approved!
return _.get(this, 'options.region') | ||
|| _.get(this, 'serverless.config.region') | ||
|| _.get(this, 'serverless.service.provider.region') | ||
|| defaultRegion; |
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.
Nice!
const invocationsCount = _.sumBy(getDatapointsByLabel('Invocations'), 'Sum'); | ||
const throttlesCount = _.sumBy(getDatapointsByLabel('Throttles'), 'Sum'); | ||
const errorsCount = _.sumBy(getDatapointsByLabel('Errors'), 'Sum'); | ||
const durationAverage = _.meanBy(getDatapointsByLabel('Duration'), 'Average') || 0; |
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 did you implement:
Closes #3066 + refactoring of AWS Metrics plugin
How did you implement it:
Before:
Previously it was summing durations from each day and dividing it by number of Lambda functions, instead of number of data points from CloudWatch.
After:
Also refactored some code to increase readability (I hope) and "code churn" metric 😅 I was careful and all the tests are still passing, so should be ok.
How can we verify it:
This can be verified by:
should display correct average of service wide average function duration
Also I'm not sure whether the code coverage dropped or not. It dropped by statements, but increased by branches.
Todos:
Is this ready for review?: YES
Is it a breaking change?: NO