When a module maintainer wants to change a default value — such as the settings file path or the important-file regex patterns — the change must be made in two places: workflow.yml and Get-Settings.yml. If only one is updated, the two files silently disagree on what the default is, leading to confusing behavior that is difficult to diagnose.
Request
Current experience
The ImportantFilePatterns default (^src/ and ^README\.md$) and SettingsPath default (.github/PSModule.yml) are defined identically in both workflow.yml (lines 63–70, 33) and Get-Settings.yml (lines 37–44, 8). Other inputs — Debug, Verbose, Version, Prerelease, WorkingDirectory — are also duplicated with identical defaults.
Desired experience
Each default value is defined in exactly one place. Downstream workflows either inherit the value from the caller or define no default at all (relying on the single upstream source).
Acceptance criteria
- No input default appears in more than one workflow file
- Changing a default in one place propagates correctly to all downstream workflows
- Existing behavior is preserved for callers that do not override inputs
Technical decisions
Approach: Remove default values from reusable workflow inputs in Get-Settings.yml (and other child workflows). The defaults remain only in workflow.yml, which is the entry point. GitHub Actions passes caller-provided values (including caller defaults) to workflow_call inputs, so child workflows receive the correct value without needing their own defaults.
Affected files: Get-Settings.yml is the primary target. A secondary pass should verify all other reusable workflows (Build-Module.yml, Test-Module.yml, etc.) for the same pattern.
Risk: GitHub Actions requires workflow_call inputs to have types declared, but defaults are optional. Removing defaults from child workflows is safe as long as the parent always provides the value.
Implementation plan
When a module maintainer wants to change a default value — such as the settings file path or the important-file regex patterns — the change must be made in two places:
workflow.ymlandGet-Settings.yml. If only one is updated, the two files silently disagree on what the default is, leading to confusing behavior that is difficult to diagnose.Request
Current experience
The
ImportantFilePatternsdefault (^src/and^README\.md$) andSettingsPathdefault (.github/PSModule.yml) are defined identically in bothworkflow.yml(lines 63–70, 33) andGet-Settings.yml(lines 37–44, 8). Other inputs —Debug,Verbose,Version,Prerelease,WorkingDirectory— are also duplicated with identical defaults.Desired experience
Each default value is defined in exactly one place. Downstream workflows either inherit the value from the caller or define no default at all (relying on the single upstream source).
Acceptance criteria
Note
This is a DRY (Don't Repeat Yourself) violation. It also relates to Twelve-Factor App Factor III (Config) — configuration should have a single source of truth.
Technical decisions
Approach: Remove default values from reusable workflow inputs in
Get-Settings.yml(and other child workflows). The defaults remain only inworkflow.yml, which is the entry point. GitHub Actions passes caller-provided values (including caller defaults) toworkflow_callinputs, so child workflows receive the correct value without needing their own defaults.Affected files:
Get-Settings.ymlis the primary target. A secondary pass should verify all other reusable workflows (Build-Module.yml,Test-Module.yml, etc.) for the same pattern.Risk: GitHub Actions requires
workflow_callinputs to have types declared, but defaults are optional. Removing defaults from child workflows is safe as long as the parent always provides the value.Implementation plan
workflow.ymldefault:values fromGet-Settings.ymlinputsworkflow.ymlwithout overrides still gets correct defaults