@steren can we have the cloudrun/hello image open sourced (I'm thinking on its own repo) so that we can have the demo work with a repo that actually has code in it?

See: jamesward/cloud-run-button#4

Very soon, --platform managed will be required when running gcloud beta run deploy to deploy to the managed version of Cloud Run without prompt.

The support for working dir from #26 needs documentation.

Maybe when we first start running we display something like:
Running in terse output mode - hit "v" to enter verbose mode

In verbose mode we should show the gcloud commands we are running but not necessarily their output.

From: jamesward/cloud-run-button#2

Cloud Shell will soon ship the most recent pack CLI (v0.4.1) for Buildpacks. There have been many changes to the Buildpacks spec; hopefully nothing breaks.

Also, the binary will be placed under /usr/local/bin/pack where the current Dockerfile tries to create a symlink. The symlink command will probably break by then.

The docs suggest setting cloudshell_dir but I found that cloudshell_working_dir works.

Pull request at #78.

When no projects exist, create one for them, like:

PROJECT_NAME="$1-$((1 + RANDOM % 10000))"
    gcloud projects create $PROJECT_NAME --set-as-default --quiet 2> /dev/null
    if [[ "$?" -eq 0 ]]; then
      break
    fi
    sleep 1

It's possible to list regions via the client library:

https://cloud.google.com/run/docs/reference/rest/v1alpha1/projects.locations/list

This is primarily because Cloud Run default service account currently has broad capabilities (Editor) on user’s GCP project.

So if someone clicks to the button to deploy a malicious repository, they might just go with it which would’ve ended up stealing their tokens.

Right now we show this indicator:

[ ✓ ] Cloned git repository https://github.com/foo/bar.
[ ✓ ] Queried list of your GCP projects
[ ✓ ] Found 3044 projects in your GCP account.

and then definitely prompt for input at least once once for a GCP project.

Does this give user enough chance to review the git repo being deployed –or should we show the user another confirmation like:

[ ? ] Do you allow application at https://github.com/foo/bar to be deployed? (Y/n) 

I'm not sure.

I'm working on an app that'd be nice to buttonize but it is one that should set the "Require authentication" flag on the service. I think if we allow the app.json to have a property like:

{
    "require-auth": true
}

Then maybe prompt for the roles to allow.

This might be related to #33 but I'm not totally sure.

The name from app.json can contain spaces and other chars which are not valid in the container tag. So we need to escape them (which may already be in place for the Cloud Run service name).

Reproduce with:
https://console.cloud.google.com/cloudshell/editor?shellonly=true&cloudshell_image=gcr.io/cloudrun/button&cloudshell_git_repo=https://github.com/bkimminich/juice-shop.git

Pretty error message. Or maybe not show projects that the user can't actually use for deploy.
@grant

If there's a way to collect analytics and determine top public repositories used with the button, it would be great to keep a tab on those.
cc: @jamesward

The script output tells me how to change the image and deploy a new version, but it doesn't tell me how to remove it.

It also doesn't tell me what happens if I don't - will it live forever? Will it expire? Will I have to pay anything

Like:

  gcloud services enable run.googleapis.com 2> /dev/null

  if [[ $? -eq 1 ]]; then
    echo "Your account needs to have billing setup to continue. Visit:"
    echo "https://console.developers.google.com/billing/linkedaccount?project=$PROJECT_ID\n"
    read -p "After setting up billing, press enter to continue."
    gcloud services enable run.googleapis.com
  fi

Right now if someone specified ?cloudshell_working_dir, we have no indication of it working or not. If specified, we can quickly print

[ checkmark ] Checked out directory **$dir**

Trying the button on:
https://github.com/bkimminich/juice-shop.git

I get:

james_demo@cloudshell:~$ cloudshell_open --repo_url "https://github.com/bkimminich/juice-shop.git"
[ ✓ ] Cloned git repository https://github.com/bkimminich/juice-shop.git.
Error: error attempting to read the app.json from the cloned repository: failed to parse app.json file: failed to parse app.json: json: unknown field "description"

Reproduce with:
https://console.cloud.google.com/cloudshell/editor?shellonly=true&cloudshell_image=gcr.io/cloudrun/button&cloudshell_git_repo=https://github.com/bkimminich/juice-shop.git

It seems like we want to support cloudbuild.yaml in addition to Dockerfiles, and there's a plan to support buildpacks via app.json (#3).

@jamesward What's the primary reason we want to have cloudbuild.yaml? Does it do something potentially we can’t do via docker build with multi-stage Dockerfiles?

I suppose it enables tools where you don't want to use docker and still end up with a docker image (ko, pack etc.), but should we treat this as a priority –especially given the adoption levels of cloudbuild.yaml vs Dockerfiles?

If there is a single project, auto-choose it.

Add:

gcloud auth configure-docker -q

To the list of stuff we run because the Cloud Shell image doesn't have all the hosts we need: GoogleCloudPlatform/cloud-run-hello#1

Lists of deployable apps look better with a smaller button, but to resize the image on GitHub requires leaving markdown for HTML. Add a smaller image that can be referenced to keep it simple.

This is what I'm currently experimenting with:

<img src="https://storage.googleapis.com/cloudrun/button.svg" alt="Run on Google Cloud" height="20">

v1beta1 is called (for example here: https://github.com/GoogleCloudPlatform/cloud-run-button/blob/master/cmd/cloudshell_open/cloudrun.go) However, it doesn't exist as a 404 error is returned. Also, it's not mentioned in the public documentation (https://cloud.google.com/run/docs/reference/rest/) nor the Google API repos (https://github.com/googleapis/google-api-go-client/tree/master/cloudbuild)

It wasn't clear in the UI that there were more project IDs beyond those listed. After scrolling it is clear but I'd be nice to have a visual indicator as such.

Received via internal bug feedback tool:

This is my second run trying out the Run Deploy and I figured it out so this screenshot isn't relevant but I think it'd be helpful if:

1. After you select a project and get an error message, you can select another one instead of just being stuck trying to fix payment options for that project
2. Be clearer about how to add a payment method and how much that payment will be. Just link to it more directly

tl;dr consider adding "New Project" option to the project selector, and handle billing errors in a more friendly way.

Quick fix: Provide an error message and ask the user to try again and trust the image
Nicer fix: Have the user login, then continue

If there is no Dockerfile, fallback to trying buildpacks. See #3 for an add-on / related discussion.

looks like this wasn't tested properly :)

I'd be cool if external services that need to be provisioned can be as part of the button deploy. Ideally we use app.json to specify these. Maybe they are based on the API names that need to be enabled? Should we have some way to select an existing resource? Examples GCS, Cloud SQL, etc.

End goal: An app that needs something like Cloud SQL can be deployed to 100% functionality from the button.

Make it possible to customize the SERVICE_NAME possible via app.json

After clicking the button and following prompts, I now have a deployed app, and the source for that app cloned in my Cloud Shell.

I'd love to be able to modify the source and redeploy to the app again, but I don't know how. Looking in history, it looks like I originally deployed using cloudshell_open but it takes a -repo_url which will presumably re-clone the repo, instead of just deploying my changes.

Currently we don't support ?cloudshell_working_dir argument.

Looks like Cloud Run Samples repo will have multiple samples in the same repo using this button, so this feature request will come soon.

If I have a public image in gcr.io, can I give the button required parameters and when clicked, it opens the window for cloud run and the image name is already filled out ?

I don't want user to build the repo or so, just autofill the image name in Cloud run and if possible add some env variables ?

cc:@steren

This feature would allow users to run with non-default service accounts created just for that application.

@mchmarny said that the default Run app identity doesn't have enough permissions to create a PubSub topic to one-click-deploy his app. (Ideally it should, since GCE default svc account has Editor role, so I'll investigate that separately).

But if we needed this someday, the strawman design would be like:

app.json:

{ 
  "roles": [
     "roles/storage.objectAdmin",
     "roles/pubsub.subscriber"
  ]
}

When this field specifies, we should prompt the user with a confirmation saying a "service account with permissions [..., ...] will be created or re-used by the deployed application".

Then we would create a Cloud IAM Service Account that has the same name as the Run app name. (It would assign the listed roles on the project-level to that service account. It wouldn't remove extra role bindings that are already there, as they may be added by the user.)

If the account exists, we should have a way of verifying it was created by cloud-run-button (somehow through a marker). If so, we can reuse it (by making sure the role bindings listed in app.json exist).

But I'm not sure if we need this feature just yet, since technically GCE Default Service Account is an Editor and it should be able to bootstrap its needs just fine.

Set via the cloudshell_git_branch query param.

jlward4th@cloudshell:~$ cloudshell_open --repo_url "https://github.com/jamesward/hello-micronaut.git" --git_branch "dockerfile"
Incorrect Usage. flag provided but not defined: -git_branch

NAME:
   cloudshell_open - This tool is only meant to be invoked by Google Cloud Shell

USAGE:
   cloudshell_open [global options] command [command options] [arguments...]

VERSION:
   0.0.0

DESCRIPTION:
   Specialized cloudshell_open for the Cloud Run Button

COMMANDS:
     help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --repo_url value
   --help, -h        show help
   --version, -v     print the version
Error: flag provided but not defined: -git_branch

I think we should create a service (on Cloud Run) which gives us a short and custom URL we can link to for the button so that we can:

• be isolated from underlying URL which we redirect to
• possibly support the referrer so the git URL is optional
• track deploy metrics (#13)
• set current or future defaults

So the button href cloud be just something like:
https://cloud.run/deploy

Maybe @steren can chime in on possibly using the existing cloud.run domain.

The CONTRIBUTING doc includes info on using Docker for local development, which is probably good for some methods of testing. But it is slow (see #90). We should document how to do local development directly with Go. Also there are some tests and we should document how to run them.

It'd be nice if we could enable a way to run Jib builds via Maven or Gradle. The app.json could include something like:

{
    "scripts": {
        "build": "./mvnw compile jib:build -Dimage=gcr.io/${PROJECT_ID}/hello-springboot"
    }
}

If that is set, we run the command instead of docker build or buildpack stuff. We'd have to set the PROJECT_ID env var when we run the build command.

Note that this example requires a JVM which Cloud Shell has, but if the user needs other system deps they could add a build shell script to install them, and then specify that script.

So the user has deployed their first app, now what? Maybe help them setup GCB for CI/CD.

Add support for: https://devcenter.heroku.com/articles/app-json-schema#scripts

The way the button clones the repo implies that you can only ever use the button once. After the first use, it will fail.