Tag and release the site when a deploy publishes a new version

[sdh100shaun]

Why

The site has published to Pages on every push to main and daily since the Astro rebuild, but nothing recorded what went out when — gh release list is empty, the only tag is backup/pre-split-chore-dependabot-batch, and package.json has sat at 2.0.0. There's no version to point at, no changelog, and nothing to roll back to by name.

What this does

deploy.yml gains a third job, release, that runs once the Pages deploy succeeds:

• package.json is the source of truth. It creates tag v<version> and a Release with generated notes, but only when that version has no release yet — so a release happens exactly when someone bumps the version in a PR, and every other push is a no-op.
• Pushes to main only. The daily 06:00 cron rebuild and workflow_dispatch deploy exactly as before but skip the job, since they republish identical content. Releasing on the cron would mean ~365 releases a year for no change.

It checks for the release rather than the tag, which keeps re-runs idempotent and self-heals a tag left behind without one. gh release create creates the tag at --target itself, so there's no separate git tag && git push to keep in sync.

Supporting changes

File	Change
.github/release.yml	New. Groups generated notes: Listings (event-suggestion) → Dependencies (dependencies) → Changes (*, catch-all last), so meetup listings don't read the same as a feature change.
process-suggestion.yml	Adds labels: event-suggestion to the create-pull-request step. The label was only ever applied to the issue, so the Listings category would have matched nothing.
ci.yml	fetch-depth: 0 on the build checkout, plus a non-blocking ::notice:: when a PR touches files outside src/content/meetups/** without a version bump.
package.json	2.0.0 → 2.1.0.
CLAUDE.md	Documents the flow in Deployment and CI.

Verified locally

• All four YAML files parse; deploy.yml exposes build, deploy, release with the expected needs / if / permissions, and the suggestion step's labels reads back as event-suggestion.
• The reminder script run against real repo state: quiet with the bump present, and fires ::notice:: when the version is simulated as unchanged. A touched meetup file is correctly filtered out of the "code changes" list.
• gh release view v2.1.0 exits 1, so the first deploy after merge will create the release rather than skip.
• npm run build passes.

Two things to know before merging

The first release will have long notes. There's no prior release for --generate-notes to bound against, so v2.1.0 picks up the whole history. One-off; later releases are scoped to the previous tag.

The version bump is manual, and the CI notice is the only nudge. That's deliberate — content PRs are the common case, shouldn't bump anything, and shouldn't show a contributor a red check. If it proves too easy to ignore, the follow-up is making it a required check, not auto-bumping.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D46yvMekBML3gD9k4xSeZ3

[Copilot]

Pull request overview

This PR adds an automated release/tagging step to the GitHub Pages deploy workflow so that production deployments can be referenced by version (v<package.json version>) and get generated release notes.

Changes:

• Add a release job to .github/workflows/deploy.yml that creates a GitHub Release (and tag) on pushes to main, but skips scheduled/dispatch deploys.
• Add .github/release.yml to group generated release notes by PR labels (Listings/Dependencies/Changes), and ensure suggestion PRs get the event-suggestion label.
• Add a CI ::notice:: reminder when a PR changes non-listing files without bumping package.json version; bump version to 2.1.0 and document the flow in CLAUDE.md.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
package.json	Bumps site version to 2.1.0 as the release trigger.
CLAUDE.md	Documents the new deploy/release workflow and version-bump contract.
.github/workflows/process-suggestion.yml	Labels auto-opened suggestion PRs as event-suggestion to support release note grouping.
.github/workflows/deploy.yml	Adds a post-deploy release job to create a release/tag based on package.json version (push-only).
.github/workflows/ci.yml	Fetches full git history and adds a non-blocking version-bump reminder notice for code-changing PRs.
.github/release.yml	Configures release note categories for --generate-notes based on labels.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

CLAUDE.md:141

• In this new deployment/release documentation, process-suggestion.yml and ci.yml are referenced without their .github/workflows/ path, while surrounding bullets use full workflow paths. Using the full paths here too avoids ambiguity and keeps the section consistent.

  `process-suggestion.yml` labels the PR it opens and not just the issue.
  `ci.yml`'s `build` job prints a non-blocking `::notice::` when a PR changes

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.