Using vars-file flag results in error

[xyloman]

Attempting to use the new vars-file flag to interpolate cf manifest files with a command similar to the following:

cf zero-downtime-push app-name -f app-manifest.yml -p app.jar -vars-file app-manifest-vars.yml 

I made a similar report back to the cf-resource which leverages the autopilot plugin: cloudfoundry-community/cf-resource#56 (comment)

No one has responded so I am not completely sure if its something that I am doing or something with the plugin. Wasn't really sure how to turn on additional debugging to tease out more details.

[squeedee]

I've had a look into this problem. It seems that the autopilot parameters to cf look like this (we injected some debug in autopilot):

cf zero-downtime-push front-end -f `pwd`/manifest.yml --vars-file `pwd`/cf-app-variables/acceptance.yml
[push front-end -f /Users/pivotal/workspace/tile-dashboard/manifest.yml --no-start --vars-file /Users/pivotal/workspace/tile-dashboard/cf-app-variables/acceptance.yml]

When autopilot calls the socket server on this line https://github.com/contraband/autopilot/blob/master/autopilot.go#L259 , with those arguments:
[push front-end -f /Users/pivotal/workspace/tile-dashboard/manifest.yml --no-start --vars-file /Users/pivotal/workspace/tile-dashboard/cf-app-variables/acceptance.yml]
we see the error: error: The following flags cannot be used with deprecated usage: vars-file

What's peculiar about this, is that if you call cf from the command line:

cf push front-end -f /Users/pivotal/workspace/tile-dashboard/manifest.yml --no-start --vars-file /Users/pivotal/workspace/tile-dashboard/cf-app-variables/acceptance.yml it works perfectly.

This leads me to believe that the CLI has inconsistencies between command line options handling, and socket server options handling.

I need this to work so I'll discuss it with the CLI team.

[squeedee]

I think this is the same known issue: cloudfoundry/cli#1445

[jpluscplusm]

Just to clarify for future readers: this problem exists for the single-value --var flag, too, rendering pretty much all of #52 irrelevant :-(