This PR changes the format of CUE codegen, moving from reading all top-level CUE selectors as kinds to reading a single manifest top-level field (or a different name if supplied). Other top-level fields are ignored, allowing kinds to still be defined as root-level keys, but they will only be parsed for codegen if listed in the kinds field in the manifest.
This change is required to properly generate a manifest that
enforces that all kinds for an app have the same group (group is now a manifest-level attribute, and if it is specified in the kind, it must match the full computed API group for the manifest)
allows for specifying permissions required for the app operator
Ensures that all kinds for an app are now API resources (the model type has been fully removed)
There are some slight changes around writing a kind, namely that the fields previous in apiResource are either moved into the main body of the kind, or into the manifest itself, as all kinds are now always API resources.
apiResource.scope is now just scope
apiResource.validateion is now just validation
apiResource.mutation is now just mutation
apiResource.conversion is now just conversion
apiResource.groupOverride is now in the manifest, as manifest.groupOverride, as it will apply to all kinds for the manifest
The grafana-app-sdk project init command now generates a kinds/manifest.cue with a basic manifest, and grafana-app-sdk project kind add still creates a kind CUE file, but now also adds the kind to the list of kinds in manifest.cue, found under manifest.kinds.
In the codegen package, jennies may use codegen.Kind or codegen.AppManifest as their input, to allow for not requiring too much change there. The cuekind.Parser now doesn't implement codegen.Parser[codegen.Kind] itself, and instead has methods to get a parser that implements either codegen.Parser[codegen.Kind] or codegen.Parser[codegen.AppManifest]. This is likely an intermediary step as we continue to improve the codegen pipeline's structure. This PR aims mainly to change the input type of --format=cue to use the manifest, and define that manifest properly, with a low-impact changes as possible to the rest of the project.
What this PR Does
This PR changes the format of CUE codegen, moving from reading all top-level CUE selectors as kinds to reading a single
manifest
top-level field (or a different name if supplied). Other top-level fields are ignored, allowing kinds to still be defined as root-level keys, but they will only be parsed for codegen if listed in thekinds
field in the manifest.This change is required to properly generate a manifest that
group
is now a manifest-level attribute, and if it is specified in the kind, it must match the full computed API group for the manifest)model
type has been fully removed)There are some slight changes around writing a kind, namely that the fields previous in
apiResource
are either moved into the main body of the kind, or into the manifest itself, as all kinds are now always API resources.apiResource.scope
is now justscope
apiResource.validateion
is now justvalidation
apiResource.mutation
is now justmutation
apiResource.conversion
is now justconversion
apiResource.groupOverride
is now in the manifest, asmanifest.groupOverride
, as it will apply to all kinds for the manifestThe
grafana-app-sdk project init
command now generates akinds/manifest.cue
with a basic manifest, andgrafana-app-sdk project kind add
still creates a kind CUE file, but now also adds the kind to the list of kinds inmanifest.cue
, found undermanifest.kinds
.In the
codegen
package, jennies may usecodegen.Kind
orcodegen.AppManifest
as their input, to allow for not requiring too much change there. Thecuekind.Parser
now doesn't implementcodegen.Parser[codegen.Kind]
itself, and instead has methods to get a parser that implements eithercodegen.Parser[codegen.Kind]
orcodegen.Parser[codegen.AppManifest]
. This is likely an intermediary step as we continue to improve the codegen pipeline's structure. This PR aims mainly to change the input type of--format=cue
to use the manifest, and define that manifest properly, with a low-impact changes as possible to the rest of the project.