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

s-h-a-d-o-w · 2019-10-05T21:13:49Z

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

The text was updated successfully, but these errors were encountered:

exlame · 2019-10-06T19:30:08Z

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 · 2019-10-06T19:46:52Z

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

s-h-a-d-o-w · 2019-10-06T21:58:23Z

@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 · 2019-10-16T22:30:47Z

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 #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 · 2019-10-17T01:49:27Z

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 · 2019-10-17T17:26:49Z

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 · 2019-10-17T18:32:14Z

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 · 2019-10-19T18:42:33Z

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

githubsaturn · 2019-10-19T19:17:57Z

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 · 2019-10-19T19:20:44Z

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 · 2019-10-20T21:55:02Z

@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 · 2019-10-20T23:30:08Z

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 · 2020-01-10T15:25:45Z

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

githubsaturn · 2020-01-10T15:31:59Z

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

ofirl · 2020-01-10T15:42:02Z

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 · 2020-03-12T12:34:08Z

@githubsaturn I did some debugging on my windows machine and found out, that the cli hangs at

caprover-cli/src/commands/deploy.ts

Lines 232 to 237 in 179faf8

 this.apps = 

 ( 

 await CliApiManager.get( 

 machine 

 ).getAllApps() 

 ).appDefinitions || []

Seems the promise doesn't resolve

sleeyax · 2020-03-30T21:51:49Z

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

caprover-cli/src/api/ApiManager.ts

Lines 111 to 116 in fb632f7

 getAllApps() { 

 const http = this.http 

 return Promise.resolve() // 

 .then(http.fetch(http.GET, '/user/apps/appDefinitions', {})) 

 }

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 · 2020-04-13T10:04:55Z

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 · 2020-05-27T15:18:33Z

@jekusz I can reproduce this too.

manuman94 · 2021-03-06T16:41:03Z

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!

githubsaturn mentioned this issue Aug 20, 2020

Freezes on ensuring authentication when machine name provided from command line #61

Closed

githubsaturn mentioned this issue Jan 15, 2021

Default Deployment get's stuck #75

Closed

githubsaturn mentioned this issue May 8, 2021

caprover deploy --default hangs at the: Ensuring authentication... step #94

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

s-h-a-d-o-w commented Oct 5, 2019 •

edited

Loading

exlame commented Oct 6, 2019

s-h-a-d-o-w commented Oct 6, 2019

s-h-a-d-o-w commented Oct 6, 2019

vohzd commented Oct 16, 2019 •

edited

Loading

githubsaturn commented Oct 17, 2019

s-h-a-d-o-w commented Oct 17, 2019 •

edited

Loading

githubsaturn commented Oct 17, 2019

vohzd commented Oct 19, 2019

githubsaturn commented Oct 19, 2019

vohzd commented Oct 19, 2019

s-h-a-d-o-w commented Oct 20, 2019 •

edited

Loading

githubsaturn commented Oct 20, 2019

ofirl commented Jan 10, 2020

githubsaturn commented Jan 10, 2020

ofirl commented Jan 10, 2020

perzeuss commented Mar 12, 2020 •

edited

Loading

sleeyax commented Mar 30, 2020 •

edited

Loading

jektvik commented Apr 13, 2020

JosXa commented May 27, 2020

manuman94 commented Mar 6, 2021

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

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

Comments

s-h-a-d-o-w commented Oct 5, 2019 • edited Loading

exlame commented Oct 6, 2019

s-h-a-d-o-w commented Oct 6, 2019

s-h-a-d-o-w commented Oct 6, 2019

vohzd commented Oct 16, 2019 • edited Loading

githubsaturn commented Oct 17, 2019

s-h-a-d-o-w commented Oct 17, 2019 • edited Loading

githubsaturn commented Oct 17, 2019

vohzd commented Oct 19, 2019

githubsaturn commented Oct 19, 2019

vohzd commented Oct 19, 2019

s-h-a-d-o-w commented Oct 20, 2019 • edited Loading

githubsaturn commented Oct 20, 2019

ofirl commented Jan 10, 2020

githubsaturn commented Jan 10, 2020

ofirl commented Jan 10, 2020

perzeuss commented Mar 12, 2020 • edited Loading

sleeyax commented Mar 30, 2020 • edited Loading

jektvik commented Apr 13, 2020

JosXa commented May 27, 2020

manuman94 commented Mar 6, 2021

s-h-a-d-o-w commented Oct 5, 2019 •

edited

Loading

vohzd commented Oct 16, 2019 •

edited

Loading

s-h-a-d-o-w commented Oct 17, 2019 •

edited

Loading

s-h-a-d-o-w commented Oct 20, 2019 •

edited

Loading

perzeuss commented Mar 12, 2020 •

edited

Loading

sleeyax commented Mar 30, 2020 •

edited

Loading