ci: automate releases with release-plz

[JamBalaya56562]

Summary

Refactor the release pipeline using release-plz, per maintainer feedback on #747 (comment):

I also saw this pipeline issue. I would prefer to use release-plz action to refactor the release pipeline.

#747 originally also reworked the changelog.yaml workflow (which pushed to the protected main branch and always failed). Per the comment above, that PR was narrowed to the obvious cliff.toml owner fix (awslabs → aws), and this follow-up implements the release-plz refactor.

What this PR does

• Adds .github/workflows/release-plz.yml — a two-phase workflow: on push to main it opens/updates a "Release PR" that bumps Cargo.toml + CHANGELOG.md; merging that PR tags v<version>, publishes a GitHub Release (which triggers the existing release.yaml → Lambda layers, gamma→prod, ECR), and runs cargo publish.
• Adds release-plz.toml for release-plz configuration (reuses the existing cliff.toml).
• Removes .github/workflows/changelog.yaml (superseded).
• Re-enables crates.io publishing. The crate lambda_web_adapter is currently at 0.9.1 (Feb 2026) while the repo is at 1.0.1 — the manual process appears to have missed the 1.0.0 / 1.0.1 publishes. release-plz will resume from the next computed version.

---

⚠️ Maintainer actions required before/after merging

The workflow will not function end-to-end without the following one-time setup. None of these can be performed from the PR itself — they require maintainer / crates.io-owner access.

1. crates.io — configure Trusted Publishing for lambda_web_adapter

A crates.io owner of the crate must register this repo as a Trusted Publisher:

1. Open https://crates.io/crates/lambda_web_adapter/settings
2. Under Trusted Publishing, click Add and enter:
   • Repository owner: aws
   • Repository name: aws-lambda-web-adapter
   • Workflow filename: release-plz.yml
   • Environment: (leave blank — this workflow does not use a deployment environment)

If skipped or misconfigured, the first release-plz release run will fail with a 401 from crates.io.

2. GitHub repository secrets — GitHub App credentials

Install a GitHub App scoped to aws/aws-lambda-web-adapter and add its credentials as repository secrets:

• RELEASE_PLZ_APP_ID — App ID
• RELEASE_PLZ_APP_PRIVATE_KEY — Private key (PEM, including the BEGIN/END lines)

Required GitHub App repository permissions:

• Contents: Read & Write
• Pull requests: Read & Write
• Issues: Read & Write (release-plz posts comments on the Release PR)

A fine-grained PAT with the equivalent scopes would also work, but a GitHub App is preferred (no human-user attribution, auto-rotating credentials).

3. Repository setting — allow Actions to open PRs

Settings → Actions → General → enable:

• ✅ "Allow GitHub Actions to create and approve pull requests"

Without this, release-plz cannot open the Release PR and the workflow will fail.

---

Test plan

• Confirm the 3 maintainer setup items above are completed before merge.
• After merge, push a commit to main and confirm a Release PR is opened by the GitHub App bot.
• Verify the Release PR's Cargo.toml bump and CHANGELOG entry look correct.
• Merge the Release PR and confirm the tag, GitHub Release, and crates.io publish all complete.
• Confirm release.yaml fires on the published Release (Lambda layer build + ECR push succeed).

---

Design notes (why this design — click to expand)

Why a GitHub App token (not the default GITHUB_TOKEN)

The default GITHUB_TOKEN cannot trigger other workflows (GitHub's loop-prevention rule). For this repository specifically, that means a Release published with GITHUB_TOKEN would not fire release.yaml (on: release: types: [released]) — silently skipping the Lambda layer build, gamma/prod deploy, and public ECR Docker publish. The workflow therefore uses a GitHub App token via actions/create-github-app-token.

crates.io auth: OIDC trusted publishing (release-plz built-in)

Uses id-token: write permission only. release-plz performs the OIDC token exchange with crates.io internally, per the release-plz quickstart — so no rust-lang/crates-io-auth-action and no long-lived CARGO_REGISTRY_TOKEN secret are needed.

What happens after merge (operator overview)

1. On every push to main, the workflow opens or updates a single Release PR (no actual release yet).
2. When the Release PR is reviewed and merged, the workflow on the resulting push to main will:
   • Create the v<version> git tag
   • Publish a GitHub Release → triggers release.yaml (Lambda layers, gamma→prod, ECR)
   • Publish to crates.io via OIDC

🤖 Generated with Claude Code