Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-15983] Fold Titanium Diagnostic Test into CLI

GitHub Issuen/a
TypeEpic
PriorityHigh
StatusClosed
ResolutionDone
Resolution Date2017-07-12T22:48:30.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsCLI
Labelsplanning-3.3.0
ReporterIngo Muschenetz
AssigneeEric Merriman
Created2013-12-13T11:22:16.000+0000
Updated2017-07-12T22:48:39.000+0000

Description

We have had good luck with an initial implementation of a connection diagnostic test for Titanium: https://github.com/appcelerator/titanium-connection-test We should fold this into CLI This should result in a tool that customers and sales engineers feel comfortable using at customer sites to diagnose any issues that may be occurring. We should run this as part of ti info and ti setup.

Attachments

FileDateSize
Screen Shot 2014-12-08 at 10.04.39 AM.png2014-12-08T15:10:55.000+000011247

Comments

  1. Chris Barber 2014-01-15

    The "titanium setup check" command already does many of these things. It checks both http and https requests using the proxy settings. It checks SDKs. It checks permissions. It does not explicitly check certs, but if the certs are bad, then the other tests would fail. So, we certainly can find other things to test. Some of these tests should be reported in the "ti info" issues list, which they currently are not.
  2. Ingo Muschenetz 2014-04-07

    Note, this is meant to fold in a complete diagnostic solution into the CLI. Thus, it would check for things that only affect Studio (like logging in via Java, vs Node.js modules), or explicitly checking a known list of servers rather than checking a proxy abstractly.
  3. Tim Poulsen 2014-12-01

    The consensus of the product development team is that these diagnostics functions should either be part of a new subcommand, such as ti test or included only if the user adds a --verbose option. They agree that folding these tests into the CLI will make them more useful and available to sales engineers, support, and clients.
  4. Chris Barber 2014-12-03

    [~skypanther] Are you still planning on doing this as a new command (i.e. "test") or add it to the ti setup check command where we already have diagnostic checks? If you are creating a "test" command, why? What's the rationale? Why is wouldn't we just add this diagnostic info to ti setup check?
  5. Tim Poulsen 2014-12-03

    I'm open to implementation suggestions. But my thinking: * Not everyone uses proxies, so why clutter the output for those folks? * The ti connection test takes a couple of command line args, which might make more sense for users to supply as flags to a separate subcommand than to ti setup check. * The output of the setup check is already pretty long. On Windows, there's a buffer limit on console output (50 lines?) that we could possibly overfill.
  6. Chris Barber 2014-12-03

    [~skypanther] I thought that part of the diagnostic tests were testing proxy settings. Besides, I've already got proxy tests on ti setup check. We certainly do not want to add command line arguments to ti setup for check's sake. But what args are we talking about? Should these be passed in or should we just include a number of known tests. I wouldn't be concerned about the command prompt output buffer size. ti info's output is huge as is.
  7. Tim Poulsen 2014-12-04

    titanium-connection-test has two arguments: -titanium-connection-test -p \[proxy url] for explicitly specifying the proxy's address- _this can be set via ti setup_ titanium-connection-test -c \[path/to/certificate] for specifying a cert to use if the proxy requires one for a secure connection
  8. Tim Poulsen 2014-12-05

    I'm unsure of the definitive list of URLs to test. What's in the docs doesn't match what's in titanium-connection-test which doesn't match what was in the CLI. Here's the list I have the CLI checking currently, happy to add or prune as needed. * https://api.appcelerator.com/p/v1/release-list, * https://api.appcelerator.net/p/v1/release-list, * https://api.cloud.appcelerator.com, * http://developer.appcelerator.com, * https://preview.appcelerator.com, * http://preview.appcelerator.com, * https://studio.appcelerator.com, * http://studio.appcelerator.com, * https://www.appcelerator.com, * http://www.appcelerator.com, * https://www.google.com, * https://github.com, * https://registry.npmjs.org Docs/titanium-connection-test suggest these additional URLs: * https://developer.appcelerator.com (doesn't exist) * https://download.appcelerator.com (redirects to preview.appcelerator.com) * http: and https://openx.appcelerator.com (gives db connection error)
  9. Tim Poulsen 2014-12-05

    PR https://github.com/appcelerator/titanium/pull/174 This PR implements the URL tests, the cURL tests, and the Java connection test from the titanium-connection-test project. It does not include the autodetection of the proxy and proxy settings. Nor does it test specifying a certificate file, which the ti-con-test project enables you to do. (At least the autodetection of proxy settings should be a separate ticket/PR as it would involve changing other portions of the CLI.) Functional test: 1. With a good network connection, run ti setup and choose option k. You should see output like this: {quote} Network ✓ online \- no proxy server configured ✓ Network connection test ✓ cURL connection test ✓ Java connection test {quote} 2. Configure your network to block access to a URL, such as studio.appcelerator.com, then re-run the test above. (I was able to configure this via my wifi router, as I have no actual proxy server available. You could install Charles or Squid & configure to block a site.) You should see output like this: {quote} Network ✓ online \- no proxy server configured ✕ http://studio.appcelerator.com (HTTP status: 404) is unreachable ✓ cURL connection test ✓ Java connection test {quote}
  10. Neeraj Gupta 2014-12-08

    [~tpoulsen] [~cbarber] My recommendation would be to fold these checks into existing "ti setup check" instead of introducing another option. It would also be good to include these URLs in a configuration file (so that it can be enhanced easily) instead of burying it in the code. It would be good to indent the output e.g. "no proxy server configured" should be indented to show that this check is part of online check. You should show Studio failures in this case under "Network connection test" as this is missing here.
  11. Tim Poulsen 2014-12-08

    [~ngupta] Thanks for your comments. You make a good point about putting the URLs into a configuration file. I will do so. I have included this functionality in ti setup check (or ti setup and choose the "k" check option) rather than making it a separate option. The output is indented in the actual console output, though that's not clear from the text in my previous Jira comment. I will attach a screenshot. To others reading this ticket: I'd like input on how to handle the cURL checks on Windows, where cURL is not installed by default. I could skip those checks entirely when the setup check is run on Windows; I could check to see if cURL is available and if so, run the tests otherwise output a "cURL not available" message; or is there something else I should do?
  12. Neeraj Gupta 2014-12-08

    [~skypanther] Your screenshot looks good. I would add that we run into these connectivity issues more on Windows platform so it is really important to figure out how to make it work on Windows platform.
  13. Ingo Muschenetz 2014-12-08

    I don't know if we need to use cURL specifically on windows. We don't use it anywhere in our platforms--it's just a data point. My guess is we can find an equivalent check using some other built-in utility.
  14. Tim Poulsen 2014-12-08

    I've updated the PR to address Neeraj's comments as well as Chris' on the PR, which relate to checking for curl on Windows and using it only if available. To my knowledge, there's no equivalent command to the curl utility on Windows. There are PowerShell commands I could use, though there's no guarantee that users would be running ti setup within PowerShell rather than simply cmd. The cURL commands are failing on all platforms now because of invalid usernames/passwords. (The same is true of the titanium-connection-test utility, though it's checks mistakenly show the tests as successful because they don't check sufficiently.) Regardless, if we supply working user credentials for the tests, those *usernames and passwords will be in the public titanium repo*, instead of being in the private titanium-connection-test repo.
  15. Tim Poulsen 2014-12-09

    This ticket has been converted to an Epic. Look to the sub-tickets for progress and pull requests.
  16. Lee Morris 2017-07-12

    Closing ticket as all related tickets have now been closing.

JSON Source