Can only deploy interactively (neither CLI arguments, nor config file work)

[s-h-a-d-o-w]

The options I supplied are these: caprover deploy --caproverUrl "https://captain.region.mydomain.com" --caproverApp myApp --branch master --caproverPassword "myPassword"

Similarly in a .yml file:

---
branch: master
caproverApp: myApp
caproverPassword: 'myPassword'
caproverUrl: https://captain.region.mydomain.com

But with both ways, I get stuck at (and by stuck I mean that it freezes there. If I supply a wrong password, I do get an error):

Ensuring authentication...

CLI version: 2.0.2 CapRover instance: 1.5.2

[exlame]

Did you try by running caprover login before? There is a note in doc for deploy :

Note: you must be logged in to "machine-name".

[s-h-a-d-o-w]

Caprover stays logged on and when running caprover ls, the machine I tried to deploy to is listed.

[s-h-a-d-o-w]

@exlame I just realized - do you mean to say that deploying using only command line arguments or configuration file works for you? Are you using the same versions I do? (I updated my original post)

[vohzd]

Getting the exact same issue ("Ensuring authentication") when running the below;

caprover deploy --caproverUrl "https://captain.domain.com" --caproverPassword "password" --caproverApp test123

This is me running it in a directory with a valid captaindefinition file and definitely works when deployed via other methods.

Note this works fine when I manually create an app with test123 in the web gui then just simply run caprover deploy.

After reading this I thought it might be because I hadn't created the app just yet https://github.com/caprover/caprover-cli/issues/12

So I called caprover api --configFile "caprover-api.json" and still get Ensuring authentication.

The contents of the .json file;

{
  "caproverName": "myservername",
  "path": "/user/apps/appDefinitions/register",
  "method": "POST",
  "data": {
    "appName": "iamtesting",
    "hasPersistentData": false
  }
}

However if you pass in the following, you'll just get prompted for the password and the API call will successfully execute;

{
  "caproverName": "myservername",
  "caproverUrl": "captain.domain.com",
  "path": "/user/apps/appDefinitions/register",
  "method": "POST",
  "data": {
    "appName": "iamtesting3",
    "hasPersistentData": "false"
  }
}

Pass in the password like so, and it'll stop working. So it seems like caproverPassword is the culprit

{
  "caproverName": "myservername",
  "caproverPassword": "password",
  "caproverUrl": "captain.domain.com",
  "path": "/user/apps/appDefinitions/register",
  "method": "POST",
  "data": {
    "appName": "iamtesting3",
    "hasPersistentData": "false"
  }
}

Ps this is a great project & thanks for the work!

[githubsaturn]

I am having trouble reproducing this issue on my end. I did the following:

caprover  deploy --caproverUrl "https://captain.srv1.usa.domain.com" --caproverApp test --branch master --caproverPassword "myPassword"

I am running 2.0.2 as well.

Having said that, I'll be publishing 2.1.0 soon which has some improvement around authentication. Please try it out and let me know if the issue still persists.

[s-h-a-d-o-w]

No luck.

FWIW, this is the debug output of request-promise. Note that the last part of the x-captain-auth token (I removed the first two parts since I suspect publishing tokens is not a good idea ;) ) is different from captainCookieAuth. Of course I don't know whether that could be the problem...

Click to expand

------------
CapRover CLI has recently been refactored. Please report potential bugs here: https://github.com/caprover/caprover-cli/issues
------------


Preparing deployment to CapRover...

**** Protip ****
You seem to have deployed fructosedb from this directory in the past, use --default flag to avoid having to re-enter the information.

Ensuring authentication...
REQUEST { headers: { 'x-namespace': 'captain' },
  form: { password: '1Q5eqhFmVdtpFEpeB-r ' },
  uri: 'REDACTED/api/v2/login',
  method: 'POST',
  callback: [Function: RP$callback],
  transform: undefined,
  simple: true,
  resolveWithFullResponse: false,
  transform2xxOnly: false }
REQUEST make request REDACTED/api/v2/login
REQUEST onRequestResponse REDACTED/api/v2/login 200 { server: 'nginx/1.17.4',
  date: 'Thu, 17 Oct 2019 17:18:08 GMT',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '307',
  connection: 'close',
  'x-powered-by': 'Express',
  'set-cookie':
   [ 'captainCookieAuth=PART1.PART2.HDQDsFf3subz5HrrDgwStldt8XrmSvNcPUs98VQdxQw; Path=/' ],
  etag: 'W/"133-blpAv8bx4CuSxrkCgLGv3Jc8CvE"' }
REQUEST reading response's body
REQUEST finish init function REDACTED/api/v2/login
REQUEST response end REDACTED/api/v2/login 200 { server: 'nginx/1.17.4',
  date: 'Thu, 17 Oct 2019 17:18:08 GMT',
  'content-type': 'application/json; charset=utf-8',
  'content-length': '307',
  connection: 'close',
  'x-powered-by': 'Express',
  'set-cookie':
   [ 'captainCookieAuth=PART1.PART2.HDQDsFf3subz5HrrDgwStldt8XrmSvNcPUs98VQdxQw; Path=/' ],
  etag: 'W/"133-blpAv8bx4CuSxrkCgLGv3Jc8CvE"' }
REQUEST end event REDACTED/api/v2/login
REQUEST has body REDACTED/api/v2/login 307
REQUEST emitting complete REDACTED/api/v2/login
REQUEST { headers:
   { 'x-captain-auth':
      'PART1.PART2.eDFhZaIsxfZgK6H_qhzvNK6H7y4SpIsg0HSdgZDldCM',
     'x-namespace': 'captain' },
  qs: {},
  uri:
   'REDACTED/api/v2/user/apps/appDefinitions',
  method: 'GET',
  callback: [Function: RP$callback],
  transform: undefined,
  simple: true,
  resolveWithFullResponse: false,
  transform2xxOnly: false }

