🚀 [Feature]: Version input accepts NuGet version ranges (#98)

The `Version` input now accepts a NuGet version range in addition to an
exact version, so a workflow can pin a compatible window (for example
`[1.2.0, 2.0.0)`) instead of a single build. Pinning an exact version
keeps working exactly as before, and a version that is already installed
and satisfies the request is no longer reinstalled on every run.

- Fixes #97

## New: NuGet version ranges for the `Version` input

`Version` accepts the same syntax as
[`Install-PSResource`](https://learn.microsoft.com/powershell/module/microsoft.powershell.psresourceget/install-psresource):

| `Version` example | Meaning |
| --- | --- |
| `1.2.3` | Exactly `1.2.3` |
| `[1.2.3]` | Exactly `1.2.3` |
| `[1.2.0, ]` | `1.2.0` or newer |
| `(, 2.0.0)` | Any version lower than `2.0.0` |
| `[1.2.0, 2.0.0)` | `1.2.0` up to but not including `2.0.0` |

A bare version is treated as an *exact* version (not a minimum), so
existing pins are unaffected. PSResourceGet resolves a range to the
lowest satisfying version.

## Fixed: a satisfying version is reused instead of reinstalled

Previously, supplying anything other than an exact version caused the
module to be reinstalled on every run: the already-installed check
compared the raw input to installed versions with exact string equality,
which never matches a range. The check now honors ranges, so an
already-installed version that satisfies the request is reused.

## Technical Details

- `src/init.ps1`: the already-installed lookup now passes the value to
`Get-InstalledPSResource -Name $Name -Version $Version` instead of
piping to `Where-Object Version -EQ`. The redundant `Where-Object
Prerelease -EQ` filter was removed — prerelease handling is governed by
the `-Prerelease` switch passed to `Install-PSResource`. The retry loop
(5 attempts, 10s delay) around `Install-PSResource` is unchanged.
- `action.yml` / `README.md`: the `Version` input is documented as
accepting an exact version or a NuGet version range, with an examples
table and a note that a bare version is exact.
- Tests (`.github/workflows/TestWorkflow.yml`): added `Version [Exact]`,
`Version [Bounded range]`, `Version [Minimum range]`, and `Version
[Already installed]` jobs (Linux; version resolution is OS-independent).
Written test-first — the already-installed job failed on the unfixed
code (two installed versions) and passes after the fix. Because these
jobs use `Prerelease: ${{ inputs.Prerelease }}`, they also exercise the
prerelease + range combination when run via
`Action-Test-Prerelease.yml`.
- Implementation plan progress: all tasks in #97 are complete.

Backward compatibility: exact-version pins resolve identically; only the
unnecessary-reinstall behavior changes.

🚀 [Feature]: Version input accepts NuGet version ranges (#98)

The `Version` input now accepts a NuGet version range in addition to an
exact version, so a workflow can pin a compatible window (for example
`[1.2.0, 2.0.0)`) instead of a single build. Pinning an exact version
keeps working exactly as before, and a version that is already installed
and satisfies the request is no longer reinstalled on every run.

- Fixes #97

## New: NuGet version ranges for the `Version` input

`Version` accepts the same syntax as
[`Install-PSResource`](https://learn.microsoft.com/powershell/module/microsoft.powershell.psresourceget/install-psresource):

| `Version` example | Meaning |
| --- | --- |
| `1.2.3` | Exactly `1.2.3` |
| `[1.2.3]` | Exactly `1.2.3` |
| `[1.2.0, ]` | `1.2.0` or newer |
| `(, 2.0.0)` | Any version lower than `2.0.0` |
| `[1.2.0, 2.0.0)` | `1.2.0` up to but not including `2.0.0` |

A bare version is treated as an *exact* version (not a minimum), so
existing pins are unaffected. PSResourceGet resolves a range to the
lowest satisfying version.

## Fixed: a satisfying version is reused instead of reinstalled

Previously, supplying anything other than an exact version caused the
module to be reinstalled on every run: the already-installed check
compared the raw input to installed versions with exact string equality,
which never matches a range. The check now honors ranges, so an
already-installed version that satisfies the request is reused.

## Technical Details

- `src/init.ps1`: the already-installed lookup now passes the value to
`Get-InstalledPSResource -Name $Name -Version $Version` instead of
piping to `Where-Object Version -EQ`. The redundant `Where-Object
Prerelease -EQ` filter was removed — prerelease handling is governed by
the `-Prerelease` switch passed to `Install-PSResource`. The retry loop
(5 attempts, 10s delay) around `Install-PSResource` is unchanged.
- `action.yml` / `README.md`: the `Version` input is documented as
accepting an exact version or a NuGet version range, with an examples
table and a note that a bare version is exact.
- Tests (`.github/workflows/TestWorkflow.yml`): added `Version [Exact]`,
`Version [Bounded range]`, `Version [Minimum range]`, and `Version
[Already installed]` jobs (Linux; version resolution is OS-independent).
Written test-first — the already-installed job failed on the unfixed
code (two installed versions) and passes after the fix. Because these
jobs use `Prerelease: ${{ inputs.Prerelease }}`, they also exercise the
prerelease + range combination when run via
`Action-Test-Prerelease.yml`.
- Implementation plan progress: all tasks in #97 are complete.

Backward compatibility: exact-version pins resolve identically; only the
unnecessary-reinstall behavior changes.

🚀 [Feature]: Version input accepts NuGet version ranges (#98)

The `Version` input now accepts a NuGet version range in addition to an
exact version, so a workflow can pin a compatible window (for example
`[1.2.0, 2.0.0)`) instead of a single build. Pinning an exact version
keeps working exactly as before, and a version that is already installed
and satisfies the request is no longer reinstalled on every run.

- Fixes #97

## New: NuGet version ranges for the `Version` input

`Version` accepts the same syntax as
[`Install-PSResource`](https://learn.microsoft.com/powershell/module/microsoft.powershell.psresourceget/install-psresource):

| `Version` example | Meaning |
| --- | --- |
| `1.2.3` | Exactly `1.2.3` |
| `[1.2.3]` | Exactly `1.2.3` |
| `[1.2.0, ]` | `1.2.0` or newer |
| `(, 2.0.0)` | Any version lower than `2.0.0` |
| `[1.2.0, 2.0.0)` | `1.2.0` up to but not including `2.0.0` |

A bare version is treated as an *exact* version (not a minimum), so
existing pins are unaffected. PSResourceGet resolves a range to the
lowest satisfying version.

## Fixed: a satisfying version is reused instead of reinstalled

Previously, supplying anything other than an exact version caused the
module to be reinstalled on every run: the already-installed check
compared the raw input to installed versions with exact string equality,
which never matches a range. The check now honors ranges, so an
already-installed version that satisfies the request is reused.

## Technical Details

- `src/init.ps1`: the already-installed lookup now passes the value to
`Get-InstalledPSResource -Name $Name -Version $Version` instead of
piping to `Where-Object Version -EQ`. The redundant `Where-Object
Prerelease -EQ` filter was removed — prerelease handling is governed by
the `-Prerelease` switch passed to `Install-PSResource`. The retry loop
(5 attempts, 10s delay) around `Install-PSResource` is unchanged.
- `action.yml` / `README.md`: the `Version` input is documented as
accepting an exact version or a NuGet version range, with an examples
table and a note that a bare version is exact.
- Tests (`.github/workflows/TestWorkflow.yml`): added `Version [Exact]`,
`Version [Bounded range]`, `Version [Minimum range]`, and `Version
[Already installed]` jobs (Linux; version resolution is OS-independent).
Written test-first — the already-installed job failed on the unfixed
code (two installed versions) and passes after the fix. Because these
jobs use `Prerelease: ${{ inputs.Prerelease }}`, they also exercise the
prerelease + range combination when run via
`Action-Test-Prerelease.yml`.
- Implementation plan progress: all tasks in #97 are complete.

Backward compatibility: exact-version pins resolve identically; only the
unnecessary-reinstall behavior changes.

🚀 [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.

```yaml
- 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.

---------

Co-authored-by: anthropic-code-agent[bot] <242468646+Claude@users.noreply.github.com>

🚀 [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.

```yaml
- 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.

---------

Co-authored-by: anthropic-code-agent[bot] <242468646+Claude@users.noreply.github.com>

🩹 [Patch]: Standardize project structure and rename release workflow (#…

…81)

This PR standardizes the project structure and updates workflows to
align with PSModule conventions.

## Changed

- Rename `Auto-Release.yml` workflow to `Release.yml` for consistency
- Update release action from `PSModule/Auto-Release@v1.9.5` to
`PSModule/Release-GHRepository@v2`
- Rename `scripts/` folder to `src/` to follow standard project layout
- Update `action.yml` to reference scripts from new `src/` location
- Add linter workflow configuration

## Removed

- Remove unused `.jscpd.json` linter configuration file

## Summary

This PR brings the GitHub-Script action in line with PSModule's
standardized project structure. The `scripts/` folder is renamed to
`src/` for consistency across all actions, and the release workflow is
updated to use the renamed `Release-GHRepository` action.

🩹 [Patch]: Standardize project structure and rename release workflow (#…

…81)

This PR standardizes the project structure and updates workflows to
align with PSModule conventions.

## Changed

- Rename `Auto-Release.yml` workflow to `Release.yml` for consistency
- Update release action from `PSModule/Auto-Release@v1.9.5` to
`PSModule/Release-GHRepository@v2`
- Rename `scripts/` folder to `src/` to follow standard project layout
- Update `action.yml` to reference scripts from new `src/` location
- Add linter workflow configuration

## Removed

- Remove unused `.jscpd.json` linter configuration file

## Summary

This PR brings the GitHub-Script action in line with PSModule's
standardized project structure. The `scripts/` folder is renamed to
`src/` for consistency across all actions, and the release workflow is
updated to use the renamed `Release-GHRepository` action.

🩹[Patch]: Update workflow configurations (#79)

Updates workflow configurations to use the latest pinned action versions
for improved security and reproducibility.

- Related to PSModule workflow standardization

## Action pinning

Pinned all GitHub Actions to specific commit SHAs:

- `actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd` (v6.0.2) -
Updated from v6.0.1

🩹 [Patch]: Remove output access hints from logs (#55)

Removes the output access hint text from the action logs to avoid
confusion when the action is used directly or nested in another
composite action. The output grouping and output content display remain
unchanged.

- Fixes #54

## Changes

- Remove access-hint printing in `scripts/outputs.ps1`
- Simplify composite output test by removing access-pattern demo and
help-text validation

## Rationale

The access pattern differs for direct vs nested usage, so printed hints
can be misleading. Removing the hint avoids confusion while still
showing the output values.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: MariusStorhaug <17722253+MariusStorhaug@users.noreply.github.com>
Co-authored-by: Marius Storhaug <marstor@hotmail.com>

🩹[Patch]: CI and workflow maintenance updates (#76)

This release updates CI and workflow maintenance for the GitHub-Script
action.

### Changes
- Super-linter updated to v8.3.2 and Biome format validation disabled
for this repo.
- Checkout action pins refreshed across workflows.
- Dependabot schedule moved to daily with a 7‑day cooldown.
- Action test workflows now pass explicit secrets instead of inheriting.
- Auto-Release workflow now runs on pull_request events.

### Notes
- No changes to action.yml behavior or runtime output.

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Marius Storhaug <marstor@hotmail.com>