return result in deployProxy including not deployed result

[antxxxx]

This change returns deployment information when deployProxy is called so caller can work out which revision was uploaded, where it was deployed to etc.

It also includes a 'not deployed' information when proxy is uploaded but not deployed

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[antxxxx]

I signed it!

[googlebot]

CLAs look good, thanks!

[noahdietz]

Hi @antxxxx, first of all thanks for the PR. I am on the email thread we have going WRT Hosted Functions, so I am aware of generally why you are submitting this PR.

I'm trying to understand the use case better.

Currently, the deployProxy will return nothing if there was nothing deployed or some deployment info if that proxy was actually deployed to an environment (or multiple).

If I understand, you would like to see deployProxy always return some bit of proxy info regardless of the deployment state of said proxy? I'm curious of when this might happen without the caller knowing...i.e. when using import-only or not. Let me know if I'm misunderstanding!

[antxxxx]

There is a bug in Apigee which means you can not upload service callout policies with loadbalancer elements (we have had an open case with Apigee for several years over this - it fails when you try uploading using curl command so it is not a bug with this program).

We have a couple of proxies with service callout polices with load balancer element, so our CI script replaces this and then uses apigeetool with import only flag and prints a message at the end saying 'revision xxx of proxy yyy needs service callout policy changes and manually deploying'

So we can print this, we need to know the revision that has been uploaded

[noahdietz]

Thank you for the explanation! I’m happy to help with that. I’d prefer to do the work for you, as there are some other touch points in the code I’d like to work on related to this change. Do you mind if I close this PR, open an issue and solve it with a PR today/tomorrow? When the next release will happen I can’t say, but at least we will have a change staged for y’all to deprecate your fork.

On Wed, Oct 18, 2017 at 7:53 AM Anthony Brown ***@***.***> wrote: There is a bug in Apigee which means you can not upload service callout policies with loadbalancer elements (we have had an open case with Apigee for several years over this - it fails when you try uploading using curl command so it is not a bug with this program). We have a couple of proxies with service callout polices with load balancer element, so our CI script replaces this and then uses apigeetool with import only flag and prints a message at the end saying 'revision xxx of proxy yyy needs service callout policy changes and manually deploying' So we can print this, we need to know the revision that has been uploaded — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#92 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGVj_wDHCB_8tvYY9okNVUh3CGkIpod4ks5sthDvgaJpZM4P75pD> .

-- Noah Dietz | Software Engineer | ndietz@google.com | 650-930-0938

[noahdietz]

@antxxxx I opened #94 to fix #93

If you are OK with accepting my change instead of yours here, please close this PR. Otherwise, I am happy to continue discussing this!

[antxxxx]

The code in your change is better than mine, so I am happy to accept your change :)

[noahdietz]

Fixed by #94

Thanks @antxxxx for opening this in the first place!