Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Finish the cutover to source-generated schemas and publish missing version folders

Abierto
  • ¿Algo no está bien?
#1,673 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
powershell, rust
Área
build-system, ci-cd, devtools

Línea de trabajo

Comienza leyendo schemas/src y schemas/build.ps1; después inspecciona las implementaciones de DscRepoSchema en lib/dsc-lib y ejecuta cargo xtask schema export. Compara la salida generada con las carpetas schemas/ existentes y con la cobertura de Pester propuesta en dsc/tests. Se considera terminado cuando los esquemas generados cubren los tipos declarados y las versiones publicadas, evitan desviaciones y validan los manifiestos de ejemplo del repositorio.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Issue-Enhancement Needs Triage
Summary of the new feature / enhancement

As a configuration author or resource developer using the published DSC schemas,
I want the schemas to publish for every released version and stay in sync with the engine automatically,
So that editor validation and IntelliSense help me instead of contradicting DSC.

Currently the published schemas under schemas/ are built from hand-maintained YAML sources (schemas/src via schemas/build.ps1) that were last generated for v3.1.0, while the engine has moved on to 3.4.

The most visible symptom is that recognized $schema URIs don't resolve. The engine accepts every version through v3.2.3 as a valid $schema value, but no schema folder was ever published after v3.1.0, so a document pinned to a URI like this validates in DSC and 404s in the editor:

$schema: https://aka.ms/dsc/schemas/v3.2/bundled/config/document.json

The YAML sources have also drifted from the engine — fields, enum values, and whole subsystems added since v3.1.0 aren't represented, and in several cases the published schemas reject manifests this repository ships. Those content gaps will be filed as individual issues; this issue tracks the underlying problem that makes them inevitable.

That underlying problem is that the repository has two schema systems mid-migration. The YAML pipeline is what publishes, but every release requires manually editing schemas.config.yaml, re-running build.ps1 per version folder, and hand-updating the $schema URI enums in the sources — steps nothing enforces, which is how seven releases shipped without schemas. Meanwhile the source-based generator from #538/#1406 (DscRepoSchema + cargo xtask schema export) derives schemas directly from the engine's types — making drift structurally impossible — but is nearly complete rather than complete: it has never published anything, and no CI exercises either system.

Proposed technical implementation details (optional)

Finish the cutover to generated schemas in phases, each independently reviewable:

  1. Exporter correctness (#1672): fix the two silent path collisions (AdaptedDscResourceManifest, DeleteWhatIfResult), export every type that derives DscRepoSchema, fail on duplicate output paths, add --schema-version/--release targeting, and route dsc schema through the same machinery so the CLI and exporter agree.
  2. Bundling and namespace parity: expand should_bundle to match the 24 bundled schemas the YAML pipeline publishes today, and decide the disposition of each YAML-only schema (resource/stdout/*, resource/properties/*, metadata/Microsoft.DSC/*), with $ref alias stubs in the floating version folders for moved paths.
  3. Authoring parity: port the title/description/VS Code keywords from the YAML sources onto the Rust types using the existing schema_i18n! pattern, with a comparison report gating the cutover so generated schemas don't regress the editor experience.
  4. CI: commit schemas/vNext, regenerate it in CI and fail on drift, and validate the repository's own example configurations and manifests against the generated schemas.
  5. Backfill: publish the missing v3.1.1–v3.2.3 folders from each release tag's own sources so every recognized URI resolves.
  6. Cutover: the next stable release publishes its folders via cargo xtask schema export --release, after which schemas/src and schemas/build.ps1 can be retired.

The CI checks (phase 4) fit naturally as a Pester test in dsc/tests, so they run in the existing ./build.ps1 -Test -PesterTestGroup dsc job as well as in a dedicated schemas workflow that invokes cargo xtask schema export first. Something like:

BeforeDiscovery {
    # Every (folder_path, base_name) pair declared with #[dsc_repo_schema(...)]
    $declarations = Get-ChildItem lib/dsc-lib/src -Recurse -Filter '*.rs' | ForEach-Object {
        [regex]::Matches(
            (Get-Content $_.FullName -Raw),
            '(?s)base_name\s*=\s*"(?<base>[^"]+)"\s*,\s*folder_path\s*=\s*"(?<folder>[^"]+)"'
        ) | ForEach-Object {
            @{ folder = $_.Groups['folder'].Value; base = $_.Groups['base'].Value }
        }
    }
}

Describe 'exported schemas' {
    It 'exports <folder>/<base>.json' -TestCases $declarations {
        Join-Path 'schemas/vNext' $folder "$base.json" | Should -Exist
    }

    It 'has no uncommitted drift' {
        git diff --exit-code -- schemas/vNext
        $LASTEXITCODE | Should -Be 0 -Because 'run `cargo xtask schema export` and commit the result'
    }
}

Describe 'instance validation' {
    It 'validates <name> against the generated manifest schema' -TestCases $manifests {
        Test-Json -Path $path -SchemaFile 'schemas/vNext/bundled/resource/manifest.json' | Should -BeTrue
    }
}

The first block also catches the "derives DscRepoSchema but was never exported" class of bug statically, and the instance validation is the regression proof for the drift issues: manifests in this repository that fail against the published v3.1.0 schemas today must pass against the generated ones.

Lenguaje dominante
Rust
Estrellas
532
Forks
76
Merge medio
2 d 10 h
PR fusionados (30 d)
15

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de PowerShell/DSC

Todos los issues de PowerShell/DSC

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.