feat: validate official Kubernetes module values and provider defaults
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 62/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- ruby
- Área
- backend, infrastructure
Línea de trabajo
Start from the module rendering path that already loads module defaults, and locate where each official Kubernetes module's schema.yaml is declared so validation can run before Helm rendering. Then find where provider defaults are stored and how the precedence hierarchy is documented, and wire them into the existing rendering flow for the selected provider only. Add tests covering valid values, invalid values (asserting the error names the module and value path), defaults precedence, and client overrides, plus a regression run over the existing DigitalOcean manifests to confirm they still render.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Context
The Kubernetes module contract documents strict schemas for official modules and a defaults hierarchy that includes provider defaults. Current platform rendering loads module defaults, but does not apply schema.yaml to module values or load provider defaults through the normal rendering path. This leaves the documented module contract unenforced.
Scope
- Validate values for official Kubernetes modules against their declared
schema.yamlbefore rendering. - Apply provider defaults in the documented precedence order for the selected provider.
- Keep error messages actionable and identify the module and invalid value path.
- Add coverage for valid values, invalid values, defaults precedence, and client overrides.
Acceptance criteria
- Invalid official module values fail validation before Helm rendering.
- Provider defaults are applied only for the selected provider and are overridden according to the documented precedence.
- Existing supported DigitalOcean platform manifests continue to render successfully.
- Lenguaje dominante
- Ruby
- Estrellas
- 0
- Forks
- 0
- Merge medio
- 11 h 37 min
- PR fusionados (30 d)
- 35
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de opsd-io/opsd-cli
-
area: cli enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
area: cli enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
area: cli enhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
area: cli enhancement
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
area: modules enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
Todos los issues de opsd-io/opsd-cli
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
seek4science/seek#2762 ·
Los mantenedores suelen responder en 5 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
rubyevents/rubyevents#2277 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 92/100
Los mantenedores suelen responder en 2 días