GitHub repositories and automated releases

The update server reads GitHub releases. A repository can contain multiple packages:

plugins/<slug>/<slug>.php
themes/<slug>/style.css
bin/build.sh
.github/workflows/release.yml

Use the build scripts and release workflow in FluxWP as a reference.

Publish a version#

1. Increase the package’s Version: header and version constant, if present.
2. Add release notes under the version heading in the package’s CHANGELOG.md.
3. Submit the change through a branch and PR. After review and merge to main, Actions builds dist/<slug>.zip, creates a <slug>-v<version> release and attaches the ZIP.

With UPDATE_WEBHOOK_SECRET configured, the workflow refreshes the server cache. The update then appears in WordPress.

Rules#

A hyphenated version such as 1.3.0-beta.1 is a prerelease for beta-channel sites. A version decrease fails the release. Requires Plugins: declares dependencies installed by FluxWP Panel. Use .distignore in the package directory to exclude files; Git metadata, node_modules and tests are excluded by default.

Manual builds#

Use Actions → Package release → Run workflow for manual releases, optionally selecting one package. For a local ZIP, run bin/build.sh plugins/flx-example. New packages belong under plugins/<slug>/ or themes/<slug>/ and are discovered from releases when the repository is enabled on the server.

Keep tokens out of the repository. The GitHub token belongs in the update server panel; UPDATE_WEBHOOK_SECRET belongs in GitHub Actions secrets.