With the deprecation of Container Registry, it's probably useful to share the Artifact Registry hosted image, rather than the Container Registry one: us-docker.pkg.dev/cloudrun/container/hello

With the new design, the main call to action (take the quickstart) is now below the fold and not very visible on a standard screen.

See

CC @code128 @chemichelle

Hello,

My name is Alexie

I have a suggestion:

when browsing, for example, when you press a button, that section suddenly appears in front of you. I think that the transition property should be added, below is a code that I think should be added, so that the user does not get "scared" of what appears in front of him and plus that google should have the latest elements design and without upset, but it looks quite old... But if you add the transitions, then it will look more compact and newer.

transition: all .3s ease-in-out;

I hope I was helpful, this is just a personal opinion...

With the new design (c45d502), we seem to have lost some accessibility points in the Lighthouse score: Before we were at 90, now we are at 66. (you can access it under "Audit" in Chrome Devtools).

It's mainly due to contrast ratio and alt on images

We should aim for 100.

CC @code128 @chemichelle

Let's respect developers' eyes and add a dark variant of the congrats webpage.

Sprinkle some @media (prefers-color-scheme: dark)

Hi folks!

When deploying this service on Cloud Run, the $PORT is printed as a literal in the log:

2024/04/17 14:13:36 Hello from Cloud Run! The container started successfully and is listening for HTTP requests on $PORT

Shall this be formatted?

Thanks for your support!

can the static resources be embedded and then used for the templating at runtime.

this would make things much easier to deploy and developer

This sample depends on github.com/cloudevents/sdk-go/v2 and has a lot of logic to parse CloudEvent.

This is source of potential vulnerability and code complexity.

It's unclear that this sample still needs to be able to handle CloudEvent.

We should figure out if it is used in any EventArc sample or if it used to demo EventArc.

If not, we should remove this dependency and code.

"Congrats" may be less understandable to non-English speakers.

I'm getting an error trying to build the container:

Status: Downloaded newer image for golang:latest
 ---> f50db16df5da
Step 2/8 : WORKDIR /go/src/cloudrun/hello
 ---> Running in ab656f83f629
Removing intermediate container ab656f83f629
 ---> 1c24f8f8b0ae
Step 3/8 : COPY . .
 ---> bc287b53a41a
Step 4/8 : RUN CGO_ENABLED=0 GOOS=linux go build -v -o hello
 ---> Running in 59ed5289c668
net
crypto/x509
crypto/tls
net/textproto
internal/x/net/http/httpguts
internal/x/net/http/httpproxy
net/http/httptrace
net/http
cloudrun/hello
Removing intermediate container 59ed5289c668
 ---> 11d2c8ad490f
Step 5/8 : FROM marketplace.gcr.io/google/ubuntu1804:latest
unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

In porting this sample for other uses, I found it valuable to revise the go code. I'm happy to port those improvements back here:

• Reflow code for clarity and performance
• Add error handling
• Use metadata client library

Something terrible is happening. After building and pushing image I get panic as below.

I can make new revision from pushed image in Cloud Run Console and everything works OK.

[ ✓ ] Pushed container image to Google Container Registry.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x87b8af]

goroutine 1 [running]:
main.optionsToFlags(...)
        /src/cmd/cloudshell_open/cloudrun.go:37
main.run(0x7ffd00e04221, 0x2d, 0x0, 0x0, 0x0, 0x0, 0xa6e1e0, 0xc000198710)
        /src/cmd/cloudshell_open/main.go:300 +0x198f
main.main()
        /src/cmd/cloudshell_open/main.go:81 +0x207r ``

BTW: I find this error a happy coincidence as it stops and lets me play with Docker image before publishing new revision.

With the new design (c45d502), the main image is not inlined in the HTML, thus requiring a subsequent request to be downloaded.

However, browsers start to render the page as soon as they have the HTML (and before the image is fully downloaded), leading to a layout refresh once it is downloaded. See the issue in this animation:

This is a common issue with websites, the effect can be mitigated by providing the the exact size or the aspect ratio via CSS or img attributes

I can help with that.

CC @code128 @chemichelle

I want to create 3 services with different environment variables from the same google container image. Is it possible?
Currently i'm using functions framework to create the docker image(by adding start script to package.json).

Unfortunately, its not letting me to specify any other name for service other than the function name i used in the functions framework target.

"start": "functions-framework --target=app --signature-type http"

In the above command, app is my exported function name.

When I deploy service name with ZZZ instead of app, it fails with below error.

Function 'app' is not defined in the provided module.
Did you specify the correct target function to execute?
Could not load the function, shutting down.

If i deploy with service name as app, it works fine.

Can someone suggest on how to solve this?

Steps to reproduce:

gcloud container clusters create cluster-1 \
  --addons=HttpLoadBalancing,CloudRun \
  --machine-type=n1-standard-2 \
  --enable-stackdriver-kubernetes \
  --region=us-central1 \
  --node-locations=us-central1-a

gcloud config set run/cluster cluster-1
gcloud config set run/cluster_location us-central1

gcloud run deploy hello --image gcr.io/cloudrun/hello --platform gke

export GW_IP=$(kubectl get svc -n gke-system istio-ingress | grep istio-ingress | awk '{ print $4}')

curl -s -H "Host: hello.default.example.com" $GW_IP

That curl returns the following:

                        <p>

                                        This container <strong>does not</strong> seem to be running
                                        on Cloud Run.

                        </p>
                   

In previous versions of this image ~6 months ago, the exact same steps did not return This container does not seem to be running on cloud run. So something must have changed on the Cloud Run side or in this image.

Now that Cloud Run supports traffic splits, we often need a demo container ro demo blue/green deployment.

What I usually do is I take a go hello world that display the value of an env var (if present), and I set it to "blue" and "green" in two revisions for my demo.

It could be useful to have this container do the same, so that we don't even need to build one.

One word of the text could change based on this env var for example

At

This is no longer necessary as default installations of Cloud Run on a GKE cluster do not have this issue.

We could clean up this part.

In porting this sample for other uses, I implemented a CI/CD pipeline using Cloud Build. Not sure if I can setup the trigger here but happy to relay the necessary configuration and test code here.

We can start from Ubuntu 22 container if we move over to google-22 tag. documentation https://cloud.google.com/docs/buildpacks/builders

We use one system to create a cloud run service using the placeholder image, and another system to build our own images and create new revisions of the cloud run service using the newly built images. At the moment, the first revision always fails to start because we pass the args for our own image, and the placeholder image is failing to deploy with those:

terminated: Application failed to start: invalid status ::14: could not start container: "--[REDACTED]" not found in PATH [/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin]: no such file or directory

I think if the placeholder image specified an ENTRYPOINT instead of a CMD, it would run the placeholder code correctly instead of trying to execute the first argument. Then could the placeholder also just ignore any unknown arguments? That way we could spin up the services using the placeholder image without error, then just change out the image later.