概要
playground-preview-publish.yml で利用している WordPress/action-wp-playground-pr-preview の expose-artifact-on-public-url アクションが、ci-artifacts リリースを 通常リリース（prerelease: false）として作成します。
これにより以下の問題が起きます。
release-drafter の baseline 判定が乱れる。release-drafter (v6+) はデフォルトで include-pre-releases: false なので、prerelease マークが付いていれば無視されるが、現状は付かない。タイミングによっては ci-artifacts が「最新の非prerelease リリース」になり、次バージョンの算出が壊れる懸念がある。- WordPress.org への自動デプロイワークフロー（
on: release: { types: [published] }）が誤発火する。プラグイン側で production environment の tag policy (*.*.*) でガードすれば実害は止まるが、ガードがない／弱いリポジトリでは事故りうる。
- Releases 一覧に通常リリースと混在して見え、視認性が悪い。Playground 用の中間アーティファクトであり、ユーザー向けリリースではない。
既存の挙動
参考: WordPress/action-wp-playground-pr-preview 内の作成ロジック
```bash
gh release create "$RELEASE_TAG" \
--repo "$release_repo" \
--draft \
--notes "Automated release for WordPress Playground CI artifacts"
```
--prerelease フラグなし。手動で publish したあと、メンテナが UI でチェックを入れない限り通常リリース扱いになります。
提案
tarosky/workflows/.github/workflows/playground-preview-publish.yml の publish ジョブで、アセットアップロード後に下記を追加し、ci-artifacts を 強制的に pre-release マーク する：
```yaml
- name: Ensure ci-artifacts release is pre-release
if: steps.metadata.outputs.found == 'true'
shell: bash
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release edit ci-artifacts --prerelease --repo "$GITHUB_REPOSITORY" || true
```
メリット：
- 既存のアクション (
WordPress/action-wp-playground-pr-preview) を変更せず、tarosky/workflows 側だけで完結
gh release upload --clobber でアセット更新しても prerelease フラグは保持される一回限りの設定- upstream に PR を送るより速い
長期的には WordPress/action-wp-playground-pr-preview 側に prerelease 入力オプションを足してもらうのが本筋ですが、当面はラッパー側で吸収するのが現実的だと考えます。
発見した経緯
hametuha/hamail で Playground プレビューを導入したところ (hametuha/hamail#83)、ci-artifacts が通常リリースとして残り、release-drafter とdeploy ワークフローを混乱させかねない状態だったため。プラグイン側では deploy.yml に明示的なガードを追加して回避 (hametuha/hamail#85) しましたが、共通ワークフロー側で吸収できるはずなので報告します。
概要
playground-preview-publish.ymlで利用しているWordPress/action-wp-playground-pr-previewのexpose-artifact-on-public-urlアクションが、ci-artifactsリリースを 通常リリース（prerelease: false）として作成します。これにより以下の問題が起きます。
release-drafterの baseline 判定が乱れる。release-drafter (v6+) はデフォルトでinclude-pre-releases: falseなので、prerelease マークが付いていれば無視されるが、現状は付かない。タイミングによってはci-artifactsが「最新の非prerelease リリース」になり、次バージョンの算出が壊れる懸念がある。on: release: { types: [published] }）が誤発火する。プラグイン側でproductionenvironment の tag policy (*.*.*) でガードすれば実害は止まるが、ガードがない／弱いリポジトリでは事故りうる。既存の挙動
参考:
WordPress/action-wp-playground-pr-preview内の作成ロジック```bash
gh release create "$RELEASE_TAG" \
--repo "$release_repo" \
--draft \
--notes "Automated release for WordPress Playground CI artifacts"
```
--prereleaseフラグなし。手動で publish したあと、メンテナが UI でチェックを入れない限り通常リリース扱いになります。提案
tarosky/workflows/.github/workflows/playground-preview-publish.ymlの publish ジョブで、アセットアップロード後に下記を追加し、ci-artifactsを 強制的に pre-release マーク する：```yaml
if: steps.metadata.outputs.found == 'true'
shell: bash
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release edit ci-artifacts --prerelease --repo "$GITHUB_REPOSITORY" || true
```
メリット：
WordPress/action-wp-playground-pr-preview) を変更せず、tarosky/workflows側だけで完結gh release upload --clobberでアセット更新しても prerelease フラグは保持される一回限りの設定長期的には
WordPress/action-wp-playground-pr-preview側にprerelease入力オプションを足してもらうのが本筋ですが、当面はラッパー側で吸収するのが現実的だと考えます。発見した経緯
hametuha/hamail で Playground プレビューを導入したところ (hametuha/hamail#83)、
ci-artifactsが通常リリースとして残り、release-drafter とdeploy ワークフローを混乱させかねない状態だったため。プラグイン側では deploy.yml に明示的なガードを追加して回避 (hametuha/hamail#85) しましたが、共通ワークフロー側で吸収できるはずなので報告します。