spinnaker: 'List' based Kubernetes Manifests Not Supported

Issue Summary:

Missing required field ‘metadata’ on manifest reported for k8s ‘*List’ manifests.

Cloud Provider(s):

GKE (Kubernetes v2)

Environment:

Any

Feature Area:

Pipelines

Description:

Using a helm chart which produces resources such as “ConfigMapList”, “RoleList”. “RoleBindingList” etc and try to deploy baked images will result in “Missing required field ‘metadata’ on manifest” error which is not part of the Spec for these resources.

Steps to Reproduce:

Try to deploy a baked chart with these resources. i.e.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBindingList
items:
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: prometheus-operator-prometheus
    labels:
      app: prometheus-operator-prometheus
...

Additional Details:

https://github.com/spinnaker/spinnaker/issues/4534 is the same issue but it’s closed as a workaround was performed. This doesn’t address the issue that Spinnaker cannot determine these resources do not require metadata fields.

---

Please delete the instructions below this line prior to submitting

Instructions:

• An issue is not a place to ask questions. Please use Slack or Stack Overflow.
• Before you open an issue, please check if a similar issue already exists or has been closed before.
• Make sure you have read through the Spinnaker FAQ and Halyard FAQ to provide as much information as possible.

Descriptions:

• Issue Summary: A brief description of what you’re seeing.
• Cloud Provider: AWS, GCP, Kubernetes, Azure, Cloud Foundry, etc. Please assign a label from the right so your issue can be properly sorted.
• Environment: As much information about your Spinnaker environment and configuration that might be relevant to the issue. For example: “I am running Spinnaker using the Amazon images to deploy into AWS and GCP.”
• Feature Area: Notifications, Pipelines, UI, Jenkins, etc. Please assign a label from the right so your issue can be properly sorted.
• Description: The behavior you expect to see, and the actual behavior.
• Steps to reproduce: Ideally, an isolated way to reproduce the behavior (example: GitHub repository with code isolated to the issue that anyone can clone to observe the problem). If not possible, as much information as possible to see this behavior.
• Additional Details: Additional information such as screenshots and exception logs.