Evaluate moving publish workflow from Windows to Linux

[iwizsophy]

Summary

Migrate the Publish workflow from windows-latest to ubuntu-24.04, or document the concrete blocker if Linux cannot support the current publish flow.

Background

Current GitHub Actions runner usage is split as follows:

• CI jobs (build, test, analyzer, pack) run on ubuntu-24.04
• Publish runs on windows-latest

At the workflow-definition level, Publish appears to use cross-platform tools only:

• actions/checkout
• pwsh
• git
• dotnet
• gh
• NuGet/login

This makes the remaining Windows requirement unclear and worth validating explicitly.

Problem

Keeping Publish on Windows without a documented technical reason has costs:

• the release path differs from the rest of CI
• runner behavior is less uniform across workflows
• troubleshooting platform-specific failures becomes harder
• future release workflow changes have to account for an otherwise isolated Windows environment

Proposal

Evaluate and, if viable, migrate Publish to ubuntu-24.04.

Expected scope:

• change the publish runner from windows-latest to ubuntu-24.04
• verify all publish steps still work on Linux
• update any scripts or workflow logic that accidentally depend on Windows-only behavior
• document the result

If a concrete blocker is found, record it explicitly in this issue and keep Windows only if the blocker is justified.

Areas To Validate

• branch and tag resolution logic in PowerShell
• annotated tag validation
• package version resolution from the release tag
• NuGet/login trusted publishing flow on Linux
• dotnet nuget push behavior against both publish targets
• GitHub Release creation/update via gh
• path handling and path separators in workflow scripts

Impact Scope

Likely impacted components:

• .github/workflows/publish.yml
• scripts/Validate-PublishWorkflow.ps1
• release workflow documentation
• DECISIONS.md if maintainer review concludes the runner-platform policy should be recorded

Non-Goals

• Changing tag-routing rules
• Changing release tag validation rules
• Changing feed routing semantics
• Combining publish with CI jobs

Validation / Tests

• Ensure workflow invariant tests reflect the intended runner.
• Validate the publish script logic under Linux-compatible PowerShell behavior.
• Confirm tagged package publish still works from the supported release branches.
• Confirm GitHub Release creation/update still works on Linux.
• Confirm no analyzer, build, or packaging regressions are introduced.

Acceptance Criteria

• Publish runs successfully on ubuntu-24.04, or
• the issue documents a concrete technical reason that Publish must remain on Windows.
• The chosen runner is justified in documentation or issue notes.
• Workflow validation is updated to match the accepted behavior.

[iwizsophy]

WSL (Ubuntu 24.04) で Linux publish flow の事前検証を実施しました。

Results:

• scripts/Validate-PublishWorkflow.ps1 passed under Linux pwsh
• dotnet restore DependencyContractAnalyzer.slnx passed
• dotnet build DependencyContractAnalyzer.slnx -c Release --no-restore passed
• dotnet test DependencyContractAnalyzer.slnx -c Release --no-build passed
• scripts/Invoke-PackWithSbom.ps1 ... -PackProperties 'RelaxVersionerCheckWorkingDirectoryStatus=false' passed in a clean clone
• the publish-step package enumeration using Get-ChildItem artifacts\*.nupkg also worked under Linux pwsh

Notes:

• A first pack attempt failed only because the local workspace already contained multiple historical .nupkg files in artifacts; that is not representative of GitHub Actions clean checkout behavior.
• I have not yet validated the GitHub Actions-specific pieces locally: NuGet/login@v1 trusted publishing with OIDC, and the final gh release create/edit path under Actions token semantics.

Current conclusion:

• I have not found a Linux-specific blocker in the repository-owned scripts or pack/build/test flow.
• The remaining risk is in GitHub Actions service integration rather than repository code paths.