From c2b163c1b5608cfe0c65c4d91ddf44f3ddf5911f Mon Sep 17 00:00:00 2001 From: Su Yang Date: Thu, 3 Sep 2026 00:34:02 +0800 Subject: [PATCH] docs: mark 2026.09.02-r2 as published --- CHANGELOG.md | 19 ++++++++++++++---- CONTRIBUTING.md | 10 ++++++---- README.md | 48 ++++++++++++++++++---------------------------- RELEASING.md | 18 ++++++++++------- docker-compose.yml | 4 +--- 5 files changed, 52 insertions(+), 47 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index acdd0f2..e271302 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,16 @@ ## [Unreleased] +### Changed + +- Marked `2026.09.02-r2` as published after both registries, supply-chain + evidence, signatures, and mutable aliases passed verification; switched the + Quick Start and Compose example from a local `main` build to the immutable + release image. +- Corrected the release and contribution guides to consistently describe + protected lightweight and annotated tag support and the GitHub Release + publication order. + ## [2026.09.02-r2] - 2026-09-02 ### Fixed @@ -10,7 +20,7 @@ `2026.09.02-r1` as a lightweight tag. The release workflow rejected that tag during annotated-tag preflight, before registry login or image construction. - Aligned the image version, validation examples, deployment examples, and - release documentation on the same `2026.09.02-r2` candidate. + release documentation on the same `2026.09.02-r2` release. ### Changed @@ -25,9 +35,10 @@ ### Release status -- Prepared as the next immutable release for 2026-09-02. Until its protected - annotated tag is published and verified, `2026.09.01-r1` remains the current - complete release. +- Published to Docker Hub and GHCR as matching five-platform indexes at + `sha256:9a5ceb20d80485de3e71bfe4a454f913408c6cdc995df17c2805e90fea5a049a`. + Per-platform SBOM and provenance evidence and both registry signatures were + verified before the `2026.09.02` and `latest` aliases were promoted. ### Release notes diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 29f6911..45d0a8e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -200,14 +200,16 @@ Please search for existing issues before opening a new one. When reporting a bug - **Dockerfile**: Keep the multi-stage build structure clear; keep necessary comments for non-obvious trade-offs (such as skipping the Rust build per platform). - **PHP** (`sqlite-select-id-key-fix.php`, etc.): Follow the WordPress coding standards and keep behavior conservative and safe to fall back on, avoiding destructive changes for cases that cannot be fully reasoned about. -- **YAML workflows**: Keep pull-request validation and the tag-driven `Release` workflow consistent with the supported platform matrix and release policy. +- **YAML workflows**: Keep pull-request validation and the release-triggered `Release` workflow consistent with the supported platform matrix and release policy. - Comments should explain intent and constraints, not restate what the code already expresses. ## Versioning and Releases -Releases are triggered by maintainers pushing a protected annotated tag in the -CalVer form `YYYY.MM.DD-rN`. The workflow publishes the same signed multi-arch -manifest under an immutable exact tag to +Normal releases are triggered when maintainers publish a GitHub Release for a +protected CalVer tag in the form `YYYY.MM.DD-rN`. The Releases form may create a +protected lightweight tag or select an existing protected annotated tag; a tag +push alone does not publish images. The workflow publishes the same signed +multi-arch manifest under an immutable exact tag to [Docker Hub](https://hub.docker.com/r/soulteary/sqlite-wordpress) and [GHCR](https://github.com/soulteary/docker-sqlite-wordpress/pkgs/container/sqlite-wordpress), then separately promotes the mutable date and `latest` aliases. Component diff --git a/README.md b/README.md index 622eb1f..afd71b3 100644 --- a/README.md +++ b/README.md @@ -4,15 +4,13 @@ WordPress with SQLite, ready to use out of the box. - -> **Container release availability:** `2026.09.02-r2` is prepared but is not published yet -> as a verified container image. The previous verified release, -> [`2026.09.01-r1`](https://github.com/soulteary/docker-sqlite-wordpress/releases/tag/2026.09.01-r1), -> remains available from Docker Hub and GHCR with matching manifest digest -> `sha256:a2ab943b2f9c9818528153e5b9ac70f9f84625a1f58a24d14a0bb35b91387666`. -> Until the protected annotated `2026.09.02-r2` tag succeeds in both registries, -> build current `main` as shown in Quick Start. The existing `latest` alias still -> represents the previous release and does not include this candidate's fixes. +> **Latest container release:** +> [`2026.09.02-r2`](https://github.com/soulteary/docker-sqlite-wordpress/releases/tag/2026.09.02-r2) +> is published to Docker Hub and GHCR as matching five-platform indexes at +> `sha256:9a5ceb20d80485de3e71bfe4a454f913408c6cdc995df17c2805e90fea5a049a`. +> The verified `2026.09.02` and `latest` aliases were promoted from the same +> release. Pin the exact CalVer tag or manifest digest for reproducible +> deployments. - Based on [official image](https://hub.docker.com/_/wordpress), Easier and more sustainable solution. - DockerHub Page: https://hub.docker.com/r/soulteary/sqlite-wordpress @@ -61,32 +59,26 @@ docker exec -it ls -l /var/www/html/wp-content/mu-plugins/ ## Quick Start -Until `2026.09.02-r2` is published, build current `main` locally: +Pull the immutable CalVer release for reproducible deployments, or use the +rolling `latest` alias when automatic version movement is intentional: ```bash -docker build -t sqlite-wordpress:main . -``` - -After the protected release workflow succeeds, pull the rolling tag for -convenience or the immutable CalVer release for reproducible deployments: - -```bash -# Docker Hub: use latest -docker pull soulteary/sqlite-wordpress # Docker Hub: use an immutable release docker pull soulteary/sqlite-wordpress:2026.09.02-r2 -# GHCR: use latest -docker pull ghcr.io/soulteary/sqlite-wordpress:latest # GHCR: use an immutable release docker pull ghcr.io/soulteary/sqlite-wordpress:2026.09.02-r2 +# Docker Hub: use latest +docker pull soulteary/sqlite-wordpress +# GHCR: use latest +docker pull ghcr.io/soulteary/sqlite-wordpress:latest ``` -Launch the locally built image on port `8080`: +Launch the published image on port `8080`: ```bash docker run --rm -it -p 127.0.0.1:8080:80 \ -v "$(pwd)/wordpress:/var/www/html" \ - sqlite-wordpress:main + soulteary/sqlite-wordpress:2026.09.02-r2 ``` You can also use docker compose to start wordpress: @@ -95,9 +87,7 @@ You can also use docker compose to start wordpress: services: wordpress: - build: - context: . - image: sqlite-wordpress:main + image: soulteary/sqlite-wordpress:2026.09.02-r2 restart: always ports: # Safe local default. Change this only when intentionally publishing the @@ -107,7 +97,7 @@ services: - ./wordpress:/var/www/html ``` -Save the file as `docker-compose.yml` and execute `docker compose up --build`, +Save the file as `docker-compose.yml` and execute `docker compose up -d`, then use a browser to access `localhost:8080`. ![](.github/ready-to-use.jpg) @@ -193,7 +183,7 @@ messages, and publishes only its Web inbox to the host: docker compose \ -f docker-compose.yml \ -f docker-compose.owlmail.yml \ - up --build -d + up -d ``` Open WordPress at `http://localhost:8080`, visit **Settings → SMTP**, and enable @@ -214,7 +204,7 @@ export WORDPRESS_SMTP_AUTH=false docker compose \ -f docker-compose.yml \ -f docker-compose.owlmail.yml \ - up --build -d --force-recreate + up -d --force-recreate ``` Send a test message through the real WordPress mail path: diff --git a/RELEASING.md b/RELEASING.md index 3007788..72f50a9 100644 --- a/RELEASING.md +++ b/RELEASING.md @@ -17,10 +17,11 @@ reviewers when an explicit publication approval is desired. Repository rulesets cannot be installed by a pull request. An administrator must configure and verify this policy in **Settings → Rules → Rulesets**. The -workflow independently requires GitHub's `ref_protected` signal and rejects -branch dispatches, lightweight tags, tags outside `main`, and tags whose target -does not match the checked-out commit. Server-side tag protection remains the -authoritative control. +workflow independently requires GitHub's `ref_protected` signal and accepts both +lightweight (`commit`) tags created by the Releases form and existing annotated +(`tag`) tags. It rejects branch dispatches, tags whose target commit is not on +`main`, and tags whose target does not match the checked-out commit. Server-side +tag protection remains the authoritative control. ## Prepare @@ -67,7 +68,8 @@ release-triggered run is active. For an annotated tag, create and push it first, then select that existing tag in the GitHub Releases form. A tag push alone no longer starts publication; -publishing the GitHub Release is the single fresh-release trigger. +publishing the GitHub Release is the normal automatic fresh-release trigger. +Manual dispatch remains the explicit operator path described below. The `Release` workflow builds each runtime platform once and publishes the same manifest digest to Docker Hub and GHCR under the immutable exact tag: @@ -171,8 +173,10 @@ release=2026.09.02-r2 ./scripts/verify-published-release.sh "${release}" ``` - Create the GitHub Release from the existing annotated tag only after all - image checks succeed. + The GitHub Release already exists at this stage because its `published` + event starts normal fresh publication. Record the verified digest in the + post-release documentation and announcement; do not create another tag or + Release. 4. If the release pull request carried the `release-availability: pending` README marker and local-build Compose configuration, open a documentation diff --git a/docker-compose.yml b/docker-compose.yml index f090644..4374abf 100644 --- a/docker-compose.yml +++ b/docker-compose.yml @@ -1,9 +1,7 @@ services: wordpress: - build: - context: . - image: sqlite-wordpress:main + image: soulteary/sqlite-wordpress:2026.09.02-r2 restart: always ports: # Safe local default. Replace 127.0.0.1 only when intentionally publishing