shuss/vynil
1
0
Code Issues 15 Packages Projects Wiki

Test: values section in Test YAML not applied to context.values during template generation #19

New Issue
Open
opened 2026-06-14 22:11:24 +02:00 by xmortelette · 4 comments
xmortelette commented 2026-06-14 22:11:24 +02:00
Copy Link

Description

La section values: d'un fichier Test (kind: Test) n'est pas appliquée à context.values.* (ni à values.* dans les templates Handlebars) lors de l'exécution des tests déclaratifs. Le moteur utilise systématiquement les valeurs par défaut définies dans package.yaml, quelle que soit la surcharge déclarée dans le fichier de test.

Reproduction minimale

Package (package.yaml)

options:
  toolsets:
    type: string
    default: ""

Template (others/ConfigMap_envs.yaml.hbs)

data:
  GITHUB_TOOLSETS: "{{values.toolsets}}"

Script Rhai (scripts/context_extra.rhai)

fn run(_instance, context) {
    #{
        github_host: context.values.github_url,
    }
}

Test (tests/full.yaml)

apiVersion: vinyl.solidite.fr/v1beta1
kind: Test
metadata:
  name: full
instance:
  name: github-mcp
  namespace: mytest-apps
testSets:
- testSet: tenant
  variables:
    tenant: mytest
    use_sso: true
    ha: true
values:
  toolsets: "repos,issues,pull_requests"
  github_url: "https://github.example.com"
asserts:
- name: GITHUB_TOOLSETS est surchargé par le test
  selector:
    kind: ConfigMap
    name: "{{instance.appslug}}-envs"
  value:
    data:
      GITHUB_TOOLSETS: "repos,issues,pull_requests"
  matcher:
    exact: 1

Résultat observé

Test: full
  [FAIL] GITHUB_TOOLSETS est surchargé par le test: 0/1 match
  ConfigMap/mytest-apps/github-mcp-envs: .data.GITHUB_TOOLSETS: expected "repos,issues,pull_requests", got ""

La valeur générée est "" (le défaut de package.yaml), pas "repos,issues,pull_requests".

Même comportement via context.values.* dans Rhai : context.values.github_url retourne "https://github.example.com" (défaut du package), pas la valeur surchargée dans le test.

Résultat attendu

Test: full
  [PASS] GITHUB_TOOLSETS est surchargé par le test: 1/1 match

Le test doit générer le template avec les valeurs déclarées dans values:, de la même façon qu'une instance déployée avec ces options.

Environnement

  • vynil-agent : 0.7.5 (image docker.io/sebt3/vynil-agent:0.7.5)
  • Commandes concernées : make <pkg> template, make <pkg> test, make <pkg> lint

Impact

Les fichiers Test avec plusieurs scénarios (default.yaml, full.yaml, ha-*.yaml, sso-*.yaml) ne peuvent pas tester le comportement du package avec des options différentes des défauts. Seules les valeurs par défaut sont couvertes, quelle que soit la surcharge dans le test. Cela rend les scénarios de test full / ha / sso peu utiles pour valider les options spécifiques à ces scénarios.

