Configuration#

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 following settings are available in the settings file:

Name: null

ImportantFilePatterns:
  - '^src/'
  - '^README\.md$'

Build:
  Skip: false
  Module:
    Skip: false
  Docs:
    Skip: false
    ShowSummaryOnSuccess: false
  Site:
    Skip: false

Test:
  Skip: false
  Linux:
    Skip: false
  MacOS:
    Skip: false
  Windows:
    Skip: false
  SourceCode:
    Skip: false
    Linux:
      Skip: false
    MacOS:
      Skip: false
    Windows:
      Skip: false
  PSModule:
    Skip: false
    Linux:
      Skip: false
    MacOS:
      Skip: false
    Windows:
      Skip: false
  Module:
    Skip: false
    Linux:
      Skip: false
    MacOS:
      Skip: false
    Windows:
      Skip: false
  TestResults:
    Skip: false
  CodeCoverage:
    Skip: false
    PercentTarget: 0
    StepSummaryMode: 'Missed, Files'

Publish:
  Module:
    Skip: false
    AutoCleanup: true
    AutoPatching: true
    IncrementalPrerelease: true
    DatePrereleaseFormat: ''
    VersionPrefix: 'v'
    MajorLabels: 'major, breaking'
    MinorLabels: 'minor, feature'
    PatchLabels: 'patch, fix'
    IgnoreLabels: 'NoRelease'
    UsePRTitleAsReleaseName: false
    UsePRBodyAsReleaseNotes: true
    UsePRTitleAsNotesHeading: true

Linter:
  Skip: false
  ShowSummaryOnSuccess: false
  env: {}

Example 1 - Defaults with Code Coverage target#

This example runs all steps and will require that code coverage is 80% before passing.

Test:
  CodeCoverage:
    PercentTarget: 80

Example 2 - Rapid testing#

This example ends up running Plan, Build-Module and Test-Module (tests from the module repo) on ubuntu-latest only.

Test:
  SourceCode:
    Skip: true
  PSModule:
    Skip: true
  Module:
    MacOS:
      Skip: true
    Windows:
      Skip: true
  TestResults:
    Skip: true
  CodeCoverage:
    Skip: true
Build:
  Docs:
    Skip: true

Example 3 - Configuring the Repository Linter#

The workflow uses super-linter to lint your repository code. The linter runs on pull requests and provides status updates directly in the PR.

Disabling the Linter#

You can skip repository linting entirely:

Linter:
  Skip: true

Configuring Linter Validation Rules#

The workflow supports all environment variables that super-linter provides. You can configure these through the Linter.env object:

Linter:
  env:
    # Disable specific validations
    VALIDATE_BIOME_FORMAT: false
    VALIDATE_BIOME_LINT: false
    VALIDATE_GITHUB_ACTIONS_ZIZMOR: false
    VALIDATE_JSCPD: false
    VALIDATE_JSON_PRETTIER: false
    VALIDATE_MARKDOWN_PRETTIER: false
    VALIDATE_YAML_PRETTIER: false

    # Or enable only specific validations
    VALIDATE_YAML: true
    VALIDATE_JSON: true
    VALIDATE_MARKDOWN: true

Additional Configuration#

Any super-linter environment variable can be set through the Linter.env object:

Linter:
  env:
    LOG_LEVEL: DEBUG
    FILTER_REGEX_EXCLUDE: '.*test.*'
    VALIDATE_ALL_CODEBASE: false

Showing Linter Summary on Success#

By default, the linter only shows a summary when it finds issues. You can enable summary display on successful runs:

Linter:
  ShowSummaryOnSuccess: true

This is useful for reviewing what was checked even when no issues are found.

Note: The GITHUB_TOKEN is automatically provided by the workflow to enable status updates in pull requests.

For a complete list of available environment variables and configuration options, see the super-linter environment variables documentation.

Example 4 - Configuring PR-based release notes#

The workflow can automatically generate GitHub release names and notes from your pull request content. Three parameters control this behavior:

These parameters follow specific precedence rules when building release notes:

1. Heading + Body (UsePRTitleAsNotesHeading: true + UsePRBodyAsReleaseNotes: true): Creates formatted notes with the PR title as an H1 heading followed by the PR body. The output format is # PR Title (#123)\n\nPR body content. Both the PR title and body must be present.
2. Body only (UsePRBodyAsReleaseNotes: true): Uses the PR body as-is for release notes. Takes effect when heading option is disabled or PR title is missing.
3. Fallback: When neither option is enabled or required PR content is missing, GitHub's auto-generated release notes are used via --generate-notes.

Default configuration (recommended)#

The defaults provide rich release notes with the PR title as a heading:

Publish:
  Module:
    UsePRTitleAsReleaseName: false
    UsePRBodyAsReleaseNotes: true
    UsePRTitleAsNotesHeading: true

This produces release notes like:

# 🚀 Add new authentication feature (#42)

This PR adds OAuth2 support with the following changes:
- Added `Connect-OAuth2` function
- Updated documentation

Version-only release names#

If you prefer version numbers as release names but still want PR-based notes:

Publish:
  Module:
    UsePRTitleAsReleaseName: false
    UsePRBodyAsReleaseNotes: true
    UsePRTitleAsNotesHeading: false

Auto-generated notes#

To use GitHub's auto-generated release notes instead of PR content:

Publish:
  Module:
    UsePRTitleAsReleaseName: false
    UsePRBodyAsReleaseNotes: false
    UsePRTitleAsNotesHeading: false