@tmcg-gusto the custom registry will be injected at build time right? I see the appeal but as far as Kubeconform is concerned I'm not sure if I would want to provide that... Do you really this need merged if you're going to need to build a custom build pipeline anyway?

@yannh Thanks for the reply!

We have it set up so that the schemas are all pulled with a go:generate script and then embeded into an embed.FS at build time.

At runtime we then create a registry that uses that embed.FS and pass the registry to kubeconform when we initialize the Validator.

Here's a rough estimate of what it looks like:

import (
  "embed"
  "github.com/yannh/kubeconform/pkg/registry"
  "github.com/yannh/kubeconform/pkg/validator"
}
//go:generate fetch_schema.sh
//go:embed schema/*
var k8sSchemaFS embed.FS


// Our custom registry struct
type EmbededRegistry struct {
	fs           fs.FS
	pathTemplate string
	strict       bool
}

// Implementation of the primary logic for the registry fetching from the embedded FS.
func (r EmbededRegistry) DownloadSchema(...) {
  ...   
  r.fs.Open(...)
  ... 
}

func main(){
  registries := []registry.Registry{EmbeddedRegistry {
     fs: k8sSchemaFS,
     pathTemplate: ...,
     strict: false
  }}
  validate, err := validator.New(nil, validator.Opts{Strict: true, Registries: registries, KubernetesVersion: "master"})
  for i, res := range validate.Validate(someFileName, fileHandle){
     // Handle results.
  }
}

Without the change in this PR, we would need to dump the schemas to disk before kubeconform reads them back after specifying the file location. This change allows us to skip that step and read directly from memory. We'll need to provide regular updates to our tool to keep the schemas up to date, but we already planned on making frequent releases.

The only thing kubeconform would be providing is access to customizing how the schemas are loaded and where they are loaded from.