Pushing a big file with zero down time consistently fails.

[dam5s]

Whenever trying to push a pretty big app with a lot of files, the zero down time deployment fails.

error: Error processing app files: Error uploading application.
	
Error performing request: Put https://api.run.pivotal.io/v2/resource_match: http: ContentLength=144633 with Body length 0
	
error running command: exit status 1

When looking at the logs, the request for resource_match never comes back with a response.

If pushing without zero downtime, the cf cli handles the failure to do resource_match appropriately.

I think this is because of the fixes in the CLI for the following issues -
cloudfoundry/cli#1042
cloudfoundry/cli#1123

In our case we are facing the issues that were faced in this issue:
cloudfoundry/cli#1123

[vito]

Maybe this is fixed by just bumping the cf CLI?

I kicked off a new build - could you try it out? If this is fixed I'll publish a new release.

resource_types:
- name: cf
  type: docker-image
  source:
    repository: concourse/cf-resource
    tag: dev

[dam5s]

Unfortunately it does not fix it. I did try before as well, with a docker image having latest CLI and the Autopilot plugin: run cf push it works, run cf zero-downtime-push it does not.

It's not a huge emergency right now for us, as it's not an app that desperately needs the zero downtime, and in the worst case I would implement my own zero downtime. But it would be nice to get to the bottom of it. Thanks!

[dam5s]

I also faced the issue of trying to push a docker container with zero down time, and it's something that autopilot does not support either.

So I forked the resource and applied the following commit:
vmware-archive@master

Is it a change that would be considered?

My current implementation probably doesn't cover all the edge cases that autopilot did (what if an app called venerable exist, et c.), but it shells out to the cf cli for everything instead.

[dam5s]

Created a pull request to fix it
#72