Test against the newest WordPress and WooCommerce, and ship updates
Three things this repository could not do: prove the plugin still works on a
WordPress or WooCommerce released after it, get a fix onto a shop without
someone uploading a zip, and do either of those for the next plugin without
starting over.
ci/ is the test harness. ci/site-test.sh builds a throwaway WordPress +
WooCommerce in containers at any versions you name — including `nightly` and
`beta` — installs exactly the files the release zip will contain, and runs
tests/smoke.php inside it with wp eval-file. Real cart, real coupons, real
WC_Shipping_Rate objects: a mocked cart keeps passing after WooCommerce has
changed underneath it, which is the one failure worth catching here. WP_DEBUG
is on and any notice logged from this plugin's directory fails the build,
because that is the shape an upgrade actually breaks in — nothing fails, a
notice appears, and two releases later it is a fatal.
compat.yml runs that weekly against today's releases, the next WordPress and
the next WooCommerce, the oldest PHP the header promises and the newest PHP.
When it is green it opens a PR bumping "Tested up to" and "WC tested up to" —
only when green, because WooCommerce shows that second value to the shop owner
as an untested-plugin banner, and that banner is what they read before deciding
whether to press update.
includes/class-updater.php is the distribution half. It hooks
update_plugins_{hostname} for the host in the new "Update URI" header and reads
the Gitea release API, so WordPress handles the notice, the download, the
"Enable auto-updates" link and wp plugin update with no further code. Update
URI earns its place twice: since 5.8 a plugin that declares one is never asked
about on wordpress.org, so a .org plugin sharing this slug cannot be pushed
onto a shop running this one. The check sends nothing about the site and
overrides WordPress's default user agent, which carries the site's own URL.
release.yml tags, tests, builds, publishes — then reads the feed back with no
credentials. A private repository and a release with no zip attached both leave
a page that looks perfect to anyone logged in and an update no shop is ever
offered.
Measured before committing, all green: WP 7.1 + WC 11.1 on PHP 8.3 and 7.4,
WP 7.2-alpha on 8.3, and the beta cell falling back to stable on 8.4. No
deprecations from this plugin on any of them.
Three guards are there because the bug they catch is invisible without them:
the annotated tag is re-fetched before its message is read (checkout turns it
into a lightweight tag pointing at the merge commit), the two workflow roots
are kept in sync (.gitea/workflows hides .github/workflows entirely), and every
file the code loads must be in the release zip — which caught class-updater.php
being referenced and uncommitted while every local test passed.
docs/REUSE.md is the port to the next plugin: copy ci/, rewrite five lines.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
kristianwind
co-authored by
Claude Opus 5
Claude Opus 5
parent
e4a40e53a0
commit
eca2851d35
@@ -0,0 +1,25 @@
|
||||
# Why this directory exists, and the trap it carries
|
||||
|
||||
Gitea uses `.gitea/workflows` **if it exists**, and falls back to
|
||||
`.github/workflows` only when it does not. It never merges them.
|
||||
|
||||
So adding one Gitea-only workflow here silently switches off CI — and therefore
|
||||
auto-merge — for the whole repository on Gitea. There is no error and no run to
|
||||
click on. It looks exactly like a runner that has not picked the job up, so you
|
||||
wait, and waiting never fixes it.
|
||||
|
||||
**Every workflow that must run on Gitea has to be in this directory.**
|
||||
`ci.yml` and `compat.yml` are kept byte-identical in both roots, and
|
||||
`ci/workflows-in-sync.sh` fails if the two copies drift apart or if a workflow
|
||||
appears in only one of them without a stated reason.
|
||||
|
||||
`release.yml` is the deliberate exception: a release workflow publishes to
|
||||
whichever forge runs it, and the two copies publish to different places. The
|
||||
Gitea one is the one that matters — that is where the update feed shops read
|
||||
lives.
|
||||
|
||||
Two further rules learned the hard way:
|
||||
|
||||
- **No `concurrency:` block in a Gitea workflow.** It produces no run at all —
|
||||
not a failed one, not a cancelled one. Same shape of trap, same symptom.
|
||||
- If a Gitea workflow produces no run, **suspect the file, not the runner**.
|
||||
@@ -0,0 +1,58 @@
|
||||
name: CI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
pull_request:
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
# No `concurrency:` block here, and that is not an oversight. Measured on Gitea
|
||||
# 1.27.2, adding one produces no run at all — not a failed run, not a cancelled
|
||||
# one: nothing to click on, which looks exactly like a runner that has not
|
||||
# picked the job up, so you wait, and waiting never fixes it.
|
||||
#
|
||||
# This file is kept byte-identical in .github/workflows and .gitea/workflows.
|
||||
# ci/workflows-in-sync.sh fails if the two drift apart, because a workflow that
|
||||
# lives only in .github/ does not run on Gitea at all.
|
||||
|
||||
jobs:
|
||||
static:
|
||||
name: Static checks
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Workflows in sync
|
||||
run: ci/workflows-in-sync.sh
|
||||
|
||||
- name: Lint, hygiene, versions and compatibility headers
|
||||
run: ci/static.sh
|
||||
|
||||
- name: The release zip is buildable and complete
|
||||
run: ci/build-zip.sh
|
||||
|
||||
site:
|
||||
name: WordPress ${{ matrix.wp }} + WooCommerce ${{ matrix.wc }} on PHP ${{ matrix.php }}
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
# One cell per push: what a shop that keeps up to date is running today.
|
||||
# The wider matrix — the oldest PHP the header promises, the next
|
||||
# WordPress, the next WooCommerce — runs weekly in compat.yml, so a single
|
||||
# self-hosted runner is not asked to do all of it on every commit.
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
include:
|
||||
- { wp: latest, wc: latest, php: '8.3' }
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Install into a throwaway shop and run the tests
|
||||
env:
|
||||
WP_VERSION: ${{ matrix.wp }}
|
||||
WC_VERSION: ${{ matrix.wc }}
|
||||
PHP_VERSION: ${{ matrix.php }}
|
||||
run: ci/site-test.sh
|
||||
@@ -0,0 +1,89 @@
|
||||
name: Compatibility
|
||||
|
||||
# The question this answers: *will the shop still work after I press update?*
|
||||
#
|
||||
# It runs on a schedule rather than on a commit, because the thing that breaks
|
||||
# a finished plugin is not a new commit — it is a new WordPress or a new
|
||||
# WooCommerce, released on somebody else's timetable. A weekly run turns that
|
||||
# into a red build here, days before it turns into a broken checkout there.
|
||||
#
|
||||
# `nightly` and `beta` are the early warning: they are what the next release
|
||||
# will be. When one of those two cells goes red and the others stay green, the
|
||||
# plugin has a few weeks to be fixed rather than a few hours.
|
||||
|
||||
on:
|
||||
schedule:
|
||||
# Monday morning, so a failure has a whole week in front of it.
|
||||
- cron: '0 6 * * 1'
|
||||
workflow_dispatch:
|
||||
# Also whenever the tooling itself changes, because a compatibility run that
|
||||
# silently stopped testing anything is worse than no run at all.
|
||||
pull_request:
|
||||
paths:
|
||||
- 'ci/**'
|
||||
- 'tests/**'
|
||||
- '.github/workflows/compat.yml'
|
||||
- '.gitea/workflows/compat.yml'
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: write
|
||||
|
||||
# No `concurrency:` block — see the note in ci.yml. Kept byte-identical in
|
||||
# .github/workflows and .gitea/workflows; ci/workflows-in-sync.sh enforces it.
|
||||
|
||||
jobs:
|
||||
matrix:
|
||||
name: WP ${{ matrix.wp }} / WC ${{ matrix.wc }} / PHP ${{ matrix.php }}
|
||||
# The schedule fires on both forges, and the second run would be the same
|
||||
# work again on a single self-hosted runner for no extra information.
|
||||
# GitHub's runners take the scheduled load; Gitea keeps workflow_dispatch,
|
||||
# so the run is still one click away there.
|
||||
if: github.event_name != 'schedule' || github.server_url == 'https://github.com'
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
include:
|
||||
# Today's shop.
|
||||
- { wp: latest, wc: latest, php: '8.3' }
|
||||
# The next WordPress, before it ships.
|
||||
- { wp: nightly, wc: latest, php: '8.3' }
|
||||
# The next WooCommerce, before it ships. Falls back to the stable
|
||||
# release when there is no open beta, so the cell is never skipped.
|
||||
- { wp: latest, wc: beta, php: '8.3' }
|
||||
# The floor the plugin header promises. A shop on an old host is
|
||||
# exactly the shop that will not notice a fatal quickly.
|
||||
- { wp: latest, wc: latest, php: '7.4' }
|
||||
# And the newest PHP, which is where deprecations show up first.
|
||||
- { wp: latest, wc: latest, php: '8.4' }
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Install into a throwaway shop and run the tests
|
||||
env:
|
||||
WP_VERSION: ${{ matrix.wp }}
|
||||
WC_VERSION: ${{ matrix.wc }}
|
||||
PHP_VERSION: ${{ matrix.php }}
|
||||
run: ci/site-test.sh
|
||||
|
||||
headers:
|
||||
name: Keep the compatibility headers honest
|
||||
# Only after the current releases have actually been tested. Bumping
|
||||
# "Tested up to" on a red build would be writing a claim we have just
|
||||
# watched fail.
|
||||
needs: matrix
|
||||
# The PR is opened through the GitHub API, and the scheduled run that
|
||||
# produces it is the GitHub one.
|
||||
if: github.server_url == 'https://github.com' && github.event_name == 'schedule'
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Bump the headers and open a PR if they are behind
|
||||
env:
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
run: ci/bump-tested-up-to.sh
|
||||
@@ -0,0 +1,76 @@
|
||||
name: Release
|
||||
|
||||
# Builds the plugin zip, proves it installs and works, and publishes it here.
|
||||
#
|
||||
# This copy is the one that matters: Gitea is where the update feed lives, so
|
||||
# this is the run that decides whether shops are offered the new version. The
|
||||
# .github copy does the same work and publishes to GitHub — deliberately not
|
||||
# byte-identical, and ci/workflows-in-sync.sh knows that.
|
||||
#
|
||||
# Nothing is published before the tests have passed against the current
|
||||
# WordPress and WooCommerce. A release that fails here is one that was never
|
||||
# offered to anybody, which is the entire point of doing it in this order.
|
||||
|
||||
on:
|
||||
push:
|
||||
tags: ['v*']
|
||||
workflow_dispatch:
|
||||
inputs:
|
||||
tag:
|
||||
description: 'Tag to publish, e.g. v1.4.0'
|
||||
required: true
|
||||
|
||||
permissions:
|
||||
contents: write
|
||||
|
||||
jobs:
|
||||
release:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Which tag
|
||||
id: tag
|
||||
run: |
|
||||
TAG="${{ github.event.inputs.tag || github.ref_name }}"
|
||||
[ -n "$TAG" ] || { echo "Could not determine the tag."; exit 1; }
|
||||
echo "tag=$TAG" >> "$GITHUB_OUTPUT"
|
||||
echo "version=${TAG#v}" >> "$GITHUB_OUTPUT"
|
||||
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
ref: ${{ steps.tag.outputs.tag }}
|
||||
# ci/publish-release.sh re-fetches the tag as a ref before reading
|
||||
# its message, because checkout overwrites that ref with the commit
|
||||
# SHA and turns the annotated tag into a lightweight one. It needs
|
||||
# the history to do that.
|
||||
fetch-depth: 0
|
||||
|
||||
- name: The header version is the tag
|
||||
run: |
|
||||
HEADER=$(ci/version.sh)
|
||||
TAG_VERSION="${{ steps.tag.outputs.version }}"
|
||||
echo "plugin header: $HEADER"
|
||||
echo "tag: $TAG_VERSION"
|
||||
if [ "$HEADER" != "$TAG_VERSION" ]; then
|
||||
echo "::error::WordPress compares the update feed against the plugin header and nothing else."
|
||||
echo "::error::With the header at $HEADER and the tag at $TAG_VERSION, every shop that installs this update is offered it again immediately, forever."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Static checks
|
||||
run: ci/static.sh
|
||||
|
||||
- name: It installs and works on the current WordPress and WooCommerce
|
||||
env:
|
||||
WP_VERSION: latest
|
||||
WC_VERSION: latest
|
||||
PHP_VERSION: '8.3'
|
||||
run: ci/site-test.sh
|
||||
|
||||
- name: Build the zip
|
||||
run: ci/build-zip.sh
|
||||
|
||||
- name: Publish, then read the feed back anonymously
|
||||
env:
|
||||
TAG: ${{ steps.tag.outputs.tag }}
|
||||
GH_TOKEN: ${{ github.token }}
|
||||
run: ci/publish-release.sh
|
||||
Reference in New Issue
Block a user