Only a versioned download URL is provided for v2

[stewartmiles]

Bug Description

google_sql_proxy (v1) could be downloaded from say https://dl.google.com/cloudsql/cloud_sql_proxy.linux.amd64 to grab the latest x64 Linux build. However, per the docs on https://cloud.google.com/sql/docs/postgres/connect-auth-proxy#linux-64-bit , only versioned download URLs are now published. Would it be possible to publish a "latest" URL that points at the latest release similar to what we had with v1? It would be great to reduce the number of manual upgrades we need to manage.

Example code (or command)

// paste your code or command here

Stacktrace

Steps to reproduce?

1. Go to https://cloud.google.com/sql/docs/postgres/connect-auth-proxy#linux-64-bit
2. Try to programmatically download the latest version of the v2 proxy

Environment

1. OS type and version: Linux x64, Windows x64, macOS (all archs)
2. Cloud SQL Proxy version (./cloud-sql-proxy --version): v2 all versions
3. Proxy invocation command (for example, ./cloud-sql-proxy --port 5432 INSTANCE_CONNECTION_NAME): N/A

Additional Details

No response

[jackwotherspoon]

Hi @stewartmiles Thanks for opening an issue on the Cloud SQL Proxy 😄

I think this is really good idea and would better align the URL download path with how we tag our v2 Proxy container images (i.e latest).

Note: I made this a feature request as it is not really a bug per say.

[stewartmiles]

@jackwotherspoon I opened this as a bug since it is a regression vs v1's interface.

[hessjcg]

Hi @stewartmiles,

We don't plan to offer a stable URL to the "latest" v2 proxy executable. We prefer that our users intentionally choose the version of proxy. We find that small bit of overhead is worth it to keep systems in a more consistent state.

We will keep the url format consistent across V2 releases. You can programmatically determine the latest version of the proxy. Here is a small bash script that will reliably download the latest V2 release with arch Linux-amd64. I hope you can adapt this to your needs:

# Find the most recent v2 release tag.
#    This uses  `jq` tool to parse the Github response json. jq may not be installed by default.
LATEST=$(curl "https://api.github.com/repos/GoogleCloudPlatform/cloud-sql-proxy/releases |  jq -r '.[].tag_name' | grep 'v2' | head -n1)

# Create the URL to the latest V2 executable file.
URL="https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/$LATEST/cloud-sql-proxy.linux.amd64"

# Download the file
curl -L -o cloud-sql-proxy.linux.amd64 "$URL"

[stewartmiles]

Hey @hessjcg these little inconveniences add up, keeping software up to date is a mission critical operation and when we just need to check every vendor for their latest version rather than putting processes in place to automate upgrades this puts security at risk. Honestly I'm very disappointed by your response.

[stewartmiles]

Thanks for your response we'll spend more of our little time plugging this in.

[jackwotherspoon]

@stewartmiles I would be curious to hear more about your use-case and what kind of workflow you are wanting to download the latest Proxy version with?

@hessjcg I would not be opposed to creating a latest storage bucket and adding a step to the end of our release process to copy the contents of the newly released binaries over to https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/latest

@stewartmiles would that better meet your needs?

[jackwotherspoon]

given the interest here, I am going to re-open this so we can wait and hear if others are also wanting this

[stewartmiles]

@jackwotherspoon we have an existing integration that regularly pulls the latest proxy when we build packages that are run in nightly tests and packaged as part of containers that we refresh the base images of weekly. As I alluded to in https://github.com/GoogleCloudPlatform/cloud-sql-proxy/issues/2377#issuecomment-2622777654 running a variant of @hessjcg's script to grab the latest release is possible - indeed that is what we've done - but it just adds to our maintenance burden. While it seems like a small thing from your team's point of view we have a heap of dependencies that we manage for our services and every little thing like this takes us away from working on improvements that provide end-user value. A redirect or copy from latest build would have turned a 10 minute job into a change that takes a few seconds.

Unrelated, by while I'm replying, a few things that caused a minor bit of pain during the migration to v2:

• Token based auth to replicate the old v1 now requires passing two flags (--token and --login-token), one token - I presume, I couldn't find great docs - to auth the connection to the DB instance and the second instance to login to the DB on the instance.
• Service account impersonation with v1 used to work by providing the -enable_iam_login flag along with -token and the v1 proxy used to infer the service account username. Now, using --auto-iam-authn, --token and --login-token, the service account name, with the .gserviceaccount.com postfix, needs to be provided via the --impersonate-service-account flag as well. Now this may not seem like a big change, but plumbing this through layers of stack to get this to work is again something that we would have liked to avoid. In addition, the DSN used to connect to the DB via the proxy must use the service account's name without the .gserviceaccount.com postfix. This is important for our development tooling for users to gain access to test and development DBs.

That said, we've done the migration now and lost half an engineer day to it.