Cannot deploy a docker image with its digest to Cloud Run.

[enomoto11]

What happened: If you specify a Docker image using the digest which has 64 characters and is calculated with SHA-256 algorithm as data in EventWatcher and configure the manifest side's service.yaml under piped monitoring to rewrite the container image deployed to the Cloud Run service in the handler, the service.spec.template.metadata.name can exceed 64 characters. As a result, this causes a BadRequest error and the deployment fails, as shown below.

[2025-03-17 12:10:58 +09:00]
Successfully prepared service manifest with traffic percentages as below:
[2025-03-17 12:10:58 +09:00]
  helloworld-1bd4d708f94fcfb58b51b3a0818edc52bcc079104fc0fa3347ff0f309f9ed8b2-ca1937a: 100
[2025-03-17 12:10:58 +09:00]
Start applying the service manifest
[2025-03-17 12:10:58 +09:00]
Failed to update the service helloworld (googleapi: Error 400: service.spec.template.metadata.name: only lowercase, digits, and hyphens; must begin with letter, and may not end with hyphen; must be less than 64 characters.
Details:
[
  {
    "@type": "type.googleapis.com/google.rpc.BadRequest",
    "fieldViolations": [
      {
        "description": "only lowercase, digits, and hyphens; must begin with letter, and may not end with hyphen; must be less than 64 characters.",
        "field": "service.spec.template.metadata.name"
      }
    ]
  }
]
, badRequest)

What you expected to happen: The deployment completes successfully even when the EventWatcher handler rewrites the Docker image with the digest.

How to reproduce it:

1. Configure app.pipecd.yaml so that the EventWatcher handler rewrites $.spec.template.spec.containers[0].image in service.yaml under the application's Application Directory.

2. In the CI workflow, execute actions-event-register with the corresponding name and labels, specifying the Docker image name using a digest as data in the EventWatcher matcher.

3. Verify that the event has been registered successfully.

4. Watch the log of the deployment.

Environment:

• piped version: v0.50.2
• control-plane version:v0.50.2
• Others:
  • actions-event-register version: v0.50.2

[ren510dev]

This issue stems from Cloud Run automatically determining the revision name based on the format <SERVICE-NAME>-<IMAGE-TAG OR HASH>-<RANDOM HASH>. Given the current specification, it is likely difficult to change the naming convention for Cloud Run revisions.

• https://github.com/googleapis/googleapis/blob/2b63b9276dca4d5046470fe5e1022bd982629f62/google/rpc/error_details.proto#L67-L76

// Additional structured details about this error.
//
// Keys must match a regular expression of `[a-z][a-zA-Z0-9-_]+` but should
// ideally be lowerCamelCase. Also, they must be limited to 64 characters in
// length. When identifying the current value of an exceeded limit, the units
// should be contained in the key, not the value.  For example, rather than
// `{"instanceLimit": "100/request"}`, should be returned as,
// `{"instanceLimitPerRequest": "100"}`, if the client exceeds the number of
// instances that can be created in a single (batch) request.
map<string, string> metadata = 3;

• https://stackoverflow.com/questions/72016498/add-a-custom-revision-name-or-change-a-default-revision-name-on-cloud-run-gcp

As an alternative, using the short git commit hash (git rev-parse --short HEAD) may help address this issue. Is there any concern with this approach?

Additionally, this might be related to the following issue: https://github.com/pipe-cd/pipecd/issues/5712

[ren510dev]

It seems that the Cloud Run Service revision name is determined by PipeCD.

• https://github.com/pipe-cd/pipecd/blob/7d4722fb9e741284b41149563fa16a34b1421c55/pkg/app/piped/platformprovider/cloudrun/servicemanifest.go#L156-L167

I think it's unnecessary to include the Cloud Run service name (i.e., the name field in service.yaml) in the revision name, because the service name is inherently part of every revision and is therefore implicitly clear.

Removing sm.Name could potentially resolve this issue.

However, as this may be a breaking change, careful consideration should be given. wdyt?

[ffjlabo]

Thank you for the idea 👍

I think it's unnecessary to include the Cloud Run service name (i.e., the name field in service.yaml) in the revision name, because the service name is inherently part of every revision and is therefore implicitly clear.

Removing sm.Name could potentially resolve this issue.

However, as this may be a breaking change, careful consideration should be given. wdyt?

It is a nice idea. We can reduce the length of the service name. Also, I agree with carefully considering that. We are currently working on developing a plugin mechanism, so we will revisit the specifications after that.