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, 3 file(s) in .wordpress-org/ have never been published.

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 triaged PR 97 - see details below (full Japanese review follows)

[claude]

AI トリアージ PR #97 | リスク: 🟢低(CI設定のみ) | スコープ: scope:config | 不足: なし — asset-update.yml追加でリリース非依存のWP.orgアセット同期を実現。要確認: (1)environment:production省略によりWP_ORG_*シークレットはOrg/Repoスコープ必須 (2)@stable/@mainの可変タグ参照(軽微なサプライチェーンリスク) — 設計はdeploy.ymlと整合、permissions:contents:readで最小権限OK、テスト不要(CI設定のみ)

[claude]

---

AI トリアージ: PR #97

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

サマリー

• .github/workflows/asset-update.yml を追加し、リリース非依存で WordPress.org アセットを同期できるようにする
• environment: production を意図的に省略しており、シークレットがOrg/Repoスコープであることを事前確認要
• アクションのバージョン参照が可変タグ（@stable/@main）のため、サプライチェーンリスクが微小に存在

---

🤖 AI triage by Claude

[claude]

詳細レビュー（クリックで展開）

テスト要否

• ⚪ テスト不要: .github/workflows/asset-update.yml — CI設定ファイルのみ（ルール7）

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

1. asset-update.yml:32 — 10up/action-wordpress-plugin-asset-update@stable は可変タグ。コミットSHAでピンするとサプライチェーンリスクを排除できる（任意対応、deploy.yml との一貫性を優先するならそのまま可）
2. asset-update.yml:29 — tarosky/workflows/actions/wp-readme@main も可変ブランチ参照。内部アクションなのでリスクは低い
3. environment: production の省略 — PRのNotesに記載済みだが、WP_ORG_USERNAME_TAROSKY / WP_ORG_PASSWORD_TAROSKY がOrg/Repoシークレットであることをマージ前に必ず確認。環境スコープ限定なら初回実行が空クレデンシャルで静かに失敗する

設計上の懸念

なし。設計は deploy.yml と整合しており妥当。workflow_dispatch は既にコミット済みアセットのバックフィルに必要で合理的。permissions: contents: read による最小権限設定は適切。readme.txt の Tested up to 形式の件はPR本文で説明済み。

[fumikito]

1点不明点があったので質問です。

[fumikito]

アクションがREADMEを更新していないとダメ、ということですかね？　この必要性がわからなかったのですが。

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

置き換え先: #98