Add a workflow to update WordPress.org assets without a release

[mayukojpn]

Background

Assets reach WordPress.org only through deploy.yml, which runs on release: published. Anything committed to .wordpress-org/ therefore stays invisible until the next version ships.

Here, 2 file(s) are live under the same name with different content from the repo.

Across the org this affects 12 of 15 plugins: 21 files never published, 12 live under the same name with different content. Most of it dates from a coordinated asset refresh on 2026-07-09/10 that no release has carried out yet.

What this adds

A workflow that syncs .wordpress-org/ and the generated readme.txt using 10up/action-wordpress-plugin-asset-update, independent of releases. It uses the same secrets as deploy.yml.

• push to main touching .wordpress-org/** or README.md — keeps things current from now on
• workflow_dispatch — needed to publish what is already committed, since a path filter only reacts to future pushes

No plugin code is deployed by this workflow, so it does not release a version.

Notes for review

• environment: production is deliberately omitted. deploy.yml declares it, and that environment carries a protection rule. Requiring an approval for every asset sync would defeat the purpose. This assumes WP_ORG_USERNAME_TAROSKY / WP_ORG_PASSWORD_TAROSKY are organization or repository secrets rather than environment-scoped ones — if the first run fails on empty credentials, that assumption was wrong and the line needs adding back.
• readme.txt is synced too, generated from README.md the same way deploy.yml does it. Tested up to is written as e.g. 7.0 rather than 7.0.2; WordPress.org resolves that to the latest patch of the branch, so this does not lower any published value.
• Same change as Add a workflow to update WordPress.org assets without a release taro-cpt-front#55, which was reviewed first as a pilot.

[claude]

AI トリアージ: PR #141

リスク: 🟢 低（CI設定のみ）
スコープ: scope:config
不足: なし

サマリー

• .wordpress-org/ アセットをリリースなしで WordPress.org へ同期する GitHub Actions ワークフローを追加
• environment: production を意図的に省略（要シークレットスコープ確認）
• PHP バージョンが deploy.yml（8.1）と本ワークフロー（7.4）で異なる点に注意

詳細レビュー

テスト要否

• ⚪ テスト不要: .github/workflows/asset-update.yml — CI設定のみ、プラグインコードへの影響なし

レビュワーが確認すべき箇所

1. asset-update.yml:26 — php-version: 7.4 だが deploy.yml は 8.1 を使用。tarosky/workflows/actions/wp-readme@main が PHP バージョンに依存する処理を内包している場合、生成される readme.txt の内容が deploy.yml と異なる可能性がある。アクションの実装を確認し、バージョンを揃えるか問題ないか明示すること。

2. asset-update.yml:34–35 — PR本文に記載のとおり、WP_ORG_USERNAME_TAROSKY / WP_ORG_PASSWORD_TAROSKY が environment: production スコープのシークレットである場合、初回実行は空の認証情報で失敗する。初回 workflow_dispatch 実行前にシークレットのスコープを必ず確認すること。

3. asset-update.yml:29,31 — tarosky/workflows/actions/wp-readme@main と 10up/action-wordpress-plugin-asset-update@stable はどちらもミュータブルな ref を使用。ただし既存の deploy.yml と同じパターンであり、本 PR の新規導入ではないため許容範囲内。

設計上の懸念

なし。変更はプラグインコードに触れておらず、既存の deploy.yml のパターンを踏襲した整合性のある設計。permissions: contents: read を明示しており、最小権限の原則に沿っている。workflow_dispatch を設けて既コミット済みアセットを手動で即時反映できる点も適切。

[fumikito]

方針転換のためクローズします。

各リポジトリに個別の asset-update.yml を追加するのではなく、tarosky/workflows の共有 reusable workflow を workflow_dispatch で呼び出す薄いラッパー方式に一本化しました（tarosky/workflows#121, #122）。

また調査の結果、10up/action-wordpress-plugin-asset-update は readme.txt を trunk へ無条件同期するため、本PRの構成（push + README.md paths）だと main の未リリース README が公開ページに漏洩するリスクがありました。新方式は自前の assets-only SVN commit で readme を一切触らないため、このリスクを構造的に排除しています。

置き換え先: #142