Icenium/icenium-cli

Telerik-login not listed as a command

Closed this issue · 10 comments

To invoke builds and other cloud features you need to be logged in. The officially listed way of logging in is using the appbuilder login command. The command launches your default browser and redirects you to identity.telerik.com to login. Your credentials are than stored in a cookie so that you don't have to log in every single time. That is all good if you are going with the assumption that a person is using CLI. However the biggest reason for the CLI in the first place is AUTOMATION :) So how do you log in when you are running CLI as part of . Well you can't launch a browser and log in. Did some digging into the code and internally there is the telerik-login command which is used as follows : appbuilder telerik-login .

Tested it out and it works great. So we arrive at this issue....I think the command should be added to the list of commands, maybe even replace the login command.

The currently intended usage of the CLI is to provide yet another way for developers to use AppBuilder without forcing the usage of our web/windows clients. We also envision that the CLI will be used in a CI environment, but we are not there yet in terms of API and scalability point of view.

We plan to introduce API tokens (think of GitHub's Personal API tokens) that devs will be able to use in CI scenarios. We might have to put some quotas to limit the build usage to reasonable amount once released. We will also provide documentation how to enable CI with popular CI servers like: Jenkins, TFS, etc.

Regarding the undocumented login, feel free to use it while it is there but we might remove it at some point once the CI infrastructure is in-place.

Please share your feedback with us about your CI workflow.

Looks like the telerik-login option was removed 2 days ago. Is there an alternative command that can be used? Any update on the support for CI?

Hello @paulpatarinski,
Telerik Platform and AppBuilder, which is part of it, are moving quickly because we want to implement the best features on the market. Due to recent improvements in the backend of the Telerik Platform, we had to remove the telerik-login CLI command. We did not publicly announced this change because we have always considered it to be an internal and undocumented code.

At this moment, we do not have a substitute for it. Our QAs use Greasemonkey scripts for our automated tests. You can consider a similar solution, using either browser extensibility APIs or UI automation APIs for your preferred OSes.
Hope this helps!

Hi @teobugslayer,

Thank you for the response. I implemented Tampermonkey per your suggestion, however one of the issues I am having is that because the command is issued from within Teamcity (running in non-interactive mode). The node js open module does not seem to launch the browser and therefore the login never executes.

More specifically line 218 in the login.js ("_this.$opener.open(loginUrl);") part of the loginInBrowser function doesn't seem to be working right.

Looking forward to your feedback.
Cheers,
Paul

I checked the source of opener and it uses the built-in start under Windows and open under Mac. For other OSes (especially Linux) it uses its own xdr-open binary. The way they are used looks correct to me and I suggest that you discover what prevents starting the browser in your particular build setup. Maybe there is no default browser registered for the account which TeamCity uses?

@teobugslayer I tried a whole bunch of different options and I still can't get this working. The default browser is set to Chrome on the remote machine. Basically the problem is that the browser is not launching in a window. The process launches but since it does not launch in a window the tamper monkey script never executes. One of the things that I tried is just creating a small powershell script that launches Chrome :

$ps = new-object System.Diagnostics.Process
$ps.StartInfo.Filename = "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
$ps.StartInfo.Arguments = " /all"
$ps.StartInfo.RedirectStandardOutput = $True
$ps.StartInfo.UseShellExecute = $false
$ps.start()
$ps.WaitForExit()
[string] $Out = $ps.StandardOutput.ReadToEnd();

This script leads to the same behavior : If I execute locally on my machine it open the browser. If I RDC into the Remote machine and execute the script it opens the browser. But when I try to invoke the script remotely using invoke-command in powershell all it does is, it launches the process (no window). I will really appreciate your help to resolve this issue

@paylocity-blackcobra, our speculation is that TeamCity works under a system account (usually NT AUTHORITY\SYSTEM or NT AUTHORITY\NETWORK SERVICE) where Chrome has not been properly installed. We recommend using (psexec)[http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx] and run Chrome under interactive user account.

Implemented in #475 but requires changes from the server side. The later are scheduled for the 2.6 release of AppBuilder.

Hi @teobugslayer,

What is the expected release date for 2.6? Also when do you think the backend changes will be made?

Hi @paulpatarinski,

The planned date is Oct 21st but circumstances outside our control may push it a day or two late. The backend code goes on our live servers at the day we release.