Skip to content

ci(release): modernize release.sh + add tag-triggered GitHub Release workflow#83

Merged
kennethphough merged 1 commit into
masterfrom
chore/modernize-release-pipeline
May 22, 2026
Merged

ci(release): modernize release.sh + add tag-triggered GitHub Release workflow#83
kennethphough merged 1 commit into
masterfrom
chore/modernize-release-pipeline

Conversation

@kennethphough

Copy link
Copy Markdown
Member

Summary

Tier 1 release-pipeline modernization for kyte-php. Same shape as the kyte-api-js work, scoped to kyte-php's composer-only distribution (no CDN deploy step needed).

What's in here

release.sh — fix + harden

The old release.sh was silently broken since v4.3.2. It tried to read src/Core/Version.php for hardcoded MAJOR/MINOR/PATCH constants that were removed in v4.3.2 when Version.php was rewritten to read from Composer's runtime data. Every release after v4.3.2 — including v4.4.0 yesterday — bypassed it and used git tag directly.

Rewrite drops the dead Version.php check and adds pre-flight gates that match the kyte-api-js script:

  • CHANGELOG.md top matches the version arg
  • Working tree clean
  • Current branch is master
  • Local master in sync with origin
  • Tag doesn't already exist (locally or upstream)

.github/workflows/release.yml — new

Tag push (v*) triggers GitHub Actions to:

  1. Extract version from tag ref
  2. Verify a ## <version> header exists in CHANGELOG.md (refuse to publish empty release notes)
  3. Extract the matching section as release notes
  4. Create GitHub Release via softprops/action-gh-release@v2

No S3 / CDN upload — Packagist auto-detects new tags from GitHub within minutes. This workflow is much smaller than kyte-api-js's deploy.yml for that reason.

Includes FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true belt-and-suspenders for the June 2 force-migration.

What's NOT in here

  • release-please for kyte-php. Filed as Tempo card. kyte-php's release cadence is slow enough that manual CHANGELOG management remains acceptable, and the no-version-field-in-composer.json quirk makes release-please's php release-type integration messier than for kyte-api-js. Worth doing eventually if cadence picks up.

New release flow after merge

# 1. Land work on master with CHANGELOG entry
# 2. From master, clean tree, in sync with origin:
./release.sh 4.4.1

# Pre-flight runs → tag is pushed → release.yml fires
# → GitHub Release created from CHANGELOG section
# → Packagist picks up the tag
# → customers composer update to pull

Test plan

  • CI green on this PR (PHPStan + tests on PHP 8.2/8.3)
  • After merge: next release (v4.4.1 / v4.5.0 / whenever) uses the new flow and creates a GitHub Release automatically

🤖 Generated with Claude Code

…workflow

Tier 1 release-pipeline modernization for kyte-php (mirrors what we
did for kyte-api-js, scoped to kyte-php's composer-only distribution).

Two changes:

1) release.sh — fix + harden

   The old script tried to read src/Core/Version.php for hardcoded
   MAJOR/MINOR/PATCH constants. Those were removed in v4.3.2 when
   Version.php was rewritten to read from Composer's runtime data
   (Composer\InstalledVersions::getPrettyVersion). The script has
   been silently broken since then — every release after v4.3.2,
   including v4.4.0 just shipped, bypassed it and used git tag
   directly. This rewrite drops the dead Version.php check and adds
   pre-flight gates:

     - CHANGELOG.md top matches the version arg (kept from original)
     - Working tree clean (would otherwise tag unintended state)
     - Current branch is master (releases off master only)
     - Local master in sync with origin (no stale tags)
     - Tag doesn't already exist locally OR upstream

   set -e added so any failed git command aborts rather than
   continuing with a half-baked release.

2) .github/workflows/release.yml — new

   Tag push (v*) triggers an Actions job that:
     - Extracts the version from the tag ref
     - Verifies a matching `## <version>` header exists in CHANGELOG.md
       (fails loud — refuses to publish an empty release)
     - Extracts the section between that header and the next `## ` as
       release notes
     - Creates a GitHub Release with the notes

   No S3 / CDN upload — kyte-php is composer-distributed, Packagist
   auto-detects new tags from GitHub within minutes of the release.
   That's why this workflow is materially smaller than kyte-api-js's
   deploy.yml.

   Belt-and-suspenders: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true
   env var so action-gh-release runs on Node 24 ahead of GitHub's
   2026-06-02 force-migration (same fix we applied to kyte-api-js).

After this lands, the v4.4.1 / v4.5.0 / etc. release flow becomes:
  1. Land work on master with a CHANGELOG entry
  2. ./release.sh X.Y.Z (pre-flight + tag + push)
  3. GitHub Release auto-created from CHANGELOG section
  4. Packagist picks up the tag, customers composer update to pull

release-please for kyte-php is deferred (filed as Tempo card —
release cadence is slow enough that manual CHANGELOG management
remains acceptable, and the no-version-field-in-composer.json
quirk makes release-please integration messier than for kyte-api-js).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@kennethphough
kennethphough merged commit aa00a66 into master May 22, 2026
4 checks passed
@kennethphough
kennethphough deleted the chore/modernize-release-pipeline branch May 22, 2026 11:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant