Feature: implement get debug-info

[10ko]

This PR introduces the command:

$ garden get debug-info

As spec'd out in #547, it's a command to collect all sort of system, project and providers information in a zip file. This will be useful data users can attach to github issues.

Thanks,
E.

[edvald]

This is great! Just a bit of pedantry in my comments, except maybe that K8s namespace thing, which is possibly a bug. That aside, happy first feature! :D

[eysi09]

Had a few nitpicks of my own but otherwise looks great!

One thing we could improve though is the logging. E.g.: the body of the command action could look like this:

    const tempPath = join(garden.projectRoot, GARDEN_DIR_NAME, TEMP_DEBUG_ROOT)
    const entry = log.info({ msg: "Collecting debug info", status: "active" })
    const systemEntry = entry.info({ section: "system", msg: "collecting info", status: "active" })
    await collectBasicDebugInfo(garden.projectRoot, systemEntry)
    systemEntry.setSuccess({ msg: chalk.green(`Done (took ${systemEntry.getDuration(1)} sec)`), append: true })

    const providerEntry = entry.info({ section: "providers", msg: "collecting info", status: "active" })
    await collectProviderDebugInfo(garden, providerEntry, tempPath, opts.format)
    providerEntry.setSuccess({ msg: chalk.green(`Done (took ${providerEntry.getDuration(1)} sec)`), append: true })

    entry.setState("Preparing archive")
    const outputFilename = DEBUG_ZIP_FILENAME.replace("TIMESTAMP", new Date().toISOString())
    await zipFolder(tempPath, join(garden.projectRoot, outputFilename), log)

    await remove(tempPath)

    entry.setSuccess({ msg: "Done", append: true })
    log.info(`\nDone! Please find your report under ${garden.projectRoot}.`)

    return { result: 0 }

With this, we can simply remove the log statements from actions.getDebugInfo (and return the Bluebird map like @edvald suggested) and from collectSystemDiagnostic. The info statements that is, not the errors.

Passing the system and provider entries like this also ensures that the errors get set on the appropriate entry.

The end result looks something like this:

✔ Preparing archive → Done
   ✔ system                    → collecting project configuration files → Done (took 0.3 sec)
   ✔ providers                 → collecting info → Done (took 0.4 sec)

Done! Please find your report under /Users/eysi/code/garden-io/garden/examples/simple-project.

[10ko]

Dear all,
thanks a lot for the review, I agree on everything and wrote fixes and add-ons as you requested.

I have few notes and consideration to add:

• @eysi09 The reason the command was running twice was because the garden project you tried the command against was:

  • a valid garden project, so
  • the normal command action would get called
  • at which point the command tried to collect the providers info but, more than likely, you had docker or k8s down.
  • the function collectProviderDebugInfo(...) would throw an exception.
  • The exception would then get caught in the cli.ts where generateBasicDebugInfoReport(...) would get called again:

  I added another try/catch in the function collecting the provider info.

• The try/catch mentioned above will catch any exception thrown by any provider. Since the actions are executed through Bluebird.props(...): even if one of may providers fail, all (promises) will. It would be nice to catch only the failing providers. This would require a lot of internals work and was kinda out-of-scope for this PR. If any of you think it's something we want in the future I can open an issue.

• @edvald I found a strange 404 error regarding a dependency called tmp-promise: the 2.0.0 version we used just got deleted from npm and github. I updated the dependecy to 2.0.1 but maybe we should investigate a replacement or if we need it at all since it doens't seem very reliable?

Thanks again and please let me know if you have any other comment.
E.

[eysi09]

I believe the tmp-promise issue was resolved in another PR so rebasing should remove the need for that fix.

[eysi09]

One thing I noticed after approving is that the debug info is not git ignored.