6 Commits

Include renames

Author	SHA1	Message	Date
Patrick Niebeling	ef973af4b5	Drop PHP 8.2/8.3 from CI, test against 8.4/8.5 only	2026-08-25 13:14:02 +02:00
Patrick Niebeling	be6faa7b42	Allow PHP 8.5 ... occ upgrade refused to install the app on a PHP 8.5 instance: Exception: App "Array" cannot be installed because the following dependencies are not fulfilled: PHP wird in einer frueheren Version als 8.4 benoetigt. That is the max-version="8.4" in appinfo/info.xml, not a real incompatibility -- nothing in this app is bounded above by 8.4. Raise it to 8.5 and add 8.5 to the php-lint matrix, so CI covers the version the server actually runs instead of stopping one below it.	2026-08-13 23:15:43 +02:00
Patrick Niebeling	8f3e3e694a	Gate the release on the lint and test jobs ... The four workflows all triggered on the same push to main and ran fully independently, so build-main.yml published a latest-main release even when PHPUnit or the linters were red. `needs:` only works between jobs of one workflow, so the checks move into build-main.yml and the package job now depends on them. Two gaps close along the way: the check workflows only ran on main pushes and pull requests, so a v* tag was published entirely unverified, and `npm run build` only ran on main, so no pull request ever exercised the frontend build -- the workflow now runs on pull_request too, with the publish step skipped so the job acts as a build check. Build and publish deliberately stay in a single job; moving the tarball between jobs would require actions/upload-artifact (unusable on this Gitea, see CLAUDE.md) or actions/cache.	2026-08-13 14:17:00 +02:00
Patrick Niebeling	9a8e4e47f0	Use the built-in GITEA_TOKEN instead of a hand-made RELEASE_TOKEN secret ... Gitea injects a token into every Actions job as secrets.GITEA_TOKEN, so the manually created PAT was never necessary. Declare permissions: contents: write on the job, which Gitea maps to Code: write (deleting the latest-main tag) and Releases: write (creating the release, uploading the asset) - the full set the publish step needs. Removes a secret that had to be created by hand, could expire, and was a single point of failure the workflow had no fallback for.	2026-08-13 13:54:38 +02:00
Patrick Niebeling	e06e382147	Merge release workflow into the main build workflow ... build-release.yml and build-main.yml ran identical steps (checkout, node, npm install, npm run build, make appstore) and differed only in where the package landed. Fold the v* tag trigger into build-main.yml and branch on gitea.ref in the publishing step: main keeps the rolling latest-main pre-release, tags get a normal release on the tag that was just pushed. Tag deletion is now guarded - only latest-main is recreated, since deleting a version tag would destroy the ref that triggered the run. A stale release is still removed in both cases so moved tags republish cleanly. Side effects: version builds are published as durable release assets with a stable URL instead of expiring workflow artifacts, which drops the last actions/upload-artifact usage and with it the @v3 pin forced by the GHES restriction; and the setup-php step goes away, since make appstore only shells out to mkdir/tar/rm.	2026-08-13 13:46:34 +02:00
Patrick Niebeling	c5bf6f8f0d	Add rolling main-branch build workflow for manual server deploys ... Publishes the appstore package as a Gitea release asset on every push to main, so a deployable build can be grabbed without cutting a version tag first.	2026-08-13 12:52:29 +02:00