Skip to content
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

CLI: doctor command #10115

Merged
merged 7 commits into from Oct 20, 2021
Merged

CLI: doctor command #10115

merged 7 commits into from Oct 20, 2021

Conversation

medikoo
Copy link
Contributor

@medikoo medikoo commented Oct 19, 2021

Addresses #9860

doctor command implementation, dedicated to print details on deprecations as triggered by previous command.
As this command is dedicated for modern logs, it's configured now to be hidden in help, and no mention in documentation is added (it'll be in v3 branch)

Addoitionally:

  • Fix command validation for not service related commands. It appears that modern validation was not triggered for commands which do no support service at any level (just basic old internally triggered validation was happening)

Not clear at this point why such filter was added.
It's harmful for commands configured externally of `Serverless` class
@codecov
Copy link

codecov bot commented Oct 19, 2021

Codecov Report

Merging #10115 (37e22b9) into master (cfd828e) will increase coverage by 0.08%.
The diff coverage is 97.82%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master   #10115      +/-   ##
==========================================
+ Coverage   85.26%   85.35%   +0.08%     
==========================================
  Files         334      337       +3     
  Lines       13640    13721      +81     
==========================================
+ Hits        11630    11711      +81     
  Misses       2010     2010              
Impacted Files Coverage Δ
lib/cli/handle-error.js 81.08% <ø> (-3.77%) ⬇️
commands/doctor.js 90.90% <90.90%> (ø)
lib/cli/commands-schema/no-service.js 100.00% <100.00%> (ø)
lib/cli/render-help/general.js 98.11% <100.00%> (ø)
lib/utils/health-status-filename.js 100.00% <100.00%> (ø)
lib/utils/logDeprecation.js 100.00% <100.00%> (+5.47%) ⬆️
scripts/serverless.js 56.69% <100.00%> (+0.62%) ⬆️
lib/classes/PluginManager.js 91.03% <0.00%> (-0.29%) ⬇️
lib/plugins/aws/package/compile/events/rabbitmq.js 100.00% <0.00%> (ø)
... and 4 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cfd828e...37e22b9. Read the comment docs.

@medikoo medikoo requested review from pgrzesik and removed request for pgrzesik October 19, 2021 16:36
Copy link
Contributor

@mnapoli mnapoli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 🎉

Just tested, that's awesome!

I added minor suggestions for wording, and noted one detail: if I run the command twice it "forgets" the previous deprecations, which was surprising. For example:

image

Would it make sense that sls doctor doesn't clear the list of deprecations? So that I can run sls doctor several times and get the same result.

lib/utils/logDeprecation.js Outdated Show resolved Hide resolved
commands/doctor.js Outdated Show resolved Hide resolved
@medikoo
Copy link
Contributor Author

medikoo commented Oct 19, 2021

Would it make sense that sls doctor doesn't clear the list of deprecations? So that I can run sls doctor several times and get the same result.

@mnapoli it's a bit tricky, as doctor is also a command, and also can trigger deprecations on its own (e.g. if deprecated Node.js version is used). I wouldn't complicate that contract.

sls doctor displays info on eventual deprecations reported by last sls .. usage. That feels very simple and clear

@mnapoli
Copy link
Contributor

mnapoli commented Oct 19, 2021

👍 understood

pgrzesik
pgrzesik previously approved these changes Oct 19, 2021
Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great 👏 I have one question, but it's more out of curiosity about your reasoning.

const path = require('path');
const os = require('os');

module.exports = path.resolve(os.homedir(), '.serverless/last-command-health-status');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a particular reason to introduce a new file for tracking this instead of using .serverlessrc for example? We're already tracking there information such as shownNotificationsHistory

Copy link
Contributor Author

@medikoo medikoo Oct 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pgrzesik very good question. I was leaning towards that at first, but then I thought it'll be a bit dirty. serverlessrc is about user configuration, while here we're storing the output of a command to eventually be run afterwards, also this output can be long.

So there are two factors that directed me to approach as implemented:

  • Output can be large, and will be quite noisy when you inspect user configuration, also rewriting this JSON file constantly, with now much larger content, felt not that optimal.
  • This output is not really a configuration data.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, I agree with the reasoning here and it sounds to me like a good call 👍

Copy link
Contributor

@pgrzesik pgrzesik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants