Skip to content

Add latest-compatible installation and DscPkg/Resource - #7

Merged
Bpoe merged 2 commits into
mainfrom
bpoe-dsc-resource-installation
Oct 26, 2026
Merged

Bpoe merged 2 commits into
mainfrom
bpoe-dsc-resource-installation

Conversation

@Bpoe

@Bpoe Bpoe commented Oct 26, 2026 •

Copy link
Copy Markdown
Owner

Summary

  • Make dscpkg install --version optional, selecting the newest compatible stable resource from the first satisfying repository. Preserve exact resource/package selectors, fail closed on metadata/integrity/signing errors, and share archive descriptor verification with the existing installer.
  • Add native DscPkg/Resource Get, Test, Set, and Export. CLI and DSC Set both use Client.Install; discovery and inventory share one installed-manifest enumerator and platform-provenance gate. Get/Test/Export are read-only and offline. Unversioned Set installs only when necessary, never automatically upgrades a compliant resource, and recognizes unregistered resources supplied by shared packages.
  • Give Export stable _name values using the existing resource type and version directly (DscExtras.Linux/groups@0.1.1). No encoding or generated identifiers. Only Export populates _name; DSC uses it as the configuration instance name and removes it from properties. Unit and actual DSC 3.3.0 integration tests verify this contract and that Get/Test/Set remain unchanged.
  • Ship both bootstrap manifests in release archives, MSI, DEB, and RPM; extend inspection and lifecycle tests for repair, upgrade replacement, removal, and preservation of user package stores. Add one consistent DSCPKG_PACKAGES_DIR override.
  • Document the property model, export/reapply behavior, installation scope, repository precedence, discovery/bootstrap, and examples/00-resources.yaml.

Validation

All PR CI jobs passed, including the stable Export-name follow-up, on Windows, macOS, Linux AMD64, and Linux ARM64: successful CI run.

CI verified:

  • Formatting, vetting, unit tests, builds, and race tests where enabled by the existing matrix.
  • Actual DSC 3.3.0 on every platform: official engine-exported manifest schemas; extension/resource discovery; Get/Test/Set/Export; exported instance validation and stable configuration names with _name removed from properties; clean dependency configuration using a loopback repository and shared executable; exactly one archive download; repeat/offline compliance; platform filtering; explicit resource-path bootstrap.
  • Same-process DSC server regression tests for both preDeployment and duringDeployment.
  • Release archive and native installer builds, payload/permission/metadata inspection, release safeguards, and checksum verification.
  • Windows MSI lifecycle: install, repair, upgrade replacement of both manifests, downgrade rejection, uninstall/PATH removal, and user-data retention.
  • Linux AMD64/ARM64 DEB and Fedora-container RPM lifecycles: install, reinstall, upgrade replacement of both manifests, uninstall, and user-data retention.

Additional local checks passed: Windows Go/vet/unit/DSC integration checks; Linux race-enabled unit and integration checks; isolated Linux archive/DEB/RPM build/inspection and container installer lifecycles; Windows archive payload verification; ShellCheck/actionlint; Linux ARM64 and Darwin ARM64 cross-builds. The Export-name follow-up was also verified locally on Windows and Linux with actual DSC 3.3.0.

Local WiX ICE validation was blocked by workstation policy (WIX1105), so validation was not suppressed and no product was installed on the developer machine. The native Windows CI build, inspection, and complete MSI lifecycle subsequently passed.

Documented limitations and server finding

  • DSC 3.3.0's persistent server retains stale resource lookup state with default preDeployment: a second configuration cannot resolve resources installed by 00-resources.yaml. Setting directives.resourceDiscovery: duringDeployment on the consuming configuration succeeds. Separate DSC processes see the new resources immediately. No dscd changes are included.
  • Native JSON/YAML manifests and resources entries in manifest lists are inventoried. Adapter-backed entries are excluded with diagnostics because offline inventory cannot verify external adapter availability; discovery still advertises them unchanged.
  • Export cannot reconstruct repository origins; users must supply repositories when reapplying to an empty store. Filtering is disabled.
  • state: missing is observation-only; Set does not remove registrations or packages. This is not Steve's proposed installation extension or a remote acquisition protocol.

Brandon Poe and others added 2 commits October 26, 2026 11:52
Share catalog resolution, archive verification, and installed manifest enumeration across CLI and DSC operations. Ship both bootstrap manifests and cover DSC 3.3 configuration and server discovery behavior.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Emit _name only from Export, allow it in the instance schema, and verify DSC consumes it as the configuration name without retaining it in properties.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@Bpoe
Bpoe merged commit 0a7807e into main Oct 26, 2026
8 checks passed
@Bpoe
Bpoe deleted the bpoe-dsc-resource-installation branch October 26, 2026 23:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant