ci: fix Release workflow failing on empty changelog pipelines

[sherwinski]

One Line Summary

Fix the `Release (v3)` and `Release (v2)` workflows that fail in the bump-version step when the changelog pipelines find no matching lines.

Motivation

Triggering Release (v3) for v3.9.0 (run 25944054673) failed in the `bump` job's "Generate changelog from git history" step. The visible failure was on `echo "$ENTRIES" > /tmp/changelog_entries.txt`, but the actual abort happens earlier inside the same script.

Two compounding causes:

1. The bump job's checkout has no tags or history. The `actions/checkout@v5` step in `release.yml` and `release-v2.yml` uses defaults `fetch-depth: 1` and `fetch-tags: false`. On the runner, `git describe --tags --abbrev=0` finds no tags (`LAST_TAG=""` → `RANGE="HEAD"`) and `git log HEAD --merges` returns nothing because squash-merged commits have a single parent and don't show under `--merges`.
2. `grep` exits 1 on empty input under `set -e -o pipefail`. Both `grep -v '^$'` and `grep -iv '^release|^chore(release)'` exit 1 when their input is empty; `pipefail` propagates that to the assignment, and `set -e` aborts the step before the `if [ -z "$ENTRIES" ]; then ENTRIES="- See release notes"; fi` fallbacks can run.

Verified by pulling the failed job log via `gh api repos/OneSignal/OneSignal-WordPress-Plugin/actions/jobs/76268196830/logs`.

Scope

• Affected: Both v3 and v2 release pipelines (`Release (v3)`, `Release (v2)`) and the shared local composite action that bumps versions and generates changelog entries.
• Not affected: Plugin runtime code, SVN publishing workflows (`publish-svn.yml`, `publish-svn-v2.yml`), reusable workflows in `OneSignal/sdk-shared` (`prep-release.yml` and `create-release.yml` already use `fetch-depth: 0` and worked correctly).

Changes

• `.github/workflows/release.yml` and `.github/workflows/release-v2.yml`: add `fetch-depth: 0` and `fetch-tags: true` to the `bump` job's `actions/checkout@v5` so the changelog script has the full history and tags it needs.
• `.github/actions/bump-version/action.yml`:
  • Append `|| true` to both `ENTRIES=$(... | grep ... | sed ...)` pipelines so empty pipelines fall through to the existing `- See release notes` fallback instead of killing the step.
  • Switch the final write to `printf '%s\n' "$ENTRIES"` for predictable multi-line output (`echo` would mangle a leading `-`).

Testing

Manual

• `yq eval '.' …` validates all three modified YAML files.
• Locally simulated the failing pipeline with empty input under `bash -e -o pipefail`:
  • Before: pipeline exits 1, step would fail.
  • After: `ENTRIES` ends up as `- See release notes` and `/tmp/changelog_entries.txt` is written cleanly.
• Locally ran the actual pipeline with `RANGE=v3.8.1..main` (the same range the workflow will compute once `fetch-depth: 0` is in place); the fallback path produces a real per-PR changelog from squash-merged commit subjects.

Recovery for the in-flight v3.9.0 release

Once this PR is merged:

1. Delete the existing `rel/3.9.0` branch so `prep-release.yml` recreates it cleanly:
   ```bash
   gh api -X DELETE repos/OneSignal/OneSignal-WordPress-Plugin/git/refs/heads/rel/3.9.0
   ```
2. Re-run Actions → Release (v3) → Run workflow → version: `3.9.0`.

Affected code checklist

• PHP plugin code (`v3/`)
• `v2/` legacy code
• JS / CSS assets
• Build / CI
• Tests
• Documentation (README, `readme.txt`, etc.)

Checklist

• Code follows existing style in the touched files
• No new lint or test errors introduced

[claude]

LGTM — small, well-scoped CI fix with clear root-cause analysis.

Extended reasoning...

Overview

This PR fixes the Release (v3) and Release (v2) workflows that were aborting in the bump-version step. Changes are limited to two workflow files and one composite action under .github/ — no plugin runtime code is touched.

Security risks

None. CI-only changes. The added fetch-depth: 0 / fetch-tags: true simply broaden the checkout to include history and tags (read-only). The || true and printf changes affect how an empty pipeline is handled and how a string is written to /tmp/changelog_entries.txt. No credentials, permissions, or external interactions are involved.

Level of scrutiny

Low. The diagnosis in the PR description matches well-known bash gotchas — grep exits 1 on no matches, and under set -e -o pipefail that kills the step before the existing if [ -z "$ENTRIES" ] fallback can run. Appending || true is the idiomatic remedy. Replacing echo with printf '%s\n' correctly handles values that start with a dash (e.g. - See release notes), which echo would have interpreted as a flag in some shells. The checkout fetch-depth: 0 / fetch-tags: true aligns this job with the sibling reusable workflows that already worked.

Other factors

The bug hunter found no issues. The PR description includes manual verification of both the empty-input and real-history pipelines, plus a YAML validation step. Recovery instructions for the in-flight v3.9.0 release are documented.

[fadi-george]

Merge?