bug(cloudrun): parseContainerImage fails to parse images with registry ports

[zyzzmohit]

What happened:
In pkg/app/piped/platformprovider/cloudrun/servicemanifest.go, the parseContainerImage function naively splits the image string by : to extract the image tag. However, if a user relies on a container image hosted in a registry that specifies a port (e.g., localhost:5000/repo/image:tag or my-registry.com:8443/app:v1), the function incorrectly splits the URI. This results in a misparsed name and an empty tag.

This causes functions like FindImageTag and FindArtifactVersions to return incorrect values or fail during a Cloud Run deployment pipeline if custom registry ports are used in the service manifest.

What you expected to happen:
The function should correctly isolate the registry/repository from the tag, utilizing a more robust parsing strategy (such as checking strings.LastIndex for the tag colon, or using a dedicated image parsing library) to safely accommodate registry ports.

How to reproduce it:
Running the existing parseContainerImage logic against an image with a port yields incorrect results:

n, t := parseContainerImage("localhost:5000/pipecd/helloworld:v0.1.0")
// Expected: Name: helloworld, Tag: v0.1.0
// Actual: Name: localhost, Tag: (empty)

[khanhtc1202]

Good catch, do you mind sending a patch for the fix?

[zyzzmohit]

Thanks @khanhtc1202 I just opened PR #6572 earlier today with the fix and added comprehensive unit test coverage. Let me know if you'd like any changes to the implementation :)

[armistcxy]

Theoretically, your point is valid based on how the function should work when the registry port is specified. But after checking Google Cloud Docs I find this part in Supported container registries and images:

You can directly use container images stored in Artifact Registry, or Docker Hub
You can use container images from other public or private registries (like JFrog Artifactory, Nexus, or GitHub Container Registry), by setting up an Artifact Registry remote repository.

Which I believe the edge case you describe is impossible to happen because these allowed registries don't need to specify registry port, but your point is still good though

[zyzzmohit]

Thanks @armistcxy for the insight, you are absolutely right that Cloud Run's current registry support makes this edge case practically impossible in a real deployment scenario today

I mainly noticed this parsing discrepancy while studying the codebase and felt that utilizing strings.LastIndex makes the parseContainerImage utility strictly follow standard Docker URI formats, which is safer as a defensive programming measure in case Cloud Run or PipeCD ever expands registry support in the future

I appreciate you taking the time to review the context