And this is the end of the log when setting NODE_DEBUG=*:

Click to expand

HTTP 22700: AGENT incoming response!
STREAM 22700: resume
STREAM 22700: readableAddChunk <Buffer 7b 22 73 74 61 74 75 73 22 3a 31 30 30 2c 22 64 65 73 63 72 69 70 74 69 6f 6e 22 3a 22 4c 6f 67 69 6e 20 73 75 63 63 65 65 64 65 64 22 2c 22 64 61 74 ... >
STREAM 22700: readableAddChunk null
STREAM 22700: emitReadable true
STREAM 22700: resume false
STREAM 22700: read 0
STREAM 22700: flow true
STREAM 22700: read undefined
STREAM 22700: need readable false
STREAM 22700: length less than watermark true
STREAM 22700: reading or ended false
STREAM 22700: endReadable false
STREAM 22700: read undefined
STREAM 22700: endReadable false
STREAM 22700: read 0
STREAM 22700: endReadable false
STREAM 22700: emitReadable_ false 0 true
STREAM 22700: flow true
STREAM 22700: read undefined
STREAM 22700: endReadable false
STREAM 22700: maybeReadMore read 0
STREAM 22700: read 0
STREAM 22700: need readable true
STREAM 22700: length less than watermark true
STREAM 22700: do read
NET 22700: _read
STREAM 22700: endReadableNT false 0
HTTP 22700: AGENT socket.destroySoon()
STREAM 22700: endReadableNT true 0
STREAM 22700: endReadableNT true 0
STREAM 22700: endReadableNT true 0
NET 22700: _final: not ended, call shutdown()
STREAM 22700: call pause flowing=true
STREAM 22700: pause

[githubsaturn]

Thanks for the additional information.

I don't see any problems in the API call. What's your OS?

If I cannot repro it on my end. I'll create more debug logs and ask you to retry again to find the problem.

PS: The difference in API auth and cookie is expected.

[vohzd]

Interestingly, on Ubuntu 18 this issue doesn't occur. It just happens on Windows10.

[githubsaturn]

That's why I cannot reproduce the issue - I don't have a windows machine :|

Or it could be NodeJS version. My NodeJS is v10.16.3. Do you have the same Nodejs version on your Windows and Ubuntu?

I'll have to add a "debug" flag to the CLI so that we can get more info when running non-interactive command.

[vohzd]

That's correct, v10.16.3 on both Ubuntu/Win.

Thanks for working to add a debug flag to the CLI. However I'm just happy its working on Ubuntu so no longer blocked.

Cheers!

[s-h-a-d-o-w]

@githubsaturn Sorry, only saw the activity in here just now - github has been weird for me with notifications lately.

Anyway, @vohzd already uncovered the mystery I suppose. I'm on Windows 10 too. :) And also thanks @vohzd for making me realize that it works via the WSL.

Since I planned on using this basically exclusively for deployment via CI anyway and can work out deployment scripts in WSL, it's not a problem for me either. So from my point of view, the issue could be closed. (Although I'd suggest to add a "Does not work on Windows" for --configFile to the CLI help if the bug can't be found.)

[githubsaturn]

Yea - generally speaking, non-interactive deployments are usually used on linux systems. But still, it'd be nice to sort out the root cause of this issue. There might be a more significant bug there. So for that reason, let's keep the issue open for now.

[ofirl]

is there any progress on this? (currently on caprover 1.6.1 and encountered the same bug)

[githubsaturn]

@ofirl I don't have windows machine to test this. Just to confirm, you're experiencing the issue on windows, right?

[ofirl]

yes, i can work around it for now but my main development system is gonna be windows. i can help you debug and send logs if you need, just give me a starting point/tell me what you need.

P.S. great project! thanks for all your work

[perzeuss]

@githubsaturn I did some debugging on my windows machine and found out, that the cli hangs at https://github.com/caprover/caprover-cli/blob/179faf8462ef81ad86dfca1a88c4ee2fc97625ae/src/commands/deploy.ts#L232-L237 Seems the promise doesn't resolve

[sleeyax]

You would think that http.fetch doesn't return anything from within the getAllApps method of the ApiManager:

https://github.com/caprover/caprover-cli/blob/fb632f7c64ba7c01c2440e9c5f7109597aa9eb48/src/api/ApiManager.ts#L111-L116

But when I go the code of the fetch method itself, I can log the response perfectly fine before the return statement. The data just 'disappeared' for no reason whatsoever.

Edit: there's something very weird going on here... sometimes it looks like all the http calls never resolve... I even tried swapping request with needle (because request is deprecated now) but still the same result. What's even weirder is that the command actually worked for me about 1% of the times I tried.

[jektvik]

Hmm, getting stuck on similar on windows 10 cli when attempting:

PS C:\Users\jektv\Documents\Source\node> caprover deploy --default


------------
CapRover CLI has recently been refactored. Please report potential bugs here: https://github.com/caprover/caprover-cli/issues
------------


Preparing deployment to CapRover...

Ensuring authentication...

If I go ahead with an ordinary deploy (i.e. without --default) I and click my way through the prompts then the deploy works without issue.

[JosXa]

@jekusz I can reproduce this too.

[manuman94]

Hi! I'm waiting for the fix too.

I use Windows at home, but my pipelines are launched on linux so I can continue working without any problem. I would like to use it on Windows to test the pipeline jobs before using the actual ones.

Thank you!