Both Cloud Run Button and Heroku Button - app.json Clash

[SudharakaP]

I am trying to add the Cloud Run Button to one of our repositories which has the Heroku Deploy Button which also uses an app.json file.

This creates problems when trying to add the Cloud Run button to the same repository as the Cloud Run also assumes an app.json file and the Heroku app.json file which is different in format will crash the Cloud Run when trying to deploy. Also I am unable to define an app.json file for Cloud Run since one already exists for Heroku.

Is there a possibility to configure the name of the app.json file (or just name it differently) for example so that it doesn't clash with other cloud providers such as Heroku? 😄

[ahmetb]

If you can mention the error, we can help it not clash (by perhaps introducing a placeholder for fields that aren't supported).

[jamesward]

Yeah, our app.json parsing is strict so likely we just need more ignore flags. I think this is the file that is failing:
https://github.com/SudharakaP/jhipster-registry/blob/add-gcp-cloud-run-deploy-button/app.json

I can investigate.

[SudharakaP]

@ahmetb : Thanks for the quick reply. The first error is;

Error: error attempting to read the app.json from the cloned repository: failed to parse app.json file: failed to parse app.json: json: cannot unmarshal string into Go struct field env.required of type bool

Now this is caused by the following line of app.yaml. When you remove the quotes around true it passes through that but gives the following error;

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 "buildpacks"

due to the buildpacks argument in the app.yaml file

Hope this helps. Let me know if you need any further details. 😄

[ahmetb]

We can try and fix buildpacks argument, but I assume this is not a good idea. Because that value is critical to how the app is built. And we better not ignore it.

About required being a string in Heroku ecosystem –that's really sad, and I am not sure if we can fix it easily. We'd need to write a custom json parser and hook that into the normal json parser. (This is not trivial, kubernetes has IntOrBool type for this, maybe we can learn from it).

A cleaner solution I can think of is to introduce a new file name that's used during the lookup stage. For example, we'd suggest people to still use app.json, but if there's a cloudrun.json, we'd use that first.

Maybe this hack would be just for repos like yours, and we would not make it as prominent as app.json in the documentation.

[jamesward]

Officially, required is a boolean in app.json https://devcenter.heroku.com/articles/app-json-schema#env

Our parsing should be able to handle that.

For the buildpacks param, I think it'd be ok to ignore it for now, with a warning. And in cases where the auto-detection / defaults work, people can then use the button. E.g. if the button doesn't work because of our lack of support, then people should add the button to their repo.

[ahmetb]

So required should be a boolean everywhere, in that case we shouldn't try to handle string for sure.

@SudharakaP are you able to deploy and run after deleting buildpacks field, and making required field a boolean as spec says?

[jamesward]

I'm guessing is actually not going to work because it is using a non-default buildpack. Maybe @jkutner can let us know if the https://github.com/jhipster/jhipster-registry-buildpack buildpack will work with the CNB heroku/buildpacks image.

[SudharakaP]

@ahmetb : After changing required to boolean and deleting the buildpacks field and trying to run; I get the following error;

sudharakapalamakumbura@cloudshell:~$ cloudshell_open --repo_url "https://github.com/SudharakaP/jhipster-registry.git" --git_branch "add-gcp-cloud-run-deploy-button"
[ ✓ ] Cloned git repository https://github.com/SudharakaP/jhipster-registry.git.
[ ? ] Value of JHIPSTER_PASSWORD environment variable (Admin password for the registry (used to login after clicking 'View App'). Must be at least 5 characters.) jhipster
[ ? ] Value of JAVA_OPTS environment variable (Java runtime options.) -Xmx300m -Xss512k -XX:CICompilerCount=2 -XX:ReservedCodeCacheSize=50m -XX:MaxMetaspaceSize=80m -XX:ParallelGCThreads=3 -Dfile.encoding=UTF-8
[ ? ] Value of SPRING_OPTS environment variable (Spring Boot options.) --server.undertow.io-threads=1 --server.undertow.eager-filter-init=false
[ ? ] Value of JHIPSTER_REGISTRY_VERSION environment variable (Version of the registry to deploy.) 5.0.2
[ ✓ ] Queried list of your GCP projects
[ ? ] Would you like to use existing GCP project jhipstergaemicro to deploy this app? Yes
[ ✓ ] Enabled Cloud Run API on project jhipstergaemicro.
[ ? ] Choose a region to deploy this application: us-central1
[ ! ] Attempting to build this application with its Dockerfile...
[ ! ] FYI, running the following command:
        docker build -t gcr.io/jhipstergaemicro/JHipster Registry .
[ ✖ ] Failed to build container image.
Error: this application doesn't have a Dockerfile; attempted to build it via heroku/buildpacks and failed: docker build failed: exit status 125, output:
invalid argument "gcr.io/jhipstergaemicro/JHipster Registry" for "-t, --tag" flag: invalid reference format: repository name must be lowercase
See 'docker build --help'.

sudharakapalamakumbura@cloudshell:~$

[jamesward]

This is because you need the custom buildpack to build this project.

[SudharakaP]

@jamesward : So if I understand correctly, app.json in cloud run currently doesn't support custom buildpacks? Trying to understand if there's a way we could get around this one. 🤔

[ahmetb]

The string JHipster comes from app.json > name field (Or repo name), no?

[jamesward]

@SudharakaP Correct, Cloud Run Button doesn't support custom buildpacks defined by app.json yet.
@ahmetb The name is unrelated. There is a custom buildpack defined that is needed to build the jhipster stuff.

I think a workaround for this would be to use a Dockerfile for the build. But we might still run into app.json parsing issues, which we should fix.

[SudharakaP]

@ahmetb : Actually I think you are right; I changed the name field to all lowercase and also changed the PORT to point to the PORT environment variable and this makes it deploy successfully. However it prints out he following error in the log when trying to authenticate.

2019-11-25 21:16:52.914 PST Container Sandbox Limitation: Unsupported syscall setsockopt(0x24,0x1,0xa,0x3e88bb822150,0x4,0x0). Please, refer to https://gvisor.dev/c/linux/amd64/setsockopt for more information.

2019-11-25 21:16:52.927 PST POST 403 434 B16 msChrome 78 https://jhipster-registry-gv3mz4r7ta-uc.a.run.app/api/authenticate

I think this is because of a limitation of the container sandbox. I am trying to see if I could do the same thing on Anthos (where there's no container sandbox). Is the Cloud Run button supports deploying on Anthos as well?

@jamesward : Thanks much for confirming; I am new to Cloud Run and learning as I go along. 😄

[ahmetb]

The “syscall not supported” log is actually an info/warning. It does not mean your app is failing. Is your app actually throwing an exception? If not, it means it’s probably working fine.