Add GitHub Actions workflow to build self-contained release archives - #999
Conversation
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
|
Will rebase after PR #1001 is merged, and CI should pass nicely. |
|
Is this written to effectively require PHP 8.2 and sqlite? |
No, it'd be database independent. You'd need to configure config.local.php or whatever as usual. It's just to save someone the hassle (?) of running composer to install libraries. |
0ea537e to
412dd3a
Compare
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
Adds an update-check page that queries the GitHub Releases API to show available updates with changelogs, and allows global admins to download and apply updates directly from the web UI. Depends on postfixadmin#999 for self-contained release tarballs.
412dd3a to
4078689
Compare
No I get that. But in the release.yml file in the PR, there is "extensions: sqlite3, gd" (line 21) in the release.yml file. If the workflow is only to have composer roll a vendor dir for the release asset, I'm puzzled why the build env needs those extensions installed? |
|
Good catch - removed the unnecessary extensions earlier from the workflow actually. They're only "suggest" in composer.json and "composer install --no-dev" doesn't need them. |
The extensions in the github action ....
|
…ostfixadmin#973) Automatically builds a .tar.gz with vendor/ included when a release is published, so admins can install without needing composer.
4078689 to
922a473
Compare
|
Restored the extensions and added a comment explaining their purpose. Thanks for clarifying David! |
|
@DavidGoodwin I've added a comment about that in the file, as it will help in the future. (documentation for the win) :) |
@knofte The comment you added in the github actions doesn't really add much. The php extensions, that are listed within the github actions file, are there so the github actions initiated unit tests can run (SQLite was the easiest database to setup/use). Yes, obviously this means there's a chance there is a bug in the MySQL or PostgreSQL support, but when I added the unit test/github action build, I thought getting something tested was better than nothing. If I had time/motivation, I might instead have a docker-compose.yml file with PostgreSQL and MySQL services, and test against them "properly". FWIW, It'd be easier to review your changes if you'd stop squashing and force pushing everything into one commit. Then (with the above comment, for example) anyone reviewing it can just look at the specific change you'd made. |
There was a problem hiding this comment.
Pull request overview
Adds a GitHub Actions workflow to build and upload a self-contained PostfixAdmin release .tar.gz (including vendor/) whenever a GitHub Release is published, enabling installations without needing Composer on the target server.
Changes:
- New
release: publishedworkflow that installs production dependencies on PHP 8.2. - Creates a release tarball with exclusions for development-only files/directories.
- Uploads the generated archive to the GitHub Release as an asset via
gh release upload.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Good point on the squashing, will keep separate commits going forward, sorry about that. On the docker-compose/testing idea, happy to put together a PR for that. I'd suggest extending the existing php.yml with MySQL and PostgreSQL service containers rather than a separate workflow, since the test infrastructure is already there. I'll add phpstan too - only 5 errors at level 0 on the current codebase, so it's a clean starting point to build from. |
|
Also put together PR #1005 which adds phpstan (level 0, 5 existing errors fixed) and MySQL + PostgreSQL test jobs to CI. The test bootstrap already had all three database backends wired up, just needed the CI service containers. |
Isn't that Action just to package the release tarball? Unit testing should have already been done at that point. |
Yes, good point. The extensions aren't needed in this context / yml file. |
|
(yes, I see you've asked me to review it; visually it look sfine. I was wondering how to test it without doing it under postfixadmin/postfixadmin .... ) |
|
Updated the archive name to include the PHP version, e.g. Single tarball built on PHP 8.2 (minimum supported). As you say, if someone hits issues on a newer PHP they can run |
|
Tested the workflow on our fork - works as expected: https://github.com/knofte/postfixadmin/releases/tag/v4.0.2-test
|
|
And the build-action here - https://github.com/knofte/postfixadmin/actions/runs/23854475761 :) |
Summary
Closes #973
Adds a GitHub Actions workflow that automatically builds a self-contained
.tar.gzrelease archive (withvendor/included) whenever a release is published. This means admins can download and install PostfixAdmin without needingcomposeron the server.How it works
release: publishedeventscomposer install --no-dev --optimize-autoloader.tar.gz, excluding development files (.git,.github,tests, etc.)gh release uploadWhy PHP 8.2?
Building on the minimum supported PHP version ensures the resolved dependencies work on all supported versions (8.2, 8.3, 8.4, 8.5+). Composer resolves packages compatible with the running PHP version, and newer PHP versions are backwards compatible.
Test plan
.tar.gzand verify it containsvendor/with all dependenciescomposer install