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.
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.
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.
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.
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.
v4+ uses the @actions/artifact v2 backend, which this self-hosted
Gitea instance rejects as unsupported since it identifies as GHES to
the action's GHES-detection check. checkout/setup-node don't have
this issue and stay on v7.
actions/checkout v4 -> v7, actions/setup-node v4 -> v7,
actions/upload-artifact v4 -> v7 across all workflows.
shivammathur/setup-php stays on the floating @v2 tag, which already
resolves to the latest 2.x release.
Ports the standalone due-date cron script into a proper Nextcloud 34
app with a personal-settings UI, per-user workflow configuration
(source/target stack, assigned-user and label filters, email
notification), a TimedJob background runner, and Gitea CI pipelines.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Patrick Niebeling
