Skip to content

refactor(workflow): add dispatch inputs and replace isPrerelease with force#468

Merged
HeyItsGilbert merged 3 commits into
mainfrom
refactor/publish-workflow-inputs
May 30, 2026
Merged

refactor(workflow): add dispatch inputs and replace isPrerelease with force#468
HeyItsGilbert merged 3 commits into
mainfrom
refactor/publish-workflow-inputs

Conversation

@HeyItsGilbert

Copy link
Copy Markdown
Member

Summary

Aligns with PowerShellOrg/.github#12.

  • Adds version, force, and dry_run to workflow_dispatch inputs (previously no manual inputs were exposed)
  • force bypasses the PSGallery existence check when re-triggering a failed job — previously there was no way to do this without a code change

Re-trigger pattern

If create_release succeeds but publish fails (e.g. expired secret), re-trigger with:
force=true, create_release=false, publish=true

🤖 Generated with Claude Code

HeyItsGilbert and others added 3 commits May 30, 2026 09:12
… force

Aligns with PowerShellOrg/.github#12 which removes isPrerelease (now
inferred from PSData.Prerelease in the manifest) and adds force to
bypass the PSGallery existence check when re-triggering a failed job.

Also exposes version and dry_run via workflow_dispatch for manual runs.

Re-trigger pattern: force=true, create_release=false, publish=true

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Required to actually use the force re-trigger pattern documented in the
previous commit. Without these inputs, operators could not set
create_release=false when re-triggering a failed publish job.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
inputs context is empty on non-dispatch triggers; the previous
`!= false` expression evaluated empty as equal to false under
GitHub Actions loose comparison, skipping both jobs on push.

Use `github.event_name != 'workflow_dispatch' || inputs.X` instead:
short-circuits to true on push, falls through to the explicit input
value on dispatch.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

Test Results

  3 files  213 suites   32s ⏱️
243 tests 241 ✅ 2 💤 0 ❌
729 runs  723 ✅ 6 💤 0 ❌

Results for commit abefe57.

@HeyItsGilbert HeyItsGilbert merged commit ef24468 into main May 30, 2026
6 of 7 checks passed
HeyItsGilbert added a commit that referenced this pull request Jun 19, 2026
## Summary

The `Run Tests (PowerShell 5.1)` CI job has been failing on every PR
(e.g. #468, #469, #470) during `build.ps1 -Bootstrap` with:

```
PSDepend\0.3.8\Private\SemanticVersion.ps1: Cannot add type.
The type name 'System.Management.Automation.SemanticVersion' already exists.
```

### Root cause

PSDepend `0.3.8` ships an **unguarded** `Add-Type` for its Windows
PowerShell 5.1 `SemanticVersion` polyfill:

```powershell
if ($PSVersionTable.PSVersion.Major -lt 6) {
  Add-Type -TypeDefinition $code
}
```

On PS 5.1, `System.Management.Automation.SemanticVersion` is not a
built-in type, so this runs. When PSDepend is imported a **second time**
in the same session — which the bootstrap triggers because PSDepend is
pinned as a dependency of itself in `requirements.psd1` — the `Add-Type`
throws, since the type already exists in the AppDomain. PowerShell 6+ is
unaffected: the type is built in, so the guard short-circuits.

PSDepend `0.4.1` (newly released) adds the missing existence guard,
making the polyfill idempotent:

```powershell
if ($PSVersionTable.PSVersion.Major -lt 6 -and -not ('System.Management.Automation.SemanticVersion' -as [type])) {
  Add-Type -TypeDefinition $code
}
```

### Fix

Bump the PSDepend pin in `requirements.psd1` from `0.3.8` → `0.4.1`.

## Reproduction / verification

Reproduced on local Windows PowerShell 5.1 (`5.1.26100`) by pre-defining
the type then dot-sourcing each version's `SemanticVersion.ps1`:

| PSDepend | Result |
| --- | --- |
| `0.3.8` | ❌ `Cannot add type. The type name
'System.Management.Automation.SemanticVersion' already exists.` |
| `0.4.1` | ✅ no-op (guard skips `Add-Type`) |

CI will confirm the PS 5.1 job goes green on this PR.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
HeyItsGilbert added a commit that referenced this pull request Jun 19, 2026
## Summary

Make module releases run on every push to `main`, replacing the two
broken release workflows with a single fixed one.

Both prior workflows were broken against the current reusable
`PowerShellOrg/.github/.github/workflows/powershell-release.yml@main`:

- **`publish.yaml`** (push-to-`main`) startup-failed on every push to
`main` — it passed an `isPrerelease` input that #468 removed.
- **`release.yml`** (tag-triggered) never ran on merges and was itself
broken: it passed a `module-name` input the reusable workflow does not
declare, and a non-existent `PSGALLERY_API_KEY` secret.

### Approach

Rename `release.yml` → `publish.yaml` and fix it. The reusable workflow
is designed for the push-to-`main` model: its `check_version` job
compares the manifest `ModuleVersion` against PSGallery and gates both
`create_release` and `publish` on `(version_bumped || force)`. So
running it on every push to `main` only actually tags/publishes when the
manifest version is new — a normal merge that doesn't bump the version
is a no-op.

### Changes

- Trigger on `push: branches: [main]` (+ `workflow_dispatch` for
manual/`force` re-runs) instead of `push: tags: ['v*']`.
- Drop the `module-name: Plaster` input — not declared by the reusable
workflow (it derives the module name itself); passing it caused a
startup failure.
- Pass the secret as `PS_GALLERY_KEY` (the reusable's required secret
name), sourced from the repo's existing `PS_GALLERY_KEY` secret.
- Remove the duplicate/broken `release.yml`.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant