fix: release workflow and immutable release tags for Packagist#55
Merged
Conversation
Fixes #54 where packagist complains the release tag has been modified after the release. To fix we need to completely change how we do releases and auto version bump. We now manually trigger the workflow, input the version tag, run the auto version bump and changelog update jobs, and then create the release and tag pragmatically after committing. - Refactor release pipeline to completely change how we do releases and auto version bump. Allowing the workflow to be triggered manually (instead of on-release) with inputs to set the release tag version and publish the release. - Introduced `tag_name`, `target_branch` with default as master, and `prerelease` boolean inputs. - Introduced `publish_only` and `release_sha` inputs to enable the skipping of a version and changelog updates and jump directly to publishing the release. - Fixed the release tag behaviour and removed the updating of tag commits. - Added a proper publish release job with the creation of immutable tags and releases. - Publish releases from resolved release commit SHA to keep tag/release contents aligned both on GitHub and Packagist. - Updated versioning validation and enforce semver release tags prefixed with a v. - Require both version.php and CHANGELOG.md updates for every release and validate them before creating a PR.
There was a problem hiding this comment.
Pull request overview
This PR refactors the release automation to avoid mutating already-published tags (addressing Packagist complaints about modified release tags) by moving to a manually triggered workflow that prepares a release commit/PR and then publishes an immutable tag and GitHub release from the resolved commit SHA.
Changes:
- Replaced the
on: releasetrigger with aworkflow_dispatchrelease flow that accepts tag/branch/prerelease inputs and supports apublish_onlymode. - Added workflow logic to bump
cli/version.php, updateCHANGELOG.md, open/auto-merge a release PR, and publish an immutable tag + GitHub release from the resolved release commit SHA. - Updated
.editorconfigto enforce spaces for YAML indentation.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| .github/workflows/release.yml | Refactors the release pipeline to prepare a release commit and publish immutable tags/releases aligned to a resolved commit SHA. |
| .editorconfig | Ensures YAML files use space indentation (supporting consistent workflow formatting). |
When using publish only mode, the release tag validation is skipped because it's a step in the skippable prepare-release job. But we still need the validation for publish only mode. Fixed by: - Moved the release tag validation into a separate required job (validate-release-tag) that always runs no matter the mode. - Refactored code to use the new validate-release-tag job outputs, and require it in the publish-release job.
- Added checks to ensure that existing tags are immutable and point to the expected release commit. - Implemented conditional steps to handle tag validation based on the `publish_only` input.
…ting - Changed all instances of the input `tag_name` to `release_tag`. - Changed the env variable name `TAG_NAME` to `RELEASE_TAG`.
Merged
yCodeTech
pushed a commit
that referenced
this pull request
Jul 5, 2026
docs: update changelog for PR #55 Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #54 where Packagist complains the release tag has been modified after the release. To fix we need to completely change how we do releases and auto version bump. We now manually trigger the workflow, input the version tag, run the auto version bump and changelog update jobs, and then create the release and tag pragmatically after committing.
Refactor release pipeline to completely change how we do releases and auto version bump. Allowing the workflow to be triggered manually (instead of on-release) with inputs to set the release tag version and publish the release.
Introduced
release_tag,target_branchwith default as master, andprereleaseboolean inputs.Introduced
publish_onlyandrelease_shainputs to enable the skipping of a version and changelog updates and jump directly to publishing the release.Fixed the release tag behaviour and removed the updating of tag commits.
Added a proper publish release job with the creation of immutable tags and releases.
Publish releases from resolved release commit SHA to keep tag/release contents aligned both on GitHub and Packagist.
Updated versioning validation and enforce semver release tags prefixed with a v.
Require both version.php and CHANGELOG.md updates for every release and validate them before creating a PR.