Support Cloud Run Job

[ren510dev]

What happened:

When trying to deploy a Cloud Run Job with PipeCD, the following error is returned: spec.template.spec.containers was missing

It appears that the current implementation of PipeCD only supports deploying Cloud Run Services, which follows the format of spec.template.spec.containers.

• https://github.com/pipe-cd/pipecd/blob/b5d9fc976d26000f08c8ab3e3927d4f674f1d595/pkg/app/piped/platformprovider/cloudrun/servicemanifest.go#L169-L174

However, Cloud Run Jobs use a different structure for the container specification: spec.template.spec.template.spec.containers. As a result, PipeCD does not handle the second-level template.spec required for Jobs, the deployment fails.

What you expected to happen:

Both Cloud Run Services and Jobs can be deployed using PipeCD.

How to reproduce it:

Prepare a manifest for a Cloud Run Job and try to deploy it using PipeCD.

ex.

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
  name: sample-job
  namespace: sample-ns
spec:
  template:
    metadata:
      labels:
        name: sample-job
      annotations:
        run.googleapis.com/client-name: gcloud
        run.googleapis.com/client-version: 510.0.0
        run.googleapis.com/execution-environment: gen2
    spec:
      taskCount: 1
      template:
        spec:
          containers:
            - image: your-image

Environment:

• piped version: v0.51.2
• control-plane version: v0.51.2

[niladrix719]

hey @khanhtc1202, can I get assigned to this issue

[t-kikuc]

We need an investigation in advance because it's so complicated and deep.

I guess CloudRun jobs were initially not considered.

Affected Area

As far as I come up with now, there're several areas to modify:

• Manifest paths like spec.template.spec.template.spec.containers. (as the top thread)
• Many cloudrun codes depending on the type ServiceManifest https://github.com/pipe-cd/pipecd/blob/39989f983a8988b2f50d6ee3c130ead16e19a03e/pkg/app/piped/platformprovider/cloudrun/servicemanifest.go#L30
• CloudRun stages
• app.pipecd.yaml
  • c.f. ECS Standalone tasks (like CloudRun jobs) have different config which are not used in services. https://pipecd.dev/docs-v0.51.x/user-guide/configuration-reference/#ecsdeploymentinput

Possible Ways

• A. Support in current form
  • It might cause a lot of bugs in jobs and services, which leads to longer reviewing/testing.
• B. Support as a new Plugin
  • The Code will be so simple, but you can't use jobs until Plugin-PipeCD is released

I would like to hear your opinion and investigation.

[t-kikuc]

@niladrix719 If you want to investigate, I'll assign you

[niladrix719]

sure @t-kikuc

[khanhtc1202]

I think the plugin would support this well, and making Cloud Run and Cloud Run Job independent plugins could help avoid many potential bugs due to the complicated codebase. Another way to deal with this is to create Cloud Run Job stages separated from Cloud Run stages. Since the pipedv0 (not plug-in piped) executes stages independently, it's better to make those plugins' stages different if we go with Cloud Run / Cloud Run Job plugins independently. So, my option is

• Making Cloud Run / Cloud Run Job plugin independent
• In the meantime, if it's required to use Cloud Run Job with pipedv0, we should make it by introducing new Cloud Run stages, not manipulating or changing the previous one. And some features could be unsupported because they complicate the current pipedv0 Cloud Run platform provider.

WDYT?

[ren510dev]

@khanhtc1202

Thank you for your comment, I think the plugin-based approach is an excellent idea!

Regarding the current implementation: I see that it assumes only Cloud Run Services for now and introduces servicemanifest.go. Have you considered supporting other resource types as well, such as Jobs, by adding a separate jobmanifest.go or a similar implemetation?

[t-kikuc]

we should make it by introducing new Cloud Run stages,

I think it's tough too because we still need to upgrade the planner of cloudrun...

Have you considered supporting other resource types as well, such as Jobs, by adding a separate jobmanifest.go or a similar implementation?

yeah, but I found the issue is not only the manifest... It would be like creating a new Kind like Azure Function...

[ren510dev]

I see, I now understand the current implementation status. A plugin architecture seems to offer a more packaged solution that could help address these issues!

[t-kikuc]

@niladrix719 Sorry, I'll support Jobs as a plugin