-
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
Add resource count and warning to info display #4822
Conversation
@alexdebrie Looks great on the visual/UI. As far as the implementation goes, it looks perfect. 👍 |
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.
@alexdebrie
Nice! The information and warning would be beneficial for many users!
I just added some comments for the implementation.
Cloud you confirm those?
lib/plugins/aws/info/display.js
Outdated
message += `${chalk.yellow('stack:')} ${info.stack}\n`; | ||
message += `${chalk.yellow('resources:')} ${info.resourceCount}`; | ||
|
||
if (info.resourceCount >= 150) { |
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.
Would be good to verify if it has the object key like this if (_.has(info, 'resourceCount') && info.resourceCount >= 150)
return this.provider.request('CloudFormation', | ||
'listStackResources', | ||
{ StackName: stackName }) | ||
.then((result) => { |
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.
You can write simpler like this .then(result => {
'listStackResources', | ||
{ StackName: stackName }) | ||
.then((result) => { | ||
if (result) { |
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.
Use lodash for consistency. if (!isEmpty(result)) {
outputs: [], | ||
}; | ||
|
||
return awsInfo.getResourceCount().then(() => { |
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.
Use chai-as-promised
style like this https://github.com/serverless/serverless/blob/master/lib/plugins/plugin/plugin.test.js
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.
@horike37 I don't quite understand this one. Which line is a good example in the plugin.test.js
?
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.
@alexdebrie
Please see this line. You can test if it returns fulfilled
or rejected
as a promise by using chai-as-promised
. Otherwise, you can't handle the test process if the current test is and returns rejected
.
https://github.com/serverless/serverless/blob/master/lib/plugins/plugin/plugin.test.js#L55
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.
@horike37 Thanks! I gave it a shot -- let me know if that's right 😄
outputs: [], | ||
}; | ||
|
||
return awsInfo.getResourceCount().then(() => { |
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.
Use chai-as-promised
style like this https://github.com/serverless/serverless/blob/master/lib/plugins/plugin/plugin.test.js
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.
@horike37 Same question as above
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, sorry. this is duplicate of the above comment, please ignore.
@alexdebrie I think the message may be unnecessary. What do you think? |
@horike37 Yea, I see what you're saying. The problem is this can't ever really be "resolved" for a user unless they remove resources. If they have more than 150 resources, they're in that danger zone of hitting the 200 resource limit. This limit is a pretty common problem, so we'd like to give users a heads up before they run directly into it without warning. Open to other thoughts on how to surface this for users while also not being annoying to others. cc @HyperBrain @brianneisler |
@alexdebrie What about restricting the warning to verbose mode only?
Then it is hidden during normal installs and users can get the warning additionally to other detailed output. Maybe at some threshold it can be even emitted without verbose mode enabled, like something above 190, because then every new resource added is likely to break the deployment. |
@HyperBrain To me, the biggest point of this is to provide helpful guidance to less-experienced users before they hit the wall head on. I'm guessing the less-experienced users won't be using verbose mode as often, and 190+ resources seems pretty late to start warning them. How big of an annoyance is the additional warning message? I feel like it's a pretty small subset of users that:
But maybe I'm misjudging that 😄 |
In regards to new users, it seems fair to emit the warning to let them know. I'm also fine to have the warning unconditionally for now 😄 A further improvement would then be to add log levels to the cli in general and put this "warning" into an "info" level. By default Serverless would show everything (error, warning and info) and thus show the warning for users that are new or unexperienced. More experienced users could then restrict the levels to "error" and/or "warning" by a config property or switch and would not see it. I think with such a level implementation everyone can be happy. |
@HyperBrain Agreed! That would be a good solution 😄 |
My first thought about it was to allow to add some kind of settings in the serverless.yml in order to hide such messages, that way people would get the warning and if it gets annoying they can just disable it through the serverless.yml file. But logging level works too, as long as it's displayed by default because that's too sensitive to be hidden by default. |
Logging levels are imo better, because settings in serverless.yml are service configuration settings. The output of warning messages is more a Serverless CLI setting than a service/project setting. |
I restarted the Travis build (had a hang). However, I'm not allowed to restart the appveyor build 🤔 . @pmuens Can you give me some rights there? |
@HyperBrain I actually agree, it has nothing to do with the serverless.yml indeed. It was just my first thought, but logging level makes more sense. |
This is a great feature! I'm sad to see this hasn't gotten much attention for a while. Is this still going places? |
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 looks great! Thanks @alexdebrie 👍
Nice feature which can be really helpful! I just looked through the code and it's almost GTM. Just added one comment regarding a removed restoring of a stub. Other than that I think it should be GTM
lib/plugins/aws/info/index.test.js
Outdated
@@ -52,7 +55,7 @@ describe('AwsInfo', () => { | |||
|
|||
afterEach(() => { | |||
awsInfo.validate.restore(); | |||
awsInfo.getStackInfo.restore(); |
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 happened to getStackInfo
here? Shouldn't we restore
it as well since I see the corresponding stub above 🤔
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.
Good catch, @pmuens ! I have no idea why I did that, so I added it back. 😄
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.
A very belated "thank you" @alexdebrie 😄
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 updating @alexdebrie 👍
And +100 for the descriptive commit message "Restore the missing restore "
👌 😂
This feature is super nifty. Just gave it a spin and it works great!
What did you implement:
This PR does two things:
resources:
indication that shows the number of resources in the CloudFormation stack:Hat tip to @Vadorequest for this idea initially. I thought it was a great idea. 💥 .
I'll update the tests as needed but want to make sure we're good on the visuals first. Once those are settled, I'll make sure the tests pass.
How did you implement it:
As part of the
aws:info:gatherData
hook, I make alistStackResources
API call for the CloudFormation stack and add it to thegatheredData
object. Then I print it out in thedisplayServiceInfo()
method.How can we verify it:
Run
sls info
in a deployed service. It should showresources:
in the info. Similarly, it should show in the Service Information block after a deploy.If you want to test the warning, set up a service with 30 HTTP functions and deploy it. It should display a warning.
Todos:
Is this ready for review?: NO
Is it a breaking change?: NO