v6.1.4

🪲 [Fix]: Resolve the current version on non-PR runs (bump Resolve-PSModuleVersion to v1.1.5) (#375)

The Plan job no longer fails on schedule and workflow_dispatch events. Resolve-PSModuleVersion is bumped to v1.1.5, which resolves the current published version on non–pull-request events instead of throwing.

• Fixes #373

Fixed: non–pull-request runs (schedule / workflow_dispatch)

Since v6.1.0 the Plan job runs Resolve-Version on every event, and the action threw "...must be run from a pull_request event" on non-PR events — failing the whole run (every job needs: Plan). Resolve-PSModuleVersion v1.1.5 (PSModule/Resolve-PSModuleVersion#10) fixes this at the source: on a non-PR event it returns the current published version — no bump, no prerelease, nothing published — floored at 0.0.0 for a module that has never been released. Pull-request and merge-to-default-branch behavior is unchanged: labels drive the bump (patch default), and the version preview on regular PRs is retained.

Technical Details

• .github/workflows/Plan.yml: bump the Resolve-Version pin 8d1dac7 (v1.1.4) → 6a59a88 (v1.1.5). One-line change — no Plan gate or Test-ModuleLocal fallback is needed, because v1.1.5 always populates Settings.Module.Version on non-PR events.
• This supersedes this PR's earlier Plan.yml gate + 999.0.0 fallback approach, replaced by the root-cause fix in the shared action.
• Validated: a workflow_dispatch self-test run on this branch completes (previously failed at Plan); the PR self-test resolves a version as before.

v6.1.3

🩹 [Patch]: Bump Invoke-ScriptAnalyzer to v5.0.0 and Test-PSModule to v3.0.14 (#380)

Brings Process-PSModule's lint/test action dependencies to their latest releases: PSModule/Invoke-ScriptAnalyzer v4.1.3 → v5.0.0 and PSModule/Test-PSModule v3.0.13 → v3.0.14. Both preserve the reusable workflow's Settings.Version/Settings.Prerelease contract for consumers.

Changed: Invoke-ScriptAnalyzer upgraded to v5.0.0

Invoke-ScriptAnalyzer v5.0.0 is a major release that repurposed its Version/Prerelease inputs to select the PSScriptAnalyzer module version and moved the GitHub bootstrap-module controls to GitHubVersion/GitHubPrerelease.

The Lint-SourceCode and Lint-Module steps pass Settings.Version/Settings.Prerelease, which in this ecosystem select the GitHub module (the same values feed the Invoke-Pester and GitHub-Script steps). They are now wired to Invoke-ScriptAnalyzer's GitHubVersion/GitHubPrerelease, so those settings keep controlling the GitHub module exactly as before. No change to the Settings contract.

With v5, the action also installs PSScriptAnalyzer itself (latest, since its Version is left unset) instead of relying on the runner's preinstalled copy — so consumer linting now runs against the latest PSScriptAnalyzer.

Changed: Test-PSModule upgraded to v3.0.14

Patch release; Test-PSModule v3.0.14 (which internally bumped Invoke-Pester to v5.1.0) preserves its own Version/Prerelease (GitHub module) contract, so the Test-SourceCode and Test-Module steps need only a SHA update — no input remap.

Technical Details

• Lint-SourceCode.yml, Test-Module.yml: Invoke-ScriptAnalyzer 6aeb1bc (v4.1.3) → 4d633e4 (v5.0.0); remapped Version → GitHubVersion, Prerelease → GitHubPrerelease.
• Test-Module.yml, Test-SourceCode.yml: Test-PSModule 25c9cd8 (v3.0.13) → 902c5e5 (v3.0.14).
• Pester and PSScriptAnalyzer versions left at the v5 defaults (latest); not wired to any Settings key.
• Scope: the Invoke-Pester step (Test-ModuleLocal.yml, still v4.2.6) is intentionally untouched.
• Label note: the Settings contract is preserved (hence Patch), but consumer linting now runs against the latest PSScriptAnalyzer — bump to Minor if you'd rather signal that behavior change.

Release notes: Invoke-ScriptAnalyzer v5.0.0

v6.1.2

🪲 [Fix]: Test data reaches module tests in every consumer repository (#377)

Module test workflows now receive the caller-provided test data (secrets and variables) in every repository that consumes Process-PSModule, and version resolution once again honors the bump label on pull requests. Previously the BeforeAll, Test, and AfterAll module jobs failed at the "Expose caller-provided test data" step because they ran a script that shipped only inside Process-PSModule's own repository, so no consumer could actually use the TestData secret introduced in v6.0.0.

• Fixes #378

Fixed: Test data now reaches module tests in consumer repositories

The TestData secret (a single-line JSON object of secrets and variables) is now exposed to the BeforeAll, Test, and AfterAll module test jobs in any repository that consumes Process-PSModule. Each job installs the shared helpers and runs the Import-TestData command, which reads the payload, masks the secrets, and publishes every entry as an environment variable for the tests.

The consumer interface is unchanged — callers already pass TestData to workflow.yml (added in v6.0.0), so no migration is required:

secrets:
  TestData: >-
    { "secrets": { "TEST_SECRET": "${{ secrets.TEST_SECRET }}" },
      "variables": { "TEST_VARIABLE": ${{ toJSON(vars.TEST_VARIABLE) }} } }

Secrets arrive masked in the logs; variables arrive verbatim.

Fixed: Bump labels are honored during version resolution on pull requests

Version resolution now always evaluates the Major/Minor/Patch bump label, so a pull request labeled Minor previews the correct next minor version instead of defaulting to a patch prerelease. This is picked up by adopting Resolve-PSModuleVersion v1.1.4.

Technical Details

• Removed .github/scripts/Expose-TestData.ps1 (138 lines); the exposure logic moved into the shared PSModule/Install-PSModuleHelpers module as the Import-TestData command, so it no longer has to be checked out from the caller's repository.
• BeforeAll-ModuleLocal.yml, Test-ModuleLocal.yml, and AfterAll-ModuleLocal.yml each now install PSModule/Install-PSModuleHelpers@v1.0.9 and run Import-TestData (env PSMODULE_TEST_DATA: ${{ secrets.TestData }}) in place of the deleted script.
• Plan.yml: PSModule/Resolve-PSModuleVersion pinned to v1.1.4, which contains the always-evaluate-labels fix.
• Build-Site.yml: Install-PSModuleHelpers bumped v1.0.8 → v1.0.9 so the action resolves to a single version across the repo.
• README.md documents that test data is exposed through Install-PSModuleHelpers / Import-TestData.
• All action references are pinned to release commit SHAs (IPH v1.0.9 = 8bfb84d557755c67d9b5643efe573bdcae4c1a4a, Resolve v1.1.4 = 8d1dac7f326a45ba08060c1e24a5dd6f6f00b3ab); actionlint is clean.
• Validated end-to-end on a consumer module: all module test matrix jobs (Linux/Windows/macOS) pass, with a masked secret and a verbatim variable observed in the tests.

v6.1.1

🩹 [Patch]: Render group overview pages as section landing pages (#372)

Module documentation now renders a command group's overview page as that group's section landing page — the content shown when the group is selected in the navigation — instead of a separate page nested under it. This is delivered by bumping the Document-PSModule action, and the behavior is documented in the repository and module-source structure guidance.

• Fixes #371

Changed: Group overview pages are the section landing page

Bumped PSModule/Document-PSModule to v1.0.18 in Build-Docs.yml. v1.0.18 publishes a group's overview page as the section index (/Functions/<Group>/) rather than a page nested under the group. Authors can name the overview after its folder (<Category>/<Category>.md) or provide <Category>/index.md directly; either becomes the section landing page.

Changed: Documentation

Documented the behavior in README.md: added a bullet under the repository expectations and updated the Category.md annotation in the module source-structure tree.

Technical Details

• .github/workflows/Build-Docs.yml: Document-PSModule@fb5d349 # v1.0.17 -> @349090c # v1.0.18.
• main already carries v1.0.17 (install built modules at their real version) from #342; this PR advances the pin to v1.0.18, which delivers the section-index behavior.
• The site config already enables navigation.indexes, so no mkdocs.yml change is required.

v6.1.0

🚀 [Feature]: Plan job decides version before build so tested artifact equals published artifact (#342)

The version a module ships with is now decided in a new Plan job that runs before the module is built. The same artifact then flows through tests and publish without being mutated, so the artifact you tested is the artifact that lands in the PowerShell Gallery and on the GitHub Release.

• Fixes #326

New: Plan job replaces Get-Settings

Get-Settings.yml is renamed to Plan.yml. The Plan job runs two steps in sequence and exposes everything downstream jobs need:

1. Get-PSModuleSettings — loads .github/PSModule.yml and emits the resolved Settings JSON.
2. Resolve-PSModuleVersion — reads settings + PR labels, queries existing releases and the PowerShell Gallery, and emits the next version.

Plan job output: a single Settings JSON. The resolved version is merged into it as Settings.Module.{Version, Prerelease, FullVersion, ReleaseType, CreateRelease}, so every downstream job receives one self-contained object with no separate version outputs.

flowchart LR
  A[Plan<br/>Get-PSModuleSettings + Resolve-PSModuleVersion] --> B[Build-Module<br/>stamps version into manifest]
  B --> C[Test-* / Coverage]
  C --> D[Publish-Module<br/>publishes artifact unchanged]

Changed: Build-Module now stamps the real version

Build-Module.yml reads the version from Settings.Module.Version / Settings.Module.Prerelease and passes them to Build-PSModule. The built manifest contains the version the module will ship with before any test runs. The 999.0.0 placeholder only appears when no version is provided (for example, direct callers that bypass the Plan job).

Changed: Publish-Module no longer calculates or mutates versions

Publish-Module.yml drops every input that used to drive version calculation:

• AutoPatching
• DatePrereleaseFormat
• IgnoreLabels
• IncrementalPrerelease
• MajorLabels / MinorLabels / PatchLabels
• ReleaseType
• VersionPrefix

Publish-Module now reads the version straight from the manifest that arrived from Build-Module and pushes it to the PowerShell Gallery as-is. The PR-title / PR-body / heading inputs are unchanged. The job also gains permission to upload release assets so the zipped module can be attached to the GitHub Release.

Fixed: Tested artifact equals published artifact

The placeholder-then-rewrite flow is gone. The bytes tested in Test-Module / Test-ModuleLocal are the same bytes published to the PowerShell Gallery and attached to the GitHub Release.

Technical Details

• Plan.yml (renamed from Get-Settings.yml): adds a Resolve-Version step (runs unconditionally — it computes the release decision, including ReleaseType) followed by an Enrich-Settings step that merges the resolved version into Settings.Module.*. Plan exposes a single Settings output on both the job and workflow_call.
• workflow.yml: the Get-Settings job is renamed to Plan and every downstream needs: / with: reference is repointed. Downstream jobs consume the single needs.Plan.outputs.Settings object (version available under Settings.Module.*).
• Build-Module.yml: reads Settings.Module.Version / Settings.Module.Prerelease and passes them as Version / Prerelease to Build-PSModule, falling back to the 999.0.0 placeholder when a direct caller bypasses Plan and omits Settings.Module.
• Publish-Module.yml: removes the seven version-calculation inputs and grants contents: write permission for release-asset uploads.
• README.md: replaces the Get-Settings section with a Plan section that documents both steps and the artifact-integrity guarantee, and notes the new release-asset upload.
• PSModule/Build-PSModule pinned to @v5.0.0 (SHA 672aaa7a91a379c4c6cd14494d03ab5e87e13c52).
• PSModule/Publish-PSModule pinned to @v3.0.0 (SHA 03c0f8b53d0367c85a0f121f98af9b40c817b0e3).

Companion repos

Repo	Change	Link
PSModule/Resolve-PSModuleVersion	New action — v1.1.0 released	https://github.com/PSModule/Resolve-PSModuleVersion/releases/tag/v1.1.0
PSModule/Build-PSModule	Major — adds Version / Prerelease inputs — v5.0.0 released	https://github.com/PSModule/Build-PSModule/releases/tag/v5.0.0
PSModule/Publish-PSModule	Major / BREAKING — drops version calculation, publishes pre-stamped artifact, uploads module zip to release — v3.0.0 released	https://github.com/PSModule/Publish-PSModule/releases/tag/v3.0.0

Implementation plan progress

• Rename Get-Settings job to Plan and add Resolve-PSModuleVersion step
• Expose a single Settings output (resolved version merged into Settings.Module.{Version, Prerelease, FullVersion, ReleaseType, CreateRelease})
• Update Build-Module.yml to read the version from Settings.Module.* and stamp it
• Strip version-calculation inputs from Publish-Module.yml
• Update needs / with wiring across workflow.yml
• Update README.md (Plan section + release-asset note)
• Resolve-PSModuleVersion action implementation (v1.1.0 released)
• Build-PSModule Version/Prerelease inputs (v5.0.0 released)
• Publish-PSModule v3 release (v3.0.0 released — PSModule/Publish-PSModule#71)
• Repin @main references in Build-Module.yml and Publish-Module.yml to released SHAs
• End-to-end run on a labeled PR

Notes

• The public input/output contract of workflow.yml is unchanged for external consumers — this is internal wiring.
• #339 covered the same scope and was closed; this PR restarts the work cleanly off the current main.

v6.0.1

Bump PSModule/GitHub-Script from 1.8.0 to 1.9.0 (#367)

Bumps PSModule/GitHub-Script from 1.8.0 to 1.9.0.

• Pin: 8083ec1f733f00357ee4d0db0c6056686e483bc0 (# v1.9.0)
• Release notes: https://github.com/PSModule/GitHub-Script/releases/tag/v1.9.0

v6.0.0

🌟 [Major]: Fixed test secret inputs replaced by TestData (#365)

Module test jobs now use a TestData object for optional test secrets and non-secret variables. This replaces the previous fixed TEST_* workflow secret inputs: callers that used those inputs must pass the same names inside TestData, while callers that need different names can expose them without changing the shared workflow.

• Fixes #52

Breaking Changes

Removed: fixed TEST_* workflow secret inputs

The reusable workflow no longer declares or accepts these individual test-secret inputs:

• TEST_APP_ENT_CLIENT_ID
• TEST_APP_ENT_PRIVATE_KEY
• TEST_APP_ORG_CLIENT_ID
• TEST_APP_ORG_PRIVATE_KEY
• TEST_USER_ORG_FG_PAT
• TEST_USER_USER_FG_PAT
• TEST_USER_PAT

Callers using any of these inputs must move them into the secrets map inside TestData. The names can stay the same, so existing Pester tests can continue reading the same environment variables.

jobs:
  Process-PSModule:
    uses: PSModule/Process-PSModule/.github/workflows/workflow.yml@v5
    secrets:
      APIKey: ${{ secrets.APIKey }}
      TestData: >-
        {
          "secrets": {
            "TEST_USER_PAT": "${{ secrets.TEST_USER_PAT }}",
            "TEST_APP_ORG_CLIENT_ID": "${{ secrets.TEST_APP_ORG_CLIENT_ID }}"
          }
        }

$env:TEST_USER_PAT
$env:TEST_APP_ORG_CLIENT_ID

New: Caller-selected TestData

TestData is an optional single-line JSON object with secrets and variables maps. Entries from both maps become environment variables in BeforeAll-ModuleLocal, Test-ModuleLocal, and AfterAll-ModuleLocal.

TestData: >-
  {
    "secrets": {
      "CONFLUENCE_API_TOKEN": "${{ secrets.CONFLUENCE_API_TOKEN }}"
    },
    "variables": {
      "CONFLUENCE_SITE": ${{ toJSON(vars.CONFLUENCE_SITE) }},
      "CONFLUENCE_SPACE_KEY": ${{ toJSON(vars.CONFLUENCE_SPACE_KEY) }}
    }
  }

$env:CONFLUENCE_API_TOKEN # from the secrets map, masked in logs
$env:CONFLUENCE_SITE      # from the variables map, not masked

Values under secrets are masked before being exposed to the test jobs. Values under variables are exposed without masking for normal, non-sensitive configuration. Modules that do not need secrets or variables can omit TestData entirely.

Because the workflow does not use secrets: inherit, only the values explicitly listed in TestData are exposed to module tests.

New: Safe TestData validation and formatting

TestData must parse as a JSON object containing only optional secrets and variables maps. Values in those maps must be scalar values. Keys must be safe environment-variable names matching ^[A-Za-z_][A-Za-z0-9_]*$, must not be duplicated across secrets and variables, and must not override reserved variables such as PATH, CI, GITHUB_*, RUNNER_* or ACTIONS_*.

Pass TestData as a single-line value after YAML folding. The folded >- form is safe when the JSON is compact, or when every JSON content line stays at the same indentation level inside the block.

Avoid normal pretty-printed JSON with nested indentation inside >-. YAML preserves more-indented lines instead of folding them, so that shape can still produce a multi-line secret value. Keeping TestData single-line after folding avoids GitHub treating line fragments as separate mask values.

Use the direct quoted form for single-line secrets:

"CONFLUENCE_API_TOKEN": "${{ secrets.CONFLUENCE_API_TOKEN }}"

Using the JSON-encoded approach, github-advanced security will warn that all secrets available to the runner gets exposed.

"CONFLUENCE_API_TOKEN": ${{ toJSON(vars.CONFLUENCE_API_TOKEN) }}

Use toJSON(vars.NAME) for variables so normal configuration values are JSON-encoded safely:

"CONFLUENCE_SITE": ${{ toJSON(vars.CONFLUENCE_SITE) }}

For multi-line secrets, or secrets containing quotes or backslashes, base64-encode the secret and decode it in the test.

Technical Details

• workflow.yml declares and forwards a single optional TestData secret instead of the seven fixed TEST_* secrets.
• .github/scripts/Expose-TestData.ps1 contains the shared TestData parsing, validation, masking, and UTF-8 GITHUB_ENV export logic used by the ModuleLocal workflows.
• BeforeAll-ModuleLocal.yml, Test-ModuleLocal.yml, and AfterAll-ModuleLocal.yml call the shared helper instead of duplicating the security-sensitive exposure logic.
• Test-Module.yml no longer declares or exports the obsolete fixed TEST_* secrets.
• The fixture-backed self-test workflows skip forked pull_request runs where repository secrets and variables are unavailable, while still running for trusted PRs, schedules, and manual dispatches.
• The parse failure path uses stable messages that do not echo the raw secret payload, and secret keys are no longer printed in logs.
• The self-test workflows pass dedicated fixture data through TestData, and the environment Pester tests assert the exact exposed secret and variable values.
• README.md documents the breaking migration path, the TestData contract, safe YAML folding, safe key names, environment-scoped value usage, the difference between masked secrets and unmasked variables, and base64 guidance for complex secret values.
• The diff also addresses #322's duplicated fixed-secret pass-through without adopting broad secrets: inherit.

v5.5.9

🪲 [Fix]: Restore correct release versioning in the publish pipeline (#363)

The module publishing pipeline once again calculates and stamps the real release version before publishing, so consumer releases are versioned and tagged correctly instead of shipping the build-time placeholder. This reverts the premature Publish-PSModule major upgrade that left main in an inconsistent state.

• Relates to #326 (move version calculation ahead of the build step)
• Contains the regression introduced by #358

Fixed: Releases are versioned correctly again

Publish-PSModule is pinned back to v2.2.4, which calculates the release version (from labels and tags) and stamps it into the module manifest at publish time. On main, Build-PSModule (v4) only stamps a 999.0.0 placeholder and does not compute the real version, and Publish-PSModule v3.0.0 is publish-only — it expects the manifest to already carry the final version. With v3.0.0 in place, nothing in the pipeline computed the real version, so a real consumer release would have published and tagged 999.0.0. Reverting to v2.2.4 restores the fully consistent old pipeline: Get-Settings → Build (v4, 999.0.0) → Publish (v2.2.4, calculates + stamps).

Only the Publish-PSModule pin is reverted. The other action bumps from #358 (actions/checkout v7.0.0, super-linter v8.7.0) are left in place.

Technical Details

• .github/workflows/Publish-Module.yml: PSModule/Publish-PSModule pin reverted 03c0f8b… # v3.0.0 → 8917aed… # v2.2.4. This is the exact pin #358 replaced; no with: inputs changed — v2.2.4 consumes the version-calculation inputs the workflow already passes, whereas v3.0.0 silently ignored them.
• .github/workflows/Publish-Module.yml: normalized the APIKey action input from secrets.APIKEY to secrets.APIKey to match the APIKey secret declaration and the other workflows (workflow.yml, Workflow-Test-*.yml). GitHub Actions secret names are case-insensitive, so this is a consistency-only change with no behavioral effect (flagged during Copilot review).
• This is step 1 (containment) of #326. Follow-ups: release Resolve-PSModuleVersion with the #348 fix, then rebase and land PR #342 (Plan job + Build v5 + publish-only Publish) and re-pin the first-party actions together.

v5.5.8

[Patch]: Update GitHub Actions dependencies to latest pinned versions (#358)

Consolidates the currently-passing Dependabot GitHub Actions updates into one change, so the pipeline moves to the latest action versions in a single release instead of separate bumps. It also configures Dependabot to group future GitHub Actions updates into one pull request, so this consolidated form happens automatically from now on.

Superseded Dependabot PRs: #351, #353, #354, #355 — Dependabot closes these automatically once this merges.

⚠️ Build-PSModule v5.0.0 (#350) is intentionally excluded. v5 makes moduleVersion a required input, which the current Build-Module.yml does not provide, so it fails CI (6 checks on #350's own PR too). Adopting it needs the "decide version before build" work in #342 and should ship with/after that PR. #350 stays open to track it.

Updated GitHub Actions

Action	From	To	Bump
actions/checkout	v6.0.2	v7.0.0	Major
PSModule/Publish-PSModule	v2.2.4	v3.0.0	Major
super-linter/super-linter	v8.6.0	v8.7.0	Minor
super-linter/super-linter/slim	v8.6.0	v8.7.0	Minor

This bundle includes two major action upgrades, so it is labelled Major and cuts a major release of Process-PSModule on merge.

Changed: Dependabot groups GitHub Actions updates

.github/dependabot.yml now groups all github-actions updates into a single grouped pull request via a groups block. The github_actions label is also corrected — it was github-actions, which does not match the repository label and was silently dropped by Dependabot.

Technical Details

• Each bump is a cherry-pick of the original Dependabot commit, preserving authorship and the Bump X from A to B messages for a clean linear history.

• All bumps touch only uses: pins under .github/workflows/; no logic changes.

• Dependabot grouping added:

  groups:
    github-actions:
      patterns:
        - "*"

  This groups every GitHub Actions ecosystem update (all semver levels) into one PR. To keep major bumps as separate PRs for individual review, add update-types: ["minor", "patch"] under the group — majors then continue to open on their own.

• No linked issue: this is Dependabot-driven maintenance; the superseded PRs above are the traceability.

v5.5.7

Bump PSModule/GitHub-Script from 1.7.10 to 1.8.0 (#346)

Bumps PSModule/GitHub-Script from 1.7.10 to 1.8.0.

Release notes

Sourced from PSModule/GitHub-Script's releases.

v1.8.0

🚀 [Minor]: GitHub API rate limit details now available in action logs (#89)

GitHub API rate limit consumption is now visible directly in the action logs. When enabled, rate limit details - including remaining quota, limit, used count, and reset time for all resource categories - are displayed before and after the user script runs, making it easy to see exactly how many API calls a workflow step consumed.

• Fixes #88

New: Rate limit visibility in action logs

A new ShowRateLimit input (default: 'false') controls whether rate limit information appears in the logs. When set to 'true', a Rate Limits LogGroup appears inside the Info fence before the user script, and another Rate Limits LogGroup appears inside the Outputs fence after it.

- uses: PSModule/GitHub-Script@v1
  with:
    ShowRateLimit: 'true'
    Script: |
      Get-GitHubRepository -Owner PSModule -Name GitHub-Script

The output includes a formatted table of all resource categories returned by Get-GitHubRateLimit (core, search, graphql, etc.), each showing Limit, Used, Remaining, ResetsAt, and ResetsIn.

When the input is omitted or set to 'false' (the default), no rate limit output appears.

If ShowRateLimit is enabled but ShowInfo or ShowOutput is off, the corresponding fence still renders with just the rate limit content inside. For auth types that do not support Get-GitHubRateLimit (for example GitHub App contexts), a warning is shown instead of failing.

Technical Details

• Added ShowRateLimit input to action.yml with required: false and default: 'false'.
• Added PSMODULE_GITHUB_SCRIPT_INPUT_ShowRateLimit environment variable to the composite step.
• Created src/ratelimit.ps1 as a helper script (no fence borders) that checks the guard and renders a single Rate Limits LogGroup.
• src/ratelimit.ps1 now calls Get-GitHubRateLimit -ErrorAction Stop so non-terminating errors are caught reliably in unsupported auth contexts.
• src/ratelimit.ps1 explicitly selects Name, Limit, Used, Remaining, ResetsAt, and ResetsIn before formatting to keep columns deterministic.
• Modified src/info.ps1: adjusted the early-return guard to also consider ShowRateLimit, wrapped existing LogGroups in if ($showInfo), and calls ratelimit.ps1 before the fence close.
• Modified src/outputs.ps1: adjusted the early-return guard to also consider ShowRateLimit, wrapped existing output LogGroups in if ($result), and calls ratelimit.ps1 before the fence close.
• The action.yml run block remains in the same flow, while info.ps1 and outputs.ps1 invoke the helper internally.
• Enabled ShowRateLimit: true across all Action-Test scenarios in .github/workflows/TestWorkflow.yml, including Basic, WithScript path variants, Commands + Outputs, Matrix Creator, WithoutToken, WithPAT, WithUserFGPAT, WithOrgFGPAT, GitHubAppEnt, GitHubAppOrg + quoted inputs, WithKeyVaultKeyReference, WithKeyVaultKeyReferenceLatest, and PreserveCredentials False.

Commits

• 1ee97bb 🚀 [Minor]: GitHub API rate limit details now available in action logs (#89)
• 8649c46 Bump azure/login from 2.3.0 to 3.0.0 (#86)
• e3b0111 ⚙️ [Maintenance]: Add afterall to codespell ignore words list (#85)
• 2d8efc6 Bump super-linter/super-linter from 8.4.0 to 8.5.0 (#84)
• 611c5dc ⚙️ [Maintenance]: Update super-linter to v8.4.0 (#83)
• 99556fc ⚙️ [Maintenance]: Align workflows across action repositories (#82)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)