Repository navigation
Build the phar in the release workflow - #67
Merged
Merged
Conversation
The release workflow uploaded the committed builds/ohdear as-is, so a release only contained new code if someone remembered to rebuild and commit the phar first. v5.3.0 needed a follow-up rebuild, and v5.4.0 shipped the 5.3.0 binary. Add a build job that compiles the phar from the tagged commit with the tag as its version, checks that --version matches, and hands it to both the GitHub release and Docker jobs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* origin/main: Rebuild phar for 5.4.1
Contributor
|
Nice, thanks! |
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.
Summary
The Release workflow uploads the committed
builds/ohdearas-is, and the Docker image copies the same file. A release only gets new code if someone rebuilds and commits the phar before tagging. This has gone wrong twice:This PR adds a
buildjob that runs on the tagged commit:builds/ohdeardoesn't report the tag's version. Composer installs run that file, so it still has to be rebuilt and committed before tagging.composer.lockon PHP 8.4php ohdear app:build ohdear --build-version=<tag without v>ohdear --versiondoesn't report the tag's versionphar-releaseanddocker-releasenow depend onbuildand use that artifact instead of the committed file. The Docker job restores the executable bit, because artifacts don't keep file modes and the image runs/ohdeardirectly.The workflow now defaults to read-only permissions, with
contents: writeonly onphar-release. Tags with a-(likev5.5.0-rc.1) publish as prereleases, and the release and artifact actions are on their current major versions.Testing
GITHUB_REF_NAME=v9.9.9. The phar reportedOh Dear 9.9.9and the check passed. A mismatched tag makes the check fail as intended.Notes
builds/ohdearis still committed. Once this has shipped a release, we could remove it and stop rebuilding it by hand, but I've left that for a separate change.v5.4.1works with or without this PR. With this PR, the phar is rebuilt from the tag either way.