fix: Add release-please for automated releases

[gjtorikian]

Summary

• Add release-please to automate versioning, changelog generation, and GitHub releases
• Add a PR title linter (lint-pr-title.yml) to enforce Conventional Commits, which release-please uses to determine version bumps
• Update release.yml to use NuGet trusted publishing (OIDC) instead of a long-lived API key

Changes

• New: .github/workflows/release-please.yml — runs on push to main, creates release PRs automatically
• New: .github/workflows/lint-pr-title.yml — validates PR titles follow conventional commit format
• New: release-please-config.json — configures release-please with simple release type
• New: .release-please-manifest.json — tracks current version (2.10.1)
• Modified: src/WorkOS.net/WorkOS.net.csproj — added <!--x-release-please-version --> annotations to <VersionPrefix> and <Version> so release-please can bump them (same pattern used by open-feature/dotnet-sdk)
• Modified: .github/workflows/release.yml — switched from DOTNET_NUGET_API_KEY secret to NuGet trusted publishing via NuGet/login@v1; trigger changed from released to published

How it works

1. Conventional commits (feat:, fix:, chore:, etc.) are enforced on PR titles via amannn/action-semantic-pull-request
2. PRs are squash-merged, so the PR title becomes the commit message on main
3. release-please-action opens (or updates) a release PR with a version bump and CHANGELOG.md entry
4. Merging the release PR creates a GitHub Release
5. The release.yml workflow triggers on the release: [published] event and publishes to NuGet using OIDC trusted publishing

Mirrors workos/workos-ruby#435

Test plan

• Configure NuGet trusted publishing policy on nuget.org (workflow file: release.yml, repo owner: workos, repo: workos-dotnet)
• Verify release-please action runs on push to main
• Verify release PR is created with correct version bump and changelog
• Verify NuGet publish job triggers when release PR is merged

[greptile-apps]

Greptile Summary

This PR introduces automated release tooling for workos-dotnet: release-please handles version bumping, changelog generation, and GitHub Releases; a PR title linter enforces Conventional Commits; and NuGet publishing is migrated from a long-lived API key to OIDC trusted publishing.

Key changes:

• release-please.yml — runs on every push to main, creates/updates release PRs via a GitHub App token; both actions are SHA-pinned
• lint-pr-title.yml — validates PR titles against Conventional Commits using pull_request_target with minimal permissions
• release.yml — switches from DOTNET_NUGET_API_KEY secret to OIDC-based NuGet/login; trigger changed from released → published; API key correctly passed via env: variable
• release-please-config.json / .release-please-manifest.json — configures the simple release type seeded at 2.10.1
• WorkOS.net.csproj — annotated with <!--x-release-please-version --> on both <VersionPrefix> and <Version> so release-please can bump them automatically

Issues found:

• release-please.yml is missing a concurrency group — rapid successive merges to main can trigger parallel runs that race to update the same release PR
• release.yml's workflow_dispatch trigger has no ref input, so a manual trigger always publishes from HEAD of the default branch, which may not match any release tag

Confidence Score: 4/5

• Safe to merge with minor operational improvements recommended before the first automated release is triggered.
• The core changes are well-structured: actions are SHA-pinned, OIDC trusted publishing is correctly configured, permissions are appropriately scoped, and the release-please config matches the csproj annotation pattern. The two flagged issues (missing concurrency group and unguarded workflow_dispatch) are operational concerns rather than blockers, and --skip-duplicate prevents duplicate NuGet publishes in the worst case.
• .github/workflows/release-please.yml (missing concurrency group) and .github/workflows/release.yml (workflow_dispatch ref handling)

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub (main branch)
    participant RPW as release-please.yml
    participant RP as release-please-action
    participant RPRR as Release PR
    participant RW as release.yml
    participant NuGetLogin as NuGet/login (OIDC)
    participant NuGet as nuget.org

    Dev->>GH: Merge conventional-commit PR (squash)
    GH->>RPW: push event (branch: main)
    RPW->>RP: Run release-please-action
    RP->>RPRR: Create/update Release PR (bump version + CHANGELOG)
    Note over RPRR: PR updates .release-please-manifest.json,<br/>WorkOS.net.csproj (VersionPrefix + Version),<br/>CHANGELOG.md

    Dev->>GH: Merge Release PR
    GH->>RP: push event (branch: main)
    RP->>GH: Create GitHub Release + tag (vX.Y.Z)

    GH->>RW: release: [published] event
    RW->>RW: dotnet pack (Build step)
    RW->>NuGetLogin: Exchange OIDC token for temporary API key
    NuGetLogin-->>RW: NUGET_API_KEY (short-lived)
    RW->>NuGet: dotnet nuget push *.nupkg --api-key $NUGET_API_KEY
    NuGet-->>RW: Published (or skipped if duplicate)

Loading

_{Last reviewed commit: 6705a71}

[greptile-apps]

_{6 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[gjtorikian]

@greptile review

[gjtorikian]

@greptile review

[greptile-apps]

Missing concurrency group — parallel runs can corrupt the release PR

Without a concurrency group, rapid successive pushes to main (e.g., two PRs merged in quick succession) will trigger parallel release-please runs. Concurrent runs can race to update the same release PR, potentially creating duplicate PRs or leaving the manifest in an inconsistent state.

The release-please documentation recommends adding a concurrency group to serialize runs:

Suggested change

	name: Release Please
	on:
	push:
	branches:
	- main
	permissions:
	contents: write
	pull-requests: write
	name: Release Please
	on:
	push:
	branches:
	- main
	concurrency:
	group: release-please
	cancel-in-progress: false
	permissions:
	contents: write
	pull-requests: write

Using cancel-in-progress: false ensures the latest run completes rather than being cancelled, so no push to main is silently skipped.

[greptile-apps]

workflow_dispatch publishes from current branch state, not a specific release tag

When this workflow is triggered manually via workflow_dispatch, it checks out the default branch at HEAD — whatever version happens to be in WorkOS.net.csproj at that moment. This is different from the release: [published] path where GITHUB_SHA is pinned to the release tag commit.

This means a manual trigger at the wrong time (e.g., after release-please has bumped the version in a release PR that hasn't been merged yet) could publish a version that doesn't correspond to any tag or release, making it hard to trace what source code was published.

Consider adding an explicit ref input to gate which commit gets published:

workflow_dispatch:
  inputs:
    ref:
      description: 'Git ref (tag or SHA) to publish'
      required: true
      default: 'main'

Then use ref: ${{ inputs.ref }} in the actions/checkout step.