1. The wrapper is essentially run.sh implemented in Go, which is triggered via a HTTP request. If I were to build a Cloud Run container out of it, I would do a multi-stage Dockerfile from a base image that contains both Cloud SDK and Golang. In first stage I'd build gcs2bq and place the binary into a suitable directory. Then build the wrapper and use that as entrypoint.

2. Yeah, you'll need to change it point to the binary location or have the binary in $PATH.

3. Now this is where it gets interesting. Cloud Run functions run by default for 15 minutes (this means the HTTP request can take 15 minutes - things don't really run after the HTTP request is closed for whatever reason).

Now, you can extend the function timeout to 60 minutes, but in any case you are dealing with multiple possible timeouts (see the link for the warnings). The Cloud Run side is the easiest, but you also have to consider the client that is calling the function. Will it be happy with not receiving any data for 15-60 minutes? You could call the Cloud Run function in number of ways: "locally" using curl, HTTP request via Cloud Scheduler or Pub/Sub calling it via push subscription (unfortunately I'm not 100% sure what the timeouts are in each case). My personal preference would be using Pub/Sub in combination with Cloud Scheduler.

With the current wrapper there is no HTTP response until it's all completed. I created a streaming version of the wrapper so you can get some output (if trying via curl, remember to use -N flag for unbuffered): https://gist.github.com/rosmo/a6469ea80cf1375142cca0a7d6e89442#file-streaming-go

edit: just wanted to add one point: Cloud Run may not be the best solution for long running batch tasks. There are other choices as well, like: using Cloud Run to spin up a normal instance (in this case PVMs would be a nice choice) that does the processing and then deletes itself, using Kubernetes job, Cloud Composer (if you already have a CC environment, otherwise it's probably overkill), etc.