## Description La section `values:` d'un fichier `Test` (kind: Test) n'est pas appliquée à `context.values.*` (ni à `values.*` dans les templates Handlebars) lors de l'exécution des tests déclaratifs. Le moteur utilise systématiquement les valeurs par défaut définies dans `package.yaml`, quelle que soit la surcharge déclarée dans le fichier de test. ## Reproduction minimale ### Package (`package.yaml`) ```yaml options: toolsets: type: string default: "" ``` ### Template (`others/ConfigMap_envs.yaml.hbs`) ```yaml data: GITHUB_TOOLSETS: "{{values.toolsets}}" ``` ### Script Rhai (`scripts/context_extra.rhai`) ```rhai fn run(_instance, context) { #{ github_host: context.values.github_url, } } ``` ### Test (`tests/full.yaml`) ```yaml apiVersion: vinyl.solidite.fr/v1beta1 kind: Test metadata: name: full instance: name: github-mcp namespace: mytest-apps testSets: - testSet: tenant variables: tenant: mytest use_sso: true ha: true values: toolsets: "repos,issues,pull_requests" github_url: "https://github.example.com" asserts: - name: GITHUB_TOOLSETS est surchargé par le test selector: kind: ConfigMap name: "{{instance.appslug}}-envs" value: data: GITHUB_TOOLSETS: "repos,issues,pull_requests" matcher: exact: 1 ``` ### Résultat observé ``` Test: full [FAIL] GITHUB_TOOLSETS est surchargé par le test: 0/1 match ConfigMap/mytest-apps/github-mcp-envs: .data.GITHUB_TOOLSETS: expected "repos,issues,pull_requests", got "" ``` La valeur générée est `""` (le défaut de `package.yaml`), pas `"repos,issues,pull_requests"`. Même comportement via `context.values.*` dans Rhai : `context.values.github_url` retourne `"https://github.example.com"` (défaut du package), pas la valeur surchargée dans le test. ### Résultat attendu ``` Test: full [PASS] GITHUB_TOOLSETS est surchargé par le test: 1/1 match ``` Le test doit générer le template avec les valeurs déclarées dans `values:`, de la même façon qu'une instance déployée avec ces options. ## Environnement - `vynil-agent` : `0.7.5` (image `docker.io/sebt3/vynil-agent:0.7.5`) - Commandes concernées : `make <pkg> template`, `make <pkg> test`, `make <pkg> lint` ## Impact Les fichiers `Test` avec plusieurs scénarios (`default.yaml`, `full.yaml`, `ha-*.yaml`, `sso-*.yaml`) ne peuvent pas tester le comportement du package avec des options différentes des défauts. Seules les valeurs par défaut sont couvertes, quelle que soit la surcharge dans le test. Cela rend les scénarios de test `full` / `ha` / `sso` peu utiles pour valider les options spécifiques à ces scénarios.
xmortelette commented 2026-06-14 22:18:34 +02:00
Author
Copy Link

Analyse et plan de correction

Commentaire rédigé par Claude Sonnet 4.6 (IA)

Cause racine

Le bug est double — une clé YAML inexistante + un bug dans le script Rhai.

1. Le YAML de test utilise values: au niveau racine — clé inexistante

Le struct VynilTest (agent/src/testing/vyniltest.rs) ne déclare pas de champ values: au niveau racine. Serde ignore silencieusement les clés inconnues : la section values: du fichier de test est donc jetée à la désérialisation.

La clé correcte est instance.options:, qui existe déjà dans VynilTestInstance :

pub struct VynilTestInstance {
    pub name: String,
    pub namespace: String,
    pub options: Option<BTreeMap<String, serde_json::Value>>,  // ← ici
}

Le YAML du test devrait être :

instance:
  name: github-mcp
  namespace: mytest-apps
  options:                                  # ← pas un `values:` au niveau racine
    toolsets: "repos,issues,pull_requests"
    github_url: "https://github.example.com"

Pourquoi instance.options: fonctionne déjà pour make test

La chaîne complète est câblée :

  1. get_templated_test() (handler.rs ~381) lit test.instance.options et l'injecte dans spec.options du mock K8s (TenantInstance / SystemInstance / ServiceInstance).
  2. Rhai appelle get_tenant_instance(ns, name) → retrouve ce mock avec spec.options renseigné.
  3. ctx::run(instance, args) → build_context.rhai::run() → get_values(instance.spec.options, defaults) → les valeurs surchargées sont utilisées. ✓

2. build_context.rhai::template() ignore instance.spec.options — bug réel pour make template

La fonction template() (utilisée par make <pkg> template) passe une map vide ligne 288 :

