Auto-update the plugin from tagged Gitea releases #65

New Issue

2026-07-18T14:09:23Z

thatguygriff commented

2026-07-18 14:09:23 +00:00

Problem

Deploying the plugin currently means downloading a zip artifact from a Gitea Actions run on main and uploading it into wp-admin by hand. There is no versioned release history in the repo sidebar, and installed sites have no way to know an update exists.

Desired workflow

Tag vX.Y.Z in Gitea (or create a release in the UI) and that's the whole deploy:

The release appears in the repo sidebar with the built plugin zip attached as an asset.
Every WordPress site running the plugin sees the update on its normal update check and can install it with one click — or unattended, if the site enables auto-updates for the plugin.

Proposed implementation

Release side — a .gitea/workflows/release.yml triggered by v* tag pushes that verifies the tag matches the plugin Version: header, runs the test suite, builds the distributable zip (composer build), and attaches it to the release for that tag (creating the release if only a bare tag was pushed). Hyphenated versions (1.2.3-rc.1) are flagged pre-release.

Site side — declare Update URI: https://git.unsupervised.ca/Unsupervised/unsupervised-scheduler in the plugin header and answer core's update_plugins_{hostname} filter from a new Update\UpdateChecker class that:

fetches the latest published release from the Gitea API (/releases/latest, which excludes drafts and pre-releases),
caches the lookup in a transient so admin page loads don't hammer the API,
offers the release's zip asset as the update package when it is newer than USC_VERSION,
degrades silently to "no update" on any API failure or malformed response.

Core handles everything downstream: the Plugins-screen update notice, one-click updates, and opt-in auto-updates via WP-Cron.

## Problem Deploying the plugin currently means downloading a zip artifact from a Gitea Actions run on `main` and uploading it into wp-admin by hand. There is no versioned release history in the repo sidebar, and installed sites have no way to know an update exists. ## Desired workflow Tag `vX.Y.Z` in Gitea (or create a release in the UI) and that's the whole deploy: - The release appears in the repo sidebar with the built plugin zip attached as an asset. - Every WordPress site running the plugin sees the update on its normal update check and can install it with one click — or unattended, if the site enables auto-updates for the plugin. ## Proposed implementation **Release side** — a `.gitea/workflows/release.yml` triggered by `v*` tag pushes that verifies the tag matches the plugin `Version:` header, runs the test suite, builds the distributable zip (`composer build`), and attaches it to the release for that tag (creating the release if only a bare tag was pushed). Hyphenated versions (`1.2.3-rc.1`) are flagged pre-release. **Site side** — declare `Update URI: https://git.unsupervised.ca/Unsupervised/unsupervised-scheduler` in the plugin header and answer core's `update_plugins_{hostname}` filter from a new `Update\UpdateChecker` class that: - fetches the latest published release from the Gitea API (`/releases/latest`, which excludes drafts and pre-releases), - caches the lookup in a transient so admin page loads don't hammer the API, - offers the release's zip asset as the update package when it is newer than `USC_VERSION`, - degrades silently to "no update" on any API failure or malformed response. Core handles everything downstream: the Plugins-screen update notice, one-click updates, and opt-in auto-updates via WP-Cron.

thatguygriff referenced this issue from a commit

2026-07-18 14:09:56 +00:00

Serve plugin updates from tagged Gitea releases

thatguygriff referenced a pull request that will close this issue

2026-07-18 14:10:38 +00:00

Auto-update the plugin from tagged Gitea releases #66

thatguygriff closed this issue

2026-07-18 14:22:06 +00:00

Sign in to join this conversation.