Forty-three repositories in this organization have had no working CI since at least 12 August. Every workflow run fails in its first job, before any build, lint, test, or publish work happens.
Context and request
Current experience
A repository pinned to Process-PSModule v5 fails immediately:
##[error]Unable to resolve action psmodule/get-psmodulesettings, repository not found
PSModule/get-PSModuleSettings no longer exists. The v5 workflow references it, so Get-Settings fails after roughly two seconds and every downstream job is skipped. The run reports failure with no signal about the code, and a pull request against such a repository gets no meaningful checks at all.
Measured on 2026-08-15 across the organization, matching on the version comment in each repository's .github/workflows/Process-PSModule.yml:
| Pin |
Repositories |
| v6 or later |
17 |
| v5 |
43 |
The 43 on v5 are: Markdown, Fonts, PSCustomObject, Lua, Net, Context, ElvUI, Hcl, Json, PowerShellGallery, CasingStyle, WoW, Utilities, Uri, Twitch, Tls, TimeSpan, Telemetry, Retry, PublicIP, PSCredential, PowerShellDataFile, Path, OpenAI, Object, MemoryMappedFile, LinkedIn, IPv6, IPv4, GZip, Guid, GraphQL, Gemini, DynamicParams, Dns, Discord, DeepSeek, DateTime, CurseForge, Context7, Claude, Bluesky, Base64.
A sample of five was checked directly rather than inferred from the pin alone — Base64, Context, Utilities, Uri, and Guid all show failing runs on main.
Why this is not a per-repository maintenance task
The breakage did not come from any of these repositories. Each was correct when pinned, and each broke when an action referenced by the version they pin was removed. Removing get-PSModuleSettings was a breaking change for every consumer of v5, and v5 remains the pinned version on most of the organization.
Dependabot does raise the bump — for example PSModule/Markdown#35 — but it opens one pull request per repository, each needing review, and those pull requests are themselves checked by the broken CI. The repository that most needs the update is the least able to demonstrate the update works.
Desired experience
A repository pinned to a supported major version of the shared workflow keeps working, or fails with an error naming what to update and why. Retiring an action does not silently break every consumer still on the previous major.
Acceptance criteria
- Repositories pinned to v5 either run successfully or fail with a diagnostic that names the required upgrade.
- The 43 repositories listed above have working CI again.
- Retiring an action referenced by a released major version is recognized as a breaking change for consumers of that major, with a defined path for them.
Technical decisions
Open: repair v5 or drive the upgrade. Restoring resolvability for v5 — reinstating the action, or removing the reference from the v5 branch — fixes all 43 without touching them, and keeps working what was previously working. Driving every repository to v6 fixes it once and permanently but requires 43 reviewed pull requests through CI that does not currently run. The two are not exclusive: repairing v5 first is what makes the upgrade pull requests reviewable.
Open: how the upgrade is propagated. Dependabot's per-repository pull requests are the current mechanism and have not landed. Whether propagation should be a coordinated sweep is a separate question from restoring service.
Not a versioning failure at the call site. Every affected repository pins by SHA with a version comment, which is the recommended practice. The pin behaved exactly as intended; what changed was the content the major version resolves to.
Implementation plan
Forty-three repositories in this organization have had no working CI since at least 12 August. Every workflow run fails in its first job, before any build, lint, test, or publish work happens.
Context and request
Current experience
A repository pinned to
Process-PSModulev5 fails immediately:PSModule/get-PSModuleSettingsno longer exists. The v5 workflow references it, soGet-Settingsfails after roughly two seconds and every downstream job is skipped. The run reports failure with no signal about the code, and a pull request against such a repository gets no meaningful checks at all.Measured on 2026-08-15 across the organization, matching on the version comment in each repository's
.github/workflows/Process-PSModule.yml:The 43 on v5 are: Markdown, Fonts, PSCustomObject, Lua, Net, Context, ElvUI, Hcl, Json, PowerShellGallery, CasingStyle, WoW, Utilities, Uri, Twitch, Tls, TimeSpan, Telemetry, Retry, PublicIP, PSCredential, PowerShellDataFile, Path, OpenAI, Object, MemoryMappedFile, LinkedIn, IPv6, IPv4, GZip, Guid, GraphQL, Gemini, DynamicParams, Dns, Discord, DeepSeek, DateTime, CurseForge, Context7, Claude, Bluesky, Base64.
A sample of five was checked directly rather than inferred from the pin alone — Base64, Context, Utilities, Uri, and Guid all show failing runs on
main.Why this is not a per-repository maintenance task
The breakage did not come from any of these repositories. Each was correct when pinned, and each broke when an action referenced by the version they pin was removed. Removing
get-PSModuleSettingswas a breaking change for every consumer of v5, and v5 remains the pinned version on most of the organization.Dependabot does raise the bump — for example PSModule/Markdown#35 — but it opens one pull request per repository, each needing review, and those pull requests are themselves checked by the broken CI. The repository that most needs the update is the least able to demonstrate the update works.
Desired experience
A repository pinned to a supported major version of the shared workflow keeps working, or fails with an error naming what to update and why. Retiring an action does not silently break every consumer still on the previous major.
Acceptance criteria
Technical decisions
Open: repair v5 or drive the upgrade. Restoring resolvability for v5 — reinstating the action, or removing the reference from the v5 branch — fixes all 43 without touching them, and keeps working what was previously working. Driving every repository to v6 fixes it once and permanently but requires 43 reviewed pull requests through CI that does not currently run. The two are not exclusive: repairing v5 first is what makes the upgrade pull requests reviewable.
Open: how the upgrade is propagated. Dependabot's per-repository pull requests are the current mechanism and have not landed. Whether propagation should be a coordinated sweep is a separate question from restoring service.
Not a versioning failure at the call site. Every affected repository pins by SHA with a version comment, which is the recommended practice. The pin behaved exactly as intended; what changed was the content the major version resolves to.
Implementation plan
get-PSModuleSettingswas removed deliberately and whether v5 can be made resolvable againmainsucceed again