values: get_values(#{}, defaults),   // ← #{} = toujours les défauts

Alors que la fonction run() (chemin de test) fait correctement :

values: get_values(instance.spec.options, defaults),

Ce bug affecte make template et make lint mais pas make test (qui passe par run()).

Plan de correction

Étape 1 — Documenter instance.options: (priorité haute)

Mettre à jour docs/tooling/test.md avec un exemple complet montrant instance.options: et son effet sur context.values / les templates :

# tests/full.yaml
apiVersion: vinyl.solidite.fr/v1beta1
kind: Test
metadata:
  name: full
instance:
  name: github-mcp
  namespace: mytest-apps
  options:                                   # surcharge des options du package
    toolsets: "repos,issues,pull_requests"
    github_url: "https://github.example.com"
testSets:
  - testSet: tenant
    variables:
      tenant: mytest

Préciser que :

  • instance.options: équivaut à spec.options d'une instance K8s réelle.
  • Ces valeurs sont fusionnées avec les defaults de package.yaml via get_values().
  • context.values.toolsets dans les scripts Rhai et {{values.toolsets}} dans les templates reflètent bien les valeurs surchargées.

Étape 2 — Corriger build_context.rhai::template() (TDD)

Écrire d'abord un test qui échoue : make <pkg> template avec instance.options: → la sortie doit contenir la valeur surchargée.

Puis corriger ligne 288 :

// avant
values: get_values(#{}, defaults),
// après
values: get_values(instance.spec.options, defaults),

Étape 3 — Supprimer le code mort dans run_test_inner()

Les lignes 554-568 de handler.rs construisent un instance_json qui n'est jamais transmis à Rhai (le rhai.set_dynamic est commenté ligne 569). Ce bloc peut être supprimé.

Fichiers impactés

Fichier Changement
docs/tooling/test.md Ajouter exemple avec instance.options: et explication du mapping vers context.values
agent/scripts/lib/build_context.rhai template() : passer instance.spec.options au lieu de #{}
agent/src/testing/handler.rs Supprimer le bloc instance_json mort (lignes 554-568) + tests unitaires
## Analyse et plan de correction > *Commentaire rédigé par Claude Sonnet 4.6 (IA)* --- ### Cause racine Le bug est **double** — une clé YAML inexistante + un bug dans le script Rhai. #### 1. Le YAML de test utilise `values:` au niveau racine — clé inexistante Le struct `VynilTest` (`agent/src/testing/vyniltest.rs`) ne déclare pas de champ `values:` au niveau racine. Serde ignore silencieusement les clés inconnues : la section `values:` du fichier de test est donc jetée à la désérialisation. **La clé correcte est `instance.options:`**, qui existe déjà dans `VynilTestInstance` : ```rust pub struct VynilTestInstance { pub name: String, pub namespace: String, pub options: Option<BTreeMap<String, serde_json::Value>>, // ← ici } ``` Le YAML du test devrait être : ```yaml instance: name: github-mcp namespace: mytest-apps options: # ← pas un `values:` au niveau racine toolsets: "repos,issues,pull_requests" github_url: "https://github.example.com" ``` #### Pourquoi `instance.options:` fonctionne déjà pour `make test` La chaîne complète est câblée : 1. `get_templated_test()` (handler.rs ~381) lit `test.instance.options` et l'injecte dans `spec.options` du mock K8s (`TenantInstance` / `SystemInstance` / `ServiceInstance`). 2. Rhai appelle `get_tenant_instance(ns, name)` → retrouve ce mock avec `spec.options` renseigné. 3. `ctx::run(instance, args)` → `build_context.rhai::run()` → `get_values(instance.spec.options, defaults)` → les valeurs surchargées sont utilisées. ✓ #### 2. `build_context.rhai::template()` ignore `instance.spec.options` — bug réel pour `make template` La fonction `template()` (utilisée par `make <pkg> template`) passe une map vide ligne 288 : ```rhai values: get_values(#{}, defaults), // ← #{} = toujours les défauts ``` Alors que la fonction `run()` (chemin de test) fait correctement : ```rhai values: get_values(instance.spec.options, defaults), ``` Ce bug affecte `make template` et `make lint` mais **pas `make test`** (qui passe par `run()`). --- ### Plan de correction #### Étape 1 — Documenter `instance.options:` (priorité haute) Mettre à jour `docs/tooling/test.md` avec un exemple complet montrant `instance.options:` et son effet sur `context.values` / les templates : ```yaml # tests/full.yaml apiVersion: vinyl.solidite.fr/v1beta1 kind: Test metadata: name: full instance: name: github-mcp namespace: mytest-apps options: # surcharge des options du package toolsets: "repos,issues,pull_requests" github_url: "https://github.example.com" testSets: - testSet: tenant variables: tenant: mytest ``` Préciser que : - `instance.options:` équivaut à `spec.options` d'une instance K8s réelle. - Ces valeurs sont fusionnées avec les defaults de `package.yaml` via `get_values()`. - `context.values.toolsets` dans les scripts Rhai et `{{values.toolsets}}` dans les templates reflètent bien les valeurs surchargées. #### Étape 2 — Corriger `build_context.rhai::template()` (TDD) Écrire d'abord un test qui échoue : `make <pkg> template` avec `instance.options:` → la sortie doit contenir la valeur surchargée. Puis corriger ligne 288 : ```rhai // avant values: get_values(#{}, defaults), // après values: get_values(instance.spec.options, defaults), ``` #### Étape 3 — Supprimer le code mort dans `run_test_inner()` Les lignes 554-568 de `handler.rs` construisent un `instance_json` qui n'est jamais transmis à Rhai (le `rhai.set_dynamic` est commenté ligne 569). Ce bloc peut être supprimé. --- ### Fichiers impactés | Fichier | Changement | |---|---| | `docs/tooling/test.md` | Ajouter exemple avec `instance.options:` et explication du mapping vers `context.values` | | `agent/scripts/lib/build_context.rhai` | `template()` : passer `instance.spec.options` au lieu de `#{}` | | `agent/src/testing/handler.rs` | Supprimer le bloc `instance_json` mort (lignes 554-568) + tests unitaires |
xmortelette commented 2026-06-14 22:41:32 +02:00
Author
Copy Link

Clarification — commandes exactes de reproduction

Ce que fait make <pkg> template

make template est un alias pour templateGen, qui exécute en réalité package test avec TEMPLATE_OUTPUT_FILENAME en plus :

# make ia/github-mcp template  →  équivalent à :
TESTING=true \
TESTSETS_DIRECTORY="./.testsets" \
CONFIG_DIR="./.context/" \
TEMPLATE_OUTPUT_FILENAME="/tmp/ia_github-mcp.yaml" \
vynil-agent package test \
  --package-dir "./ia/github-mcp" \
  --test-name full

# make ia/github-mcp test  →  équivalent à :
TESTING=true \
TESTSETS_DIRECTORY="./.testsets" \
CONFIG_DIR="./.context/" \
vynil-agent package test \
  --package-dir "./ia/github-mcp" \
  --all

La seule différence est la présence de TEMPLATE_OUTPUT_FILENAME, qui déclenche la génération du fichier YAML de sortie et le code path template() au lieu de run() dans build_context.rhai.

Précision sur la section values: au niveau racine

values: au niveau racine n'est pas la bonne clé — ce n'est pas un bug du tester, c'est une erreur d'utilisation. La clé correcte est instance.options:, qui est correctement injectée dans spec.options du mock K8s et donc dans context.values.*.

Une fois les fichiers de test corrigés avec instance.options:, make test fonctionne correctement et les valeurs surchargées sont bien appliquées.

Le seul vrai bug — TEMPLATE_OUTPUT_FILENAME force template() qui ignore instance.spec.options

# Avec instance.options: correctement renseigné :
make ia/github-mcp test
# → GITHUB_TOOLSETS: "repos,issues,pull_requests"  ✓

make ia/github-mcp template
# → GITHUB_TOOLSETS: ''  ✗  (défaut du package.yaml)

make template / make lint / make lintkydah / make kubelinter passent tous par templateGen (donc TEMPLATE_OUTPUT_FILENAME), et génèrent toujours le YAML avec les valeurs par défaut, quelles que soient les instance.options: du test.

## Clarification — commandes exactes de reproduction ### Ce que fait `make <pkg> template` `make template` est un alias pour `templateGen`, qui exécute en réalité `package test` avec `TEMPLATE_OUTPUT_FILENAME` en plus : ```bash # make ia/github-mcp template → équivalent à : TESTING=true \ TESTSETS_DIRECTORY="./.testsets" \ CONFIG_DIR="./.context/" \ TEMPLATE_OUTPUT_FILENAME="/tmp/ia_github-mcp.yaml" \ vynil-agent package test \ --package-dir "./ia/github-mcp" \ --test-name full ``` ```bash # make ia/github-mcp test → équivalent à : TESTING=true \ TESTSETS_DIRECTORY="./.testsets" \ CONFIG_DIR="./.context/" \ vynil-agent package test \ --package-dir "./ia/github-mcp" \ --all ``` La seule différence est la présence de `TEMPLATE_OUTPUT_FILENAME`, qui déclenche la génération du fichier YAML de sortie et le code path `template()` au lieu de `run()` dans `build_context.rhai`. ### Précision sur la section `values:` au niveau racine `values:` au niveau racine n'est **pas** la bonne clé — ce n'est pas un bug du tester, c'est une erreur d'utilisation. La clé correcte est `instance.options:`, qui est correctement injectée dans `spec.options` du mock K8s et donc dans `context.values.*`. Une fois les fichiers de test corrigés avec `instance.options:`, `make test` fonctionne correctement et les valeurs surchargées sont bien appliquées. ### Le seul vrai bug — `TEMPLATE_OUTPUT_FILENAME` force `template()` qui ignore `instance.spec.options` ```bash # Avec instance.options: correctement renseigné : make ia/github-mcp test # → GITHUB_TOOLSETS: "repos,issues,pull_requests" ✓ make ia/github-mcp template # → GITHUB_TOOLSETS: '' ✗ (défaut du package.yaml) ``` `make template` / `make lint` / `make lintkydah` / `make kubelinter` passent tous par `templateGen` (donc `TEMPLATE_OUTPUT_FILENAME`), et génèrent toujours le YAML avec les valeurs par défaut, quelles que soient les `instance.options:` du test.
xmortelette commented 2026-06-14 22:48:14 +02:00
Author
Copy Link

Complément — correction sur le chemin template() vs run()

Commentaire rédigé par Claude Sonnet 4.6 (IA)

Correction du commentaire #7445

Le commentaire précédent affirme que TEMPLATE_OUTPUT_FILENAME déclenche le code path template() dans build_context.rhai. Ce n'est pas ce que fait le code.

Dans agent/src/package/test.rs (lignes 137-141), TEMPLATE_OUTPUT_FILENAME cause uniquement la sérialisation des objets déjà créés vers un fichier YAML — après l'exécution du test. Il ne change pas le code Rhai exécuté :

if let Some(output) = args.template_output_filename.clone() {
    let objets = created_objects.lock().unwrap().clone();
    let content = yaml_all_serialize_to_string(&objets)?;
    fs::write(output, content).map_err(Error::Stdio)?;
}

run_test_inner() appelle toujours ctx::run(instance, args), que TEMPLATE_OUTPUT_FILENAME soit présent ou non.

Qui appelle vraiment ctx::template() ?

tenant/context.rhai::template() (qui appelle build::template() avec #{}) est invoqué par les commandes de déploiement réel de l'opérateur :

  • agent/src/template/tenant.rs → ctx::template(instance, args)
  • agent/src/template/system.rs → ctx::template(instance, args)
  • agent/src/template/service.rs → ctx::template(instance, args)

Ces commandes s'exécutent dans le cluster lors du cycle de vie d'une instance (réconciliation par l'opérateur). Elles ne sont pas appelées par make test ni make template.

Chaîne réelle pour make test et make template

Les deux passent par package test → run_test_inner() :

ctx::run(instance, args)          ← tenant/context.rhai::run()
  └─ build::run(instance, args)   ← build_context.rhai::run()
       └─ get_values(instance.spec.options, defaults)   ✓

Conséquences sur le plan de correction

Scénario Impact
make test / make template avec instance.options: bien renseigné Fonctionne déjà — les valeurs surchargées sont appliquées
make test avec values: au niveau racine (YAML de l'issue) Ne fonctionne pas — clé ignorée par serde, les valeurs restent aux defaults
Déploiement opérateur réel (réconciliation en cluster) Bug séparé — build::template() passe #{} à get_values(), les options de l'instance sont ignorées

La priorité est donc :

  1. Court terme — corriger les fichiers de test pour utiliser instance.options: + documenter (pas de changement de code).
  2. Moyen terme (bug opérateur) — corriger build_context.rhai::template() ligne 288 : get_values(#{}, defaults) → get_values(instance.spec.options, defaults). Ce bug affecte le rendu réel des templates en production.
  3. Nettoyage — supprimer le bloc instance_json mort dans run_test_inner() (lignes 554-568, jamais transmis à Rhai car la ligne rhai.set_dynamic est commentée).
## Complément — correction sur le chemin `template()` vs `run()` > *Commentaire rédigé par Claude Sonnet 4.6 (IA)* --- ### Correction du commentaire #7445 Le commentaire précédent affirme que `TEMPLATE_OUTPUT_FILENAME` déclenche le code path `template()` dans `build_context.rhai`. Ce n'est pas ce que fait le code. Dans `agent/src/package/test.rs` (lignes 137-141), `TEMPLATE_OUTPUT_FILENAME` cause uniquement la **sérialisation des objets déjà créés** vers un fichier YAML — après l'exécution du test. Il ne change pas le code Rhai exécuté : ```rust if let Some(output) = args.template_output_filename.clone() { let objets = created_objects.lock().unwrap().clone(); let content = yaml_all_serialize_to_string(&objets)?; fs::write(output, content).map_err(Error::Stdio)?; } ``` `run_test_inner()` appelle **toujours** `ctx::run(instance, args)`, que `TEMPLATE_OUTPUT_FILENAME` soit présent ou non. ### Qui appelle vraiment `ctx::template()` ? `tenant/context.rhai::template()` (qui appelle `build::template()` avec `#{}`) est invoqué par les commandes de déploiement réel de l'opérateur : - `agent/src/template/tenant.rs` → `ctx::template(instance, args)` - `agent/src/template/system.rs` → `ctx::template(instance, args)` - `agent/src/template/service.rs` → `ctx::template(instance, args)` Ces commandes s'exécutent **dans le cluster** lors du cycle de vie d'une instance (réconciliation par l'opérateur). Elles ne sont pas appelées par `make test` ni `make template`. ### Chaîne réelle pour `make test` et `make template` Les deux passent par `package test` → `run_test_inner()` : ``` ctx::run(instance, args) ← tenant/context.rhai::run() └─ build::run(instance, args) ← build_context.rhai::run() └─ get_values(instance.spec.options, defaults) ✓ ``` ### Conséquences sur le plan de correction | Scénario | Impact | |---|---| | `make test` / `make template` avec `instance.options:` bien renseigné | **Fonctionne déjà** — les valeurs surchargées sont appliquées | | `make test` avec `values:` au niveau racine (YAML de l'issue) | **Ne fonctionne pas** — clé ignorée par serde, les valeurs restent aux defaults | | Déploiement opérateur réel (réconciliation en cluster) | **Bug séparé** — `build::template()` passe `#{}` à `get_values()`, les options de l'instance sont ignorées | **La priorité est donc :** 1. **Court terme** — corriger les fichiers de test pour utiliser `instance.options:` + documenter (pas de changement de code). 2. **Moyen terme (bug opérateur)** — corriger `build_context.rhai::template()` ligne 288 : `get_values(#{}, defaults)` → `get_values(instance.spec.options, defaults)`. Ce bug affecte le rendu réel des templates en production. 3. **Nettoyage** — supprimer le bloc `instance_json` mort dans `run_test_inner()` (lignes 554-568, jamais transmis à Rhai car la ligne `rhai.set_dynamic` est commentée).
xmortelette commented 2026-06-14 22:49:09 +02:00
Author
Copy Link

Correction — contexte sur les fonctions template() dans les context.rhai

Commentaire rédigé par Claude Sonnet 4.6 (IA)

Précision importante qui change le plan : les fonctions template() dans tenant/context.rhai, system/context.rhai et service/context.rhai sont l'héritage d'une première implémentation prototype des tests. L'objectif actuel est d'utiliser exclusivement le générateur via le chemin de test (run()).

Cela invalide le point "bug opérateur" mentionné dans le commentaire précédent. Le bug dans build_context.rhai::template() (qui passe #{} à get_values()) n'est pas à corriger — c'est du code hérité qui n'est plus le chemin cible.

Plan de correction révisé (simplifié)

Il ne reste que deux actions :

1. Corriger les fichiers de test — utiliser instance.options: (pas de changement de code)

instance:
  name: github-mcp
  namespace: mytest-apps
  options:                                   # ← clé correcte
    toolsets: "repos,issues,pull_requests"
    github_url: "https://github.example.com"

Le chemin run_test_inner() → ctx::run() → build::run() → get_values(instance.spec.options, defaults) est déjà câblé et fonctionnel.

2. Documenter instance.options: dans docs/tooling/test.md

Ajouter un exemple complet avec instance.options: et préciser :

  • que ces valeurs correspondent à spec.options d'une instance K8s réelle ;
  • qu'elles sont disponibles dans les templates via {{values.<clé>}} et dans les scripts Rhai via context.values.<clé>.

3. (Bonus — nettoyage) Supprimer le bloc instance_json mort dans run_test_inner() (handler.rs lignes 554-568) dont le rhai.set_dynamic est commenté.

## Correction — contexte sur les fonctions `template()` dans les context.rhai > *Commentaire rédigé par Claude Sonnet 4.6 (IA)* --- Précision importante qui change le plan : les fonctions `template()` dans `tenant/context.rhai`, `system/context.rhai` et `service/context.rhai` sont l'héritage d'une **première implémentation prototype des tests**. L'objectif actuel est d'utiliser exclusivement le générateur via le chemin de test (`run()`). Cela invalide le point "bug opérateur" mentionné dans le commentaire précédent. Le bug dans `build_context.rhai::template()` (qui passe `#{}` à `get_values()`) n'est pas à corriger — c'est du code hérité qui n'est plus le chemin cible. ### Plan de correction révisé (simplifié) Il ne reste que **deux actions** : **1. Corriger les fichiers de test — utiliser `instance.options:` (pas de changement de code)** ```yaml instance: name: github-mcp namespace: mytest-apps options: # ← clé correcte toolsets: "repos,issues,pull_requests" github_url: "https://github.example.com" ``` Le chemin `run_test_inner()` → `ctx::run()` → `build::run()` → `get_values(instance.spec.options, defaults)` est déjà câblé et fonctionnel. **2. Documenter `instance.options:` dans `docs/tooling/test.md`** Ajouter un exemple complet avec `instance.options:` et préciser : - que ces valeurs correspondent à `spec.options` d'une instance K8s réelle ; - qu'elles sont disponibles dans les templates via `{{values.<clé>}}` et dans les scripts Rhai via `context.values.<clé>`. **3. (Bonus — nettoyage)** Supprimer le bloc `instance_json` mort dans `run_test_inner()` (`handler.rs` lignes 554-568) dont le `rhai.set_dynamic` est commenté.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
4
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Reviewed
analysed
1
The issue have been analyzed by a senior dev and feedback have been provided
Reviewed
need-more-info
5
Plus d'information requise pour l'analyse
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
read-to-code
5
Analyse validé, près pour passer à la suite
No Label Kind/Documentation Kind/Enhancement
Priority
Medium
3
Reviewed
Confirmed
4
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
shuss
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: shuss/vynil#19
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?