Scope workflow inputs to only the fields each reusable workflow uses

[MariusStorhaug]

Every reusable workflow in the Process-PSModule repository receives the entire Settings JSON blob as a single string input, even when the workflow only uses a small subset of the fields. This creates invisible coupling between all workflows and the Settings schema.

Request

Current experience

Each reusable workflow accepts Settings as a single string input and dereferences it with fromJson(inputs.Settings).Field.SubField. The actual field usage varies dramatically:

Workflow	Fields actually used	Total fields in Settings blob
Build-Module.yml	.Name, .WorkingDirectory (2 fields)	All
Test-SourceCode.yml	.Debug, .Prerelease, .Verbose, .Version, .TestSuites.SourceCode, .WorkingDirectory (6 fields)	All
Test-ModuleLocal.yml	.Debug, .Prerelease, .Verbose, .Version, .WorkingDirectory, .TestSuites.Module (6 fields)	All
Publish-Module.yml	.Name, .WorkingDirectory, .Publish.Module.* (18 fields)	All
Lint-Repository.yml	Minimal settings	All

Build-Module.yml needs only 2 fields but receives the entire blob including test suites, publish configuration, linter settings, and debug flags. Any schema change to Settings — even to unrelated sections — is a potential breaking change for all consumers.

Desired experience

Each reusable workflow declares only the inputs it actually needs. The orchestrator (workflow.yml) extracts the relevant subset from the Settings blob and passes scoped values to each child workflow.

Acceptance criteria

• Each reusable workflow input set matches its actual usage (no unused fields passed)
• A schema change in one section (e.g., Publish.Module) does not affect workflows that don't use that section
• The Settings blob remains the single source of truth — scoping happens at the call site, not in the settings file
• No change in runtime behavior

Note

This violates the Interface Segregation Principle (ISP): "no code should be forced to depend on methods it does not use." Each workflow depends on the entire Settings interface when it only uses a narrow slice.

---

Technical decisions

Approach — phased migration: This is a large change. Start with the workflows that have the narrowest coupling:

1. Phase 1: Build-Module.yml — replace Settings input with Name and WorkingDirectory inputs
2. Phase 2: Test workflows — replace Settings with scoped test-suite configuration + common fields
3. Phase 3: Publish-Module.yml — replace Settings with a scoped PublishSettings sub-object or individual inputs
4. Phase 4: Remaining workflows

Alternative considered: Pass scoped sub-objects (e.g., ${{ toJson(fromJson(needs.Get-Settings.outputs.Settings).Publish.Module) }}) from workflow.yml. This reduces coupling but still passes JSON blobs. Acceptable as an intermediate step.

Alternative considered: Keep the Settings blob and document which fields each workflow uses. Rejected because documentation drifts — the coupling should be enforced by the interface (input declarations).

Breaking change: This changes the reusable workflow interfaces. Callers of individual workflows (if any exist outside workflow.yml) would need to update. Since these workflows are internal to Process-PSModule, the blast radius is contained.

---

Implementation plan

Phase 1 — Build-Module.yml (minimal coupling)

• Add Name and WorkingDirectory inputs to Build-Module.yml
• Remove Settings input from Build-Module.yml
• Update workflow.yml to pass individual values instead of Settings blob to Build-Module

Phase 2 — Test workflows

• Identify exact fields used by Test-SourceCode.yml, Test-Module.yml, Test-ModuleLocal.yml
• Add scoped inputs to each test workflow
• Update workflow.yml to pass scoped values

Phase 3 — Publish-Module.yml

• Determine whether to pass a PublishSettings sub-object or individual inputs (18 fields)
• Update Publish-Module.yml inputs
• Update workflow.yml to pass scoped values

Phase 4 — Remaining workflows

• Apply the same pattern to Lint-Repository.yml, Lint-SourceCode.yml, Build-Docs.yml, Build-Site.yml, Publish-Site.yml, Get-TestResults.yml, Get-CodeCoverage.yml
• Remove the Settings input from all reusable workflows