Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Improve synthetic diff array for test operations

Aperta
  • Qualcosa non va?
#1,660 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
powershell, rust
Ambito
devops

Direzione di ricerca

L'issue non indica file di implementazione né test. Inizia individuando la generazione dei diff sintetici e la gestione dello schema delle risorse per le operazioni di test DSC, quindi confronta il modo in cui vengono rappresentate le proprietà di sola lettura e di sola scrittura. Il lavoro sarà completato quando i diff dei risultati non segnaleranno più proprietà che non possono essere fornite o restituite, con una copertura per le risorse di script PowerShell transitorie.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

As a system administrator using DSC to manage my infrastructure,
I want the differingProperties and changedProperties fields of results to accurately reflect configurable properties of the resource without substantial noise,
So that I can quickly review result data.

Currently, the synthetic diff array of property names for DSC resource testoperations has insufficient handling for read-only and write-only properties. This problem is most clearly raised for the transitional PowerShell script resources, where you get results like this (tested with 3.4.0-preview.1):

desiredState:
  input:
    configFilePath: ~/foo/bar/config.toml
    settings:
      foo: bar
  getScript: |-
    param($data)

    function Get-Config {
      [CmdletBinding(DefaultParameterSetName = 'ByPath')]
      param(
        [Parameter(Mandatory, ParameterSetName = 'ByPath')]
        [string]$Path,
        [Parameter(Mandatory, ParameterSetName = 'DefaultConfig')]
        [switch]$Default
      )
      # Elided for brevity
    }

    if ([string]::IsNullOrEmpty($data.configFilePath)) {
      Write-Warning "No config file path provided. Using default configuration."
      Get-Config -Default
    } else {
      Get-Config -Path $data.configFilePath
    }
  testScript: |-
    param($data)

    function Get-Config {
      [CmdletBinding(DefaultParameterSetName = 'ByPath')]
      param(
        [Parameter(Mandatory, ParameterSetName = 'ByPath')]
        [string]$Path,
        [Parameter(Mandatory, ParameterSetName = 'DefaultConfig')]
        [switch]$Default
      )
      # Elided for brevity
    }

    function Test-Config {
      [CmdletBinding()]
      param(
        [Parameter(Mandatory)]
        [pscustomobject]$actual,
        [Parameter(Mandatory)]
        [pscustomobject]$desired
      )
      # Elided for brevity
    }

    if ($null -eq $data.settings) {
      throw "Unable to test configuration without specific settings"
    }
    if ($data.settings -isnot [System.Management.Automation.PSCustomObject]) {
      throw "Unable to test configuration; settings input data must be an object but was [$($data.settings.GetType().FullName)]"
    }

    $actualState = if ([string]::IsNullOrEmpty($data.configFilePath)) {
      Write-Warning "No config file path provided. Using default configuration."
      Get-Config -Default
    } else {
      Get-Config -Path $data.configFilePath
    }

    Test-Config -Actual $actualState.settings -Desired $data.settings
actualState:
  _inDesiredState: false
inDesiredState: false
differingProperties:
- input
- getScript
- testScript

Not only is the result object difficult to read, but the actualState tells the user almost nothing (the _inDesiredState field is hoisted to the top level of the result), but the differing properties field is useless - input and *Script properties are write-only, so the resource will never return them, and output/_inDesiredState are read-only, so the user should never supply them.

The result is a substantial amount of noise with very little information for the user. The only way to more clearly indicate result granularity is for a resource to emit trace messages about how the instance is out-of-state.

Reproducing the output

Run the following command to reproduce the full output noted above:

dsc resource test -r Microsoft.DSC.Transitional/PowerShellScript -i @'
input:
  configFilePath: ~/foo/bar/config.toml
  settings:
    foo: bar
getScript: |-
  param($data)

  function Get-Config {
    [CmdletBinding(DefaultParameterSetName = 'ByPath')]
    param(
      [Parameter(Mandatory, ParameterSetName = 'ByPath')]
      [string]$Path,
      [Parameter(Mandatory, ParameterSetName = 'DefaultConfig')]
      [switch]$Default
    )

    if ($Default) {
      $Path = "$HOME/.config/default_config.json"
    }

    [ordered]@{
      Path = $Path
      settings = [ordered]@{
        foo = "baz"
      }
    }
  }

  if ([string]::IsNullOrEmpty($data.configFilePath)) {
    Write-Warning "No config file path provided. Using default configuration."
    Get-Config -Default
  } else {
    Get-Config -Path $data.configFilePath
  }
testScript: |-
  param($data)

  function Get-Config {
    [CmdletBinding(DefaultParameterSetName = 'ByPath')]
    param(
      [Parameter(Mandatory, ParameterSetName = 'ByPath')]
      [string]$Path,
      [Parameter(Mandatory, ParameterSetName = 'DefaultConfig')]
      [switch]$Default
    )

    if ($Default) {
      $Path = "$HOME/.config/default_config.json"
    }

    [pscustomobject]@{
      path = $Path
      settings = [pscustomobject]@{
        foo = "baz"
      }
    }
  }

  function Test-Config {
    [CmdletBinding()]
    param(
      [Parameter(Mandatory)]
      [pscustomobject]$actual,
      [Parameter(Mandatory)]
      [pscustomobject]$desired
    )
    $inDesiredState = $true
    if ($actual.path -ne $desired.path) {
      $inDesiredState = $false
    }
    foreach ($setting in $desired.psobject.Properties.Name) {
      if ($actual.$setting -ne $desired.$setting) {
        $inDesiredState = $false
      }
    }
    return $inDesiredState
  }

  if ($null -eq $data.settings) {
    throw "Unable to test configuration without specific settings"
  }
  if ($data.settings -isnot [System.Management.Automation.PSCustomObject]) {
    throw "Unable to test configuration; settings input data must be an object but was [$($data.settings.GetType().FullName)]"
  }

  $actualState = if ([string]::IsNullOrEmpty($data.configFilePath)) {
    Write-Warning "No config file path provided. Using default configuration."
    Get-Config -Default
  } else {
    Get-Config -Path $data.configFilePath
  }

  Test-Config -Actual $actualState.settings -Desired $data.settings
'@
Proposed technical implementation details (optional)

While I don't have a concrete proposal, this issue made me think of two approaches that could help with this problem:

  1. Introduce special handling for read-only/write-only properties in result data - we probably shouldn't include them in the differingProperties array, because they'll never match both actual and desired state.
  2. Define a helper keyword for resource schema properties like x-dsc-hideFromDesiredState to specifically filter out properties that add a lot of noise to the result object.
Lingua principale
Rust
Stelle
526
Fork
76
Merge medio
4g 20h
PR unite (30g)
24

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di PowerShell/DSC

Tutte le issue di PowerShell/DSC

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.