Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions src/docs/Frameworks/Process-PSModule/configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,11 @@ description: The Process-PSModule settings file — every available setting, the
The workflow is configured using a settings file in the module repository.
The file can be a `JSON`, `YAML`, or `PSD1` file. By default, it will look for `.github/PSModule.yml`.

The settings listed on this page are the user-facing configuration contract in `.github/PSModule.yml`. During the
Plan phase, Process-PSModule enriches this input into an internal runtime `Settings` object that downstream workflows
consume. Internal runtime paths in workflow docs (for example, `Settings.Publish.Module.Resolution.*`) describe that
enriched inter-workflow contract, not a different authoring format for repository settings files.

The following settings are available in the settings file:

| Name | Type | Description | Default |
Expand Down
34 changes: 31 additions & 3 deletions src/docs/Frameworks/Process-PSModule/pipeline-stages.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,36 @@ implements it.

The Plan job is the single decision point of the workflow. It reads the settings file (`.github/PSModule.yml`),
collects event context from GitHub, and decides what should happen in the rest of the process. Using that
situational awareness, it calculates the next module version. All decisions are captured in a single `Settings`
object — including version data under `Settings.Module` — that every downstream job receives.
situational awareness, it calculates the next module version.

The user-facing settings file stays in `.github/PSModule.yml`. The workflow enriches that input into an internal runtime
`Settings` object passed between jobs. In this runtime contract, execution decisions are phase-owned (`*.Enabled`), test
suite matrices are defined under each owning test phase, and resolved version metadata is stored under
`Settings.Publish.Module.Resolution`.

### Internal runtime settings contract

| Runtime path | Meaning |
| --- | --- |
| `Settings.Linter.Repository.Enabled` | Whether repository linting runs. |
| `Settings.Build.Module.Enabled` | Whether module build runs. |
| `Settings.Test.SourceCode.Enabled` | Whether source-code tests run. |
| `Settings.Test.PSModule.Enabled` | Whether framework tests run. |
| `Settings.Test.Module.BeforeAllEnabled` | Whether setup scripts run before module-local tests. |
| `Settings.Test.Module.MainEnabled` | Whether module-local Pester tests run. |
| `Settings.Test.Module.AfterAllEnabled` | Whether teardown scripts run after module-local tests. |
| `Settings.Test.TestResults.Enabled` | Whether test results aggregation runs. |
| `Settings.Test.CodeCoverage.Enabled` | Whether code coverage aggregation/enforcement runs. |
| `Settings.Publish.Module.Enabled` | Whether module publication/release runs. |
| `Settings.Publish.Site.Enabled` | Whether documentation publication runs. |
| `Settings.Test.SourceCode.Suites` | Source-code test suite matrix. |
| `Settings.Test.PSModule.Suites` | Framework test suite matrix. |
| `Settings.Test.Module.Suites` | Module-local test suite matrix. |
| `Settings.Publish.Module.Resolution.Version` | Resolved semantic version used for build and publish. |
| `Settings.Publish.Module.Resolution.Prerelease` | Whether the resolved version is prerelease. |
| `Settings.Publish.Module.Resolution.FullVersion` | Resolved full version string. |
| `Settings.Publish.Module.Resolution.ReleaseType` | Resolved release classification for this run. |
| `Settings.Publish.Module.Resolution.CreateRelease` | Whether this run creates a release. |

## Lint-Repository

Expand All @@ -26,7 +54,7 @@ object — including version data under `Settings.Module` — that every downstr

[workflow](https://github.com/PSModule/Process-PSModule/blob/main/.github/workflows/Build-Module.yml)

- Compiles the module source code into a PowerShell module, stamping the version from `Settings.Module` into the manifest.
- Compiles the module source code into a PowerShell module, stamping the version from `Settings.Publish.Module.Resolution.Version` into the manifest.
- Uploads the built artifact.

## Test source code
Expand Down
2 changes: 1 addition & 1 deletion src/docs/Frameworks/Process-PSModule/usage.md
Original file line number Diff line number Diff line change
Expand Up @@ -291,7 +291,7 @@ When a pull request does not contain changes to important files:

1. A comment is automatically added to the PR listing the configured patterns and explaining why build/test stages are
skipped
2. `Settings.Module.ReleaseType` is set to `None` (and `Settings.Module.CreateRelease` is `false`)
2. `Settings.Publish.Module.Resolution.ReleaseType` is `None` (and `Settings.Publish.Module.Resolution.CreateRelease` is `false`)
3. Build, test, and publish stages are skipped
4. The PR can still be merged for non-release changes (documentation updates, CI improvements, etc.)

Expand Down