xpkg build: GoTemplate function input kind field buried after large block scalar due to JSON key reordering

crossplane-runtime/pkg/xpkg/build.go の encode() から始め、埋め込まれた RawExtension.Raw の JSON が YAMLToJSON() を介してどのようにシリアライズされるかを追ってください。xpkg build で問題を再現し、package.yaml を調べてください。次に、apiVersion と kind が大きな inline.template ブロックの前に並んで現れること、およびビルドされたパッケージが正常にインストールされることを確認してください。

Describe the bug

`crossplane xpkg build` reorders fields in embedded `RawExtension` objects alphabetically (via `sigs.k8s.io/yaml.YAMLToJSON()`) during YAML serialization. For a `function-go-templating` pipeline step input, this buries `kind: GoTemplate` after the entire `inline.template` block scalar — which can be hundreds or thousands of lines long.

Some YAML parsers and the Crossplane package reader fail to correctly handle a `kind` field that appears after a very large literal block scalar, causing installed ConfigurationRevisions to fail with:

spec.pipeline[N].input.kind: Required value

This became visible with Crossplane v2.2.0, which added strict validation requiring `kind` in all pipeline step inputs. See crossplane/crossplane#7819.

Root cause

The `encode()` function in `crossplane-runtime/pkg/xpkg/build.go` re-serializes all package objects through the Kubernetes JSON serializer:

1. Source YAML is parsed → stored as `*v1.Composition` with `Input.Raw` = JSON bytes
2. `sigs.k8s.io/yaml.YAMLToJSON()` converts the YAML map to JSON with alphabetically sorted keys
3. Original YAML field order: `apiVersion → kind → source → inline`
4. JSON (and final YAML) field order: `apiVersion → inline → kind → source`

Result in `package.yaml`:

```yaml
input:
apiVersion: gotemplating.fn.crossplane.io/v1beta1
inline:
template: |
{{- ... hundreds of lines of go template ... }}
kind: GoTemplate # ← buried after the block scalar
source: Inline
```

Steps to reproduce

1. Create a Composition with a `function-go-templating` step whose `inline.template` is >100 lines
2. Run `crossplane xpkg build`
3. Extract `package.yaml` from the built `.xpkg`:

   tar xf package.xpkg
   tar xzf <layer>.tar.gz
   

4. Search for `kind: GoTemplate` — it is present but appears after the entire template block, not next to `apiVersion:`
5. Install the package on a Crossplane v2.2.0+ cluster → ConfigurationRevision fails

Expected behaviour

`kind: GoTemplate` appears adjacent to `apiVersion: gotemplating.fn.crossplane.io/v1beta1` in the serialized `package.yaml`, matching the source file and ensuring reliable parsing.

Suggested fix

In `crossplane-runtime/pkg/xpkg/build.go`, modify `encode()` to re-order keys in `RawExtension.Raw` JSON so that TypeMeta fields (`apiVersion`, `kind`) appear first before emitting. Concretely: after marshaling each object to JSON, walk any embedded `RawExtension` fields and produce a new JSON object with `apiVersion`/`kind` promoted to the front.

An alternative is to add a normalization pass in the `xpkg build` command (`cmd/crossplane/xpkg/build.go`) after `c.builder.Build()` — extract `package.yaml` from the built image, re-insert `kind`/`apiVersion` immediately after each other in embedded resource blocks, and rebuild the layer.

Workaround

Post-process the built `.xpkg` to insert `kind: GoTemplate` immediately after each `apiVersion: gotemplating.fn.crossplane.io/v1beta1` line. This is what the affected package repo currently does as a stop-gap.

Related

• crossplane/crossplane#7819 — Crossplane v2.2.0 added the `kind` validation requirement that surfaces this bug