Skip to content

Extra Objects

extraObjects is a “last mile” escape hatch for rendering arbitrary Kubernetes resources that bb-common does not natively generate. Each item is a complete manifest that bb-common emits verbatim, so you can ship resources alongside a package without waiting for first-class support in the library.

It exists for cases like:

  • Resources bb-common has no dedicated abstraction for (e.g. a Secret, ConfigMap, ServiceAccount, or a vendor CRD).
  • Bootstrapping resources an application chart’s HelmRelease depends on.

Usage

Add a top-level extraObjects value. When bb-common is consumed as a subchart, nest it under the bb-common key.

extraObjects:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name: app-config
    data:
      LOG_LEVEL: info
      FEATURE_FLAGS: "beta"
  - apiVersion: v1
    kind: Secret
    metadata:
      name: app-credentials
    type: Opaque
    stringData:
      api-token: replace-me
  - apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: app-runner

Map form

extraObjects may also be a map keyed by an arbitrary name. This is preferable when values are layered across multiple files, because Helm deep-merges maps — so an operator can override or tweak a single entry by key without restating the whole list:

extraObjects:
  app-config:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: app-config
    data:
      LOG_LEVEL: info
  app-credentials:
    apiVersion: v1
    kind: Secret
    metadata:
      name: app-credentials
    stringData:
      api-token: replace-me

Map entries are rendered in sorted key order.

Library-chart mode

In library-chart (template) mode, include the render template from your chart:

# templates/bigbang/extra-objects.yaml
{{- include "bb-common.extra-objects.render" . }}

Behavior

  • Rendered as-is — resources are emitted exactly as written, aside from the provenance label below. bb-common does not inject a namespace, so cluster-scoped resources work too. For namespaced resources without an explicit metadata.namespace, the deploy tooling (Helm/Flux) applies them to the release namespace.
  • Provenance label — every rendered resource gets the standard extra-objects.bigbang.dev/source: bb-common label so it is easily identifiable as bb-common generated (mirroring the *.bigbang.dev/source labels used elsewhere in bb-common). Any labels you set are preserved and merged alongside it; the source label always wins on conflict.
  • Templating — each item is processed through tpl, so Helm expressions may be used inside a resource:
extraObjects:
  - apiVersion: v1
    kind: ConfigMap
    metadata:
      name: app-config
      namespace: "{{ .Release.Namespace }}"
    data:
      release: "{{ .Release.Name }}"
  • No wrapping or validation — because the manifests are passed straight through, you are responsible for their correctness. Prefer the dedicated frameworks (network policies, routes, authorization policies) when they can express what you need; reach for extraObjects when you feel you have no other option.