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.

This plugin is currently in sync, so the workflow is preventative here.

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 master 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 #133

リスク: 🟢 低（CIワークフロー追加のみ）
スコープ: `scope:config`
不足: なし

サマリー

• リリースを経由せずに WordPress.org のアセット（.wordpress-org/ と readme.txt）を同期する GitHub Actions ワークフローを追加。
• environment: production を意図的に省略しているため、保護ルールなしで本番 SVN へ直接書き込む点は設計上のトレードオフとして確認が必要。
• サードパーティアクション（10up/action-wordpress-plugin-asset-update@stable）がコミットハッシュ固定ではないため、供給チェーンリスクが微小に存在。

詳細レビュー

テスト要否

• ⚪ テスト不要: .github/workflows/asset-update.yml — CI ワークフロー設定ファイルのみ、ビジネスロジックなし

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

1. .github/workflows/asset-update.yml:31 — 10up/action-wordpress-plugin-asset-update@stable はタグ固定であり、コミットハッシュではない。@stable タグが書き換えられた場合に影響を受ける。組織のセキュリティポリシーでハッシュ固定が求められるなら対応が必要。ただし deploy.yml も 10up/action-wordpress-plugin-deploy@stable をハッシュ固定していないため、既存慣行との一貫性はある。
2. .github/workflows/asset-update.yml:28 — tarosky/workflows/actions/wp-readme@main が @main 固定。tarosky 組織内アクションなのでリスクは限定的だが、同様にハッシュ固定の検討余地あり。
3. environment: production の省略（PR 説明参照） — WP_ORG_USERNAME_TAROSKY / WP_ORG_PASSWORD_TAROSKY がリポジトリ or 組織シークレットとして存在しない場合、初回実行が空認証で失敗する。既存の wordpress.yml では同名シークレットが機能しているため、実害は少ないが、初回 workflow_dispatch での実行確認を推奨。

設計上の懸念

• 保護ルールなしで本番 SVN に書き込む: environment: production を省くと、master への誤コミットが .wordpress-org/** にマッチしただけで即時アセット更新が走る。意図的な設計であることは PR 説明で明示されており、「アセット更新に承認は不要」という運用判断として合理的。ただし .wordpress-org/ への誤コミットが公開ページに即反映されるリスクは維持者が認識しておくべき。
• readme.txt の Tested up to フィールド: README.md から生成されるため、メンテナが README.md を更新し master にプッシュするだけでリリースなしに WordPress.org の表示が変わる。意図した動作であることを確認済みとのこと。

---

🤖 AI triage by Claude — レビュー日: 2026-08-03

[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 を一切触らないため、このリスクを構造的に排除しています。

置き換え先